Привет, коллеги!
Давненько не писал ничего — был в отпуске. Сейчас предстоит еще небольшой перерыв в общении в данном сообществе — подготавливаюсь к докладу на грядущих SQA Days 6 (в рамках SECR 2009). Но тем не менее, начатую работу надо закончить, поэтому закончу опровергать свою же статью "Парадокс: Хорошее тестирование ухудшает качество."

Мы уже разобрались с основным парадоксом, и осталось разоблачить 7 ошибочных утверждений.
Поехали!

Стоп. Сперва, ответ на вопрос «критерием чего является метрика подсчитывающая отношение починенных дефектов к общему числу найденых». Мое мнение таково — такую величину хорошо измерять для того, чтобы:

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

А вот теперь поехали!
1) Хуже тестирование --> меньше багов --> у программистов меньше времени уходит на фиксы и работу с дефект-трэкером, а больше времени на отладку кода.

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

2) Хуже тестирование --> меньше вопросов от тестеров  --> у программистов меньше времени уходит на болтовню и больше времени на работу, отладку итд.

Меньше вопросов — меньше задумываешься. Не раз сталкивался с ситуацией когда программист, объясняя мне как работает его функциональность, сам находит недочеты в работе, несостыковки в логике и тд. и тп. Получается, что тестирование еще не началось, а уже есть что написать в дефект-трэкер. Более того, большинство разработчиков любят рассказывать о том, что и как они запрограммировали.

3) Хуже тестирование --> преимущественно находятся наиболее очевидные дефекты --> программисты тратят меньше времени на фиксы «всякой ерунды» и чинят только реальные Баги.

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

4) Хуже тестирование --> меньше багов в трэкере  --> лучше продукт! (Да, да, есть такие люди которые думают, что чем меньше ошибок было найдено во время разработки, тем лучше продукт! И они, при этом, занимаются разработкой ПО!)

А может тогда вообще лучше не писать баги?
Никогда нельзя проводить оценку качества по количеству дефектов в трэкере. Прикинем, что это так — сразу же разработчики перестают писать баги на самих себя, это раз. Два — договариваются с тестерами, чтобы те баги им письмами присылали, вместо записи в трэкер. И так далее — начинаются игрища с дефект-трэкером.
Суммарное количество записей в дефект-трэкере это показатель ничего.

5) Хуже тестирование --> меньше денег надо платить исполнителям --> можно найти более высокооплачиваемых программистов (которые должны производить более качественый мёд).

Более высокооплачиваемый программист, по идее, должен быть и более опытным и продвинутым. Сотвественно он работает над более сложными частями проекта. А вот на количество допускаемых багов программистом ни его стоимость ни опыт напрямую не влияют. Опыт да, вероятно поможет программисту избегать «детских» багов. Но вот кто тогда будет искать более заковыристые дефекты в более сложной функциональности, если мы экономим на исполнителях в тестировании?

6) Хуже тестирование --> меньше изобретательности --> проще пройти тесты (все тесты пройдены — продукт качественый, да?)

Давайте писать тесты, которые не находят баги — их еще проще пройти....
Изобретатьльность нужна тестировщикам для того, чтобы искать неисправности. Очевидно, что более смекалистый тестировщик в состоянии выдумать большее количество тестовых случаев. И как результат — найти больше багов. И возвращаемся к тому, что больше багов -> больше информации о том, где ПО «болеет» -> больше шансов, что вылечат и болеть не будет.

7) Хуже тестирование --> меньше различных критериев качества --> проще достичь «good enough quality».

Это всё-равно, что считать, что тебя не видят, если глаза закрыть.
Так же и тут, если мы проверяем меньше различных аспектов качества ПО, оно никаким образом лучше не становится. Проще ли достичь «good enough quality»? Да, но будет ли оно гуд и енаф?