Сознательно добавляющие ошибки для оценки процессов QA

Как Вы знаете, что как можно больше ошибок было обнаружено и решено в программе? Несколько лет назад я прочитал документ об отладке (я думаю, что это было своего рода ПРАКТИЧЕСКОЕ РУКОВОДСТВО). Среди прочего тот документ описал технику, в которой команда программистов сознательно добавляет ошибки в код и передает его команде QA. Процесс QA считают завершенным, когда все сознательно известные ошибки были обнаружены.

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

Править

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

"Процесс QA не завершен, прежде чем все преднамеренные ошибки будут найдены"

5
задан Boris Gorelik 7 June 2010 в 16:24
поделиться

3 ответа

Одно из названий метода - «Ввод неисправностей». Одной из самых старых книг по этой теме является Джеффри Воас и Гэри МакГроу «Внедрение программных ошибок: внедрение программ против ошибок» .

3
ответ дан 14 December 2019 в 13:27
поделиться

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

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

3
ответ дан 14 December 2019 в 13:27
поделиться

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

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

  • Были ли выполнены все функции, определенные для этого выпуска?
  • Все ли запланированные тестовые примеры выполнены?
  • Находится ли количество открытых ошибок в допустимых пределах (например, отсутствие критических или критических ошибок). ошибки с высоким приоритетом, менее 10 ошибок с низким приоритетом и т. д.)
0
ответ дан 14 December 2019 в 13:27
поделиться
Другие вопросы по тегам:

Похожие вопросы: