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

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

Если это нетехнические люди, подделайте статистику. Под "fake" я подразумеваю "provide any inevitably meaningless, but real numbers" из тех, что вы упомянули.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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