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

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

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

Во-первых, сам приведенный парадокс это разоблачает.
Во-вторых, такая ситуация: у нас есть 25 дефектов и 20 из них починили (показатель = 80%). А теперь, представьте, что какой-то чрезчур-ретивый тестировщик написал по баге в трэкер на каждую опечатку в продукте, а их 25. Получилось, что у нас 50 багов и только 20 из них починили (=40%). А если бы был написан один дефект на все 25 опечаток, то у нас было бы 20 из 26(~=77%). А изменилось ли что-то в продукте? Нет.

Давайте теперь представим ситуацию, что такая метрика и вправду используется для оценки качества ПО. В нашей отрасли зачастую работают люди умные и смекалистые. Хотите качество повысить — мы идем к вам! Смотрим на предыдущий пример — 20 из 25, показатель 80%.
Теперь представим, что на каждый баг, найденый тестером («нажали на кнопку — результат не получили»), разработчик, починивший(уже) этот баг пишет еще один(«метод прес_бутон не работает») и тут же метит его как починеный. Получаем — 40 из 45(~=89%). Вот так вот на ровном месте почти +10%. Красота!

Еще стоит задуматься над тем, что дефекты в данной метрике обезличены. Игра в цифирьки получается. Ведь достаточно одного серьезного дефекта (типа «программа не работает» :) чтобы полностью инвалидировать ПО.

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

А еще интересный момент — как считает калькулятор. Нет, он все правильно считает, если кто-то подумал, что я обманул и использовал кривой алгоритм. Посмотрите — в обоих случаях «абсолютное» качество одинаковое. Поэтому создается впечатление, что более продуктивная команда тестирования не имеет выйгрыша. Ан-нет! Легким движением руки заставим разработчиков чинить не 24 (сколько худшая команда находит), а 48 (сколько лучшая) и получаем, что «абсолютное» качество вырастает вдвое.

О чем это говорит? О том, что:
— тестирование напрямую качество не улучшает — ведь пока у нас не стали разработчики лучше работать (48 вместо 24), ничего не менялось.
— чем лучше тестирование, тем больше шансов выпустить более качественный продукт, т.к. у разработчиков больше информации о том, что же «болит» у ПО.
— с метриками надо обходиться осторожно и использовать только объективные показатели и к месту. Иначе найдется кулибин, который придумает как обмануть ущербную метрику.
— если перед вами поставили задачу нарисовать какие-то графики, таблички и прочую статистику по дефект-трэкеру, то либо попытайтесь отмахаться, доказав ущербность всех таких вычислений (смотря что считать конечно же и для чего). Либо предоставляйте данные в выгодном для всех свете, чтобы не было желания у людей начать использовать дефект-трэкер не по назначению.

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

ЗЫ: В начале статьи вы должны были видеть фиолетовый текст, с выравниванием по правому краю. К сожалению, редактор оскуднел. Недолго в нём была возможность раскрашивать текст и позиционировать его на экране...