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

Question

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

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

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

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

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

Итак, мой вопрос:

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

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

Спасибо.

Answer 1

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

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

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

Моя компания полагается на тестирование на уровне системы / интеграции. Я вижу много дефектов, потому что отсутствует регрессионное тестирование. Я думаю, что «ошибки», когда реализация требований разработчика отклоняется от взгляда пользователя, являются своего рода отдельной проблемой, которую, как заявили Dan и rptony, лучше всего решать с помощью Agile методологий.

Answer 6

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

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

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

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

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

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

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

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

Answer 7

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