Как оценить качество программного продукта

Question

У меня есть продукт X, который мы поставляем клиенту C каждый месяц, включая исправления ошибок, усовершенствования, новые разработки и т.д.) Каждый месяц меня просят ошибиться с "гарантией" качества продукта.

Для этого мы используем ряд статистических данных, полученных в результате проведенных нами тестов, таких как:

• коэффициент повторного открытия (количество повторно открытых ошибок / количество протестированных исправленных ошибок)
• новый уровень ошибок (количество новых ошибок, включая регрессии, обнаруженных в ходе тестирования / количество исправленных протестированных ошибок)
• для каждого нового улучшения - новый уровень ошибок (количество найденных ошибок для этого улучшения / количество мандей).

и различные другие цифры.

По причинам, в которые мы не будем вдаваться, невозможно тестировать все каждый раз.

Итак, мой вопрос заключается в следующем:

Как мне оценить количество и тип ошибок, которые остаются в моем программном обеспечении?Каким стратегиям тестирования я должен следовать, чтобы убедиться в том, что продукт хорош?

Я знаю, что это немного открытый вопрос, но, эй, я также знаю, что простых решений не существует.

Спасибо.

Answer 1

Я не думаю, что вы когда-нибудь сможете по-настоящему оценить количество ошибок в вашем приложении.Если вы не используете язык и процесс, допускающие формальные доказательства, вы никогда не сможете быть по-настоящему уверены.Вероятно, вам лучше потратить свое время на настройку процессов, направленных на минимизацию ошибок, чем на попытки оценить, сколько их у вас есть.

Одна из самых важных вещей, которые вы можете сделать, - это иметь хорошую команду контроля качества и хорошее отслеживание рабочих элементов.Возможно, вы не сможете проводить полное регрессионное тестирование каждый раз, но если у вас есть список изменений, внесенных в приложение с момента последнего выпуска, то ваши специалисты по контролю качества могут сосредоточить свое тестирование на тех частях приложения, которые, как ожидается, будут затронуты.

Еще одна вещь, которая была бы полезна, - это модульные тесты.Чем больше вашей кодовой базы вы охватили, тем более уверенными вы можете быть в том, что изменения в одной области непреднамеренно не повлияли на другую область.Я нашел это весьма полезным, так как иногда я что-то меняю и забываю, что это повлияет на другую часть приложения, а модульные тесты сразу показали проблему.Пройденные модульные тесты не гарантируют, что вы ничего не нарушили, но они могут помочь повысить уверенность в том, что внесенные вами изменения работают.

Кроме того, это немного избыточно и очевидно, но убедитесь, что у вас есть хорошее программное обеспечение для отслеживания ошибок.:)

Answer 2

Вопрос в том, кто требует от вас предоставления статистики.

Если это нетехнические люди, подделайте статистику.Под "фальшивкой" я подразумеваю "предоставление любых неизбежно бессмысленных, но реальных цифр", о которых вы упомянули.

Если это технические специалисты без опыта работы в CS, им следует рассказать о проблеме остановки, которая неразрешима и проще, чем подсчет и классификация оставшихся ошибок.

Существует множество показателей и инструментов, касающихся качества программного обеспечения (покрытие кода, цикломатическая сложность, рекомендации по кодированию и инструменты для их обеспечения и т.д.).На практике работает то, что автоматизируется как можно больше тестов, когда тестировщики-люди выполняют как можно больше тестов, которые не были автоматизированы, а затем молятся.

Answer 3

Я думаю, что проще всего поступить - это лучший способ.Классифицируйте ваши ошибки по степени серьезности и устраняйте их в порядке уменьшения серьезности.

Таким образом, вы можете передать максимально качественную сборку (количество оставшихся существенных ошибок - это то, как я бы оценивал качество продукта, в отличие от некоторой сложной статистики).

Answer 4

Большинство гибких методологий довольно четко решают эту дилемму.Вы не можете проверить все.Вы также не можете тестировать его бесконечное количество раз, прежде чем выпустить.Таким образом, процедура заключается в том, чтобы полагаться на риск и вероятность возникновения ошибки.И риск, и вероятность являются числовыми величинами.Произведение того и другого дает вам номер RPN.Если их число меньше 15, вы отправляете бета-версию.Если вы можете снизить эту сумму до менее чем 10, вы отправляете продукт и настаиваете на исправлении ошибки в следующем выпуске.

Как рассчитать риск ?

Если это сбой, то это 5 Если это сбой, но вы можете найти обходной путь, то это число меньше 5.Если ошибка снижает функциональность, то это 4

Как рассчитать вероятность ?

можете ли вы воспроизводить его каждый раз, когда запускаете, это 5 баллов.Если предоставленный обходной путь все еще приводит к сбою, то менее 5

Что ж, мне любопытно узнать, использует ли кто-нибудь еще эту схему и хочет ли узнать их мнение по этому поводу.

Answer 5

Какой длины кусок бечевки?В конечном счете, что делает продукт качественным?Ошибки дают некоторое представление о том, что да, но задействовано много других факторов, охват модульным тестированием является ключевым фактором в IMO.Но, по моему опыту, главным фактором, влияющим на то, может ли продукт считаться качественным или нет, является хорошее понимание решаемой проблемы.Часто случается так, что "проблема", для решения которой предназначен продукт, понимается неправильно, и разработчики в конечном итоге изобретают решение проблемы, которую они обрисовали в своей голове, а не реальную проблему, таким образом, создаются "баги".Я убежденный сторонник итеративного Проворный разработка, таким образом, обеспечивает постоянный доступ к продукту с учетом "проблемы" и продукт не отклоняется далеко от своей цели.

Answer 6

Вопросы, которые я услышал, касались того, как мне оценить ошибки в моем программном обеспечении?и какие методы я использую, чтобы обеспечить хорошее качество?

Вместо того чтобы проходить полный курс, вот пара подходов.

Как мне оценить ошибки в моем программном обеспечении?

Начните с истории, вы знаете, сколько их вы нашли во время тестирования (надеюсь), и вы знаете, сколько было найдено постфактум.Вы можете использовать это, чтобы оценить, насколько эффективно вы находите ошибки (DDR - коэффициент обнаружения дефектов - одно из названий этого).Если вы можете показать, что в течение некоторого постоянного периода времени ваша DDR остается стабильной (или улучшается), вы можете дать некоторое представление о качестве выпуска, предположив количество дефектов после выпуска, которые будут обнаружены после выпуска продукта.

Какие методы я использую, чтобы обеспечить хорошее качество?

Анализ первопричин ваших ошибок укажет вам на конкретные глючные компоненты, конкретных разработчиков, создающих глючный код, тот факт, что отсутствие полных требований приводит к реализации, не соответствующей ожиданиям, и т.д.

Совещания по обзору проекта, позволяющие быстро определить, что было хорошим, чтобы эти вещи можно было повторить, а что плохим, и найти способ не делать этого снова.

Надеюсь, это даст вам хорошее начало.Удачи вам!

Answer 7

Похоже, все сходятся во мнении, что акцент следует делать на модульном тестировании.Отслеживание ошибок - хороший показатель качества продукта, но он точен только для вашей команды тестирования.Если вы используете модульное тестирование, это дает вам измеримый показатель покрытия кода и обеспечивает регрессионное тестирование, так что вы можете быть уверены, что ничего не нарушили с прошлого месяца.

Моя компания полагается на тестирование на уровне системы / интеграции.Я вижу, что появляется много дефектов из-за отсутствия регрессионного тестирования.Я думаю, что "ошибки", при которых реализация требований разработчиком отклоняется от видения пользователя, - это своего рода отдельная проблема, которую, как заявили Дэн и rptony, лучше всего решать с помощью гибких методологий.