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

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

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

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

А вот теперь поехали! ( Читать дальше )

Здравствуйте коллеги.

Кто-нибудь мог подумать что я в серьёз думаю, что хорошее тестирование способно ухудшить качество ПО. Смею вас заверить: я так не думаю.
Давайте разбираться почему же такой парадокс кажется возможным.

Для начала посмотрим на приведенный показатель качества. Отношение починеных дефектов к общему числу найденых. Если у нас найдено 100 дефектов, а починено из них 50 — это лучше, чем найдено 100 и починено 25 и хуже чем ситуация, когда найдено 100, а исправлено 75 из них. Все логично, такую метрику можно использовать как показатель качества.
А вот и нет! Не является это показателем качества. Почему?
( Читать дальше )

Доброго всем дня.
На написание этой заметки меня подтолкнула тема/опрос на форуме it4business.ru

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

Итак, представим, что у нас есть команда разработчиков, которая допускает 72 ошибки, в среднем за итерацию (это абсолютное число всех допущеных ошибок везде где только можно — спеки, доки, код; функциональные и нефункциональные — всё-всё тут). И есть у нас команда тестирования, которая находит в среднем за итерацию 1/3 всех ошибок (24). При этом команда разработчиков способна починить, скажем, все 24 бага в среднем за итерацию.

Давайте, теперь, возьмем за один из критериев качества, количество незакрытых дефектов по отношению к найденым дефектам. Т.е. если 10 багов нашли, 10 починили — 100% качество по этому показателю; если нашли 20, починили 10 — 50% качество итд.

И что же получается? Получается, что такой показатель качества 100% — все 24 бага из 24 чинятся. К концу итерации 0 открытых дефектов. Красотища!

А теперь представим, что команда тестирования улучшила свои показатели. Стала работать в два раза лучше и находить 48 ошибок в среднем за итерацию.
Что получаем? Получаем, что разработчики чинят только половину найденых дефектов, а следовательно наш показатель качества теперь равен 50%. Качество ухудшилось.

При этом абсолютное качество осталось неизменным — 33% (отношение починеных дефектов к общему количеству допущеных ошибок).
Кому интересно, вот тут есть калькулятор.

А вот еще несколько утверждений:
1) Хуже тестирование --> меньше багов --> у программистов меньше времени уходит на фиксы и работу с дефект-трэкером, а больше времени на отладку кода.
2) Хуже тестирование --> меньше вопросов от тестеров  --> у программистов меньше времени ухожит на болтовню и больше времени на работу, отладку итд.
3) Хуже тестирование --> преимущественно находятся наиболее очевидные дефекты --> программисты тратят меньше времени на фиксы «всякой ерунды» и чинят только реальные Баги.
4) Хуже тестирование --> меньше багов в трэкере  --> лучше продукт! (Да, да, есть такие люди которые думают, что чем меньше ошибок было найдено во время разработки, тем лучше продукт! И они, при этом, занимаются разработкой ПО!)
5) Хуже тестирование --> меньше денег надо платить исполнителям --> можно найти более высокооплачиваемых программистов (которые должны производить более качественый мёд).
6) Хуже тестирование --> меньше изобретательности --> проще пройти тесты (все тесты пройдены — продукт качественый, да?)
7) Хуже тестирование --> меньше различных критериев качества --> проще достичь «good enough quality».

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