Умышленное добавление ошибок для оценки процессов обеспечения качества

Question

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

К сожалению, я не могу найти ни этот документ, ни какой-либо аналогичный с описанием этого трюка.Может кто-нибудь указать мне на такой документ?

РЕДАКТИРОВАТЬ

Чтобы сделать Евгения счастливым, позвольте мне перефразировать последнее предложение первого абзаца:

«Процесс проверки качества не завершен до того, как обнаружены все преднамеренные ошибки»

Answer 1

Одно из названий техники - «Fault Injection».Джеффри Воас и Гэри Макгроу.

Одна из старых книг по этому вопросу - «Внедрение программных ошибок: заражение программ от ошибок»

Answer 2

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

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

Answer 3

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

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

• Завершены ли все функции, определенные для этого выпуска?
• Все ли запланированные тесты были выполнены?
• Количество открытых ошибок в допустимых пределах (например, нет критических ошибок или ошибок с высоким приоритетом, менее 10 ошибок с низким приоритетом и т. Д.)