По мере роста софтверных компаний они приходят к необходимости измерять метрики. Когда в компании всего пара десятков человек, довольно легко понять, хорошо ли работают тестировщики. Когда компания разрастается до нескольких сотен или тысяч человек, следить за тем, как все работают, становится сложнее.
В какой-то момент руководство растущей компании приходит к выводу, что для оценки работы команды необходимо использовать метрики. И зачастую командам предлагают начать подсчитывать баги.
Количество багов само по себе не говорит ни о чем
Если вы скажете, что в этом месяце QA-команда нашла пятьдесят багов, это ничего не значит. В этом утверждении столько же смысла, сколько в попытке определить, хороша ли книга, подсчитав, сколько в ней страниц.
— Хорошая книга?
— Ну, я ее не читал, но в ней пятьсот страниц!
Сравнение количества багов у разных команд ни о чем не говорит
Количество багов, которые находит QA-команда, зависит от многих вещей. Каждый тестируемый продукт отличается от другого. Продукт одной команды может быть очень простым, продукт другой команды может быть довольно сложным или совершенно новым. Кроме того, у каждой команды могут быть свои подходы к регистрации багов. У одной команды может быть практика устного сообщения об багах разработчику, если он все еще работает над фичей. В другой команде принято фиксировать буквально каждый найденный баг вплоть до пикселя. Наконец, один баг в одной команды может считаться тремя багами в другой.
Рассмотрим две команды, которые тестируют продукт на iOS и Android. Одна команда может зарегистрировать один баг для дефекта, который они обнаружили в обеих операционных системах, а другая — два бага для этого дефекта, по одному для каждой операционной системы.
Сравнение количества багов, найденных одной и той же командой за определенное время, уже что-то говорит
Если вы отслеживаете количество багов, которые команда находит каждый месяц, и при этом происходят значительные изменения, это может что-то значить. Например, увеличение количества найденных багов может означать:
- Тестировщики стали лучше находить баги
- Разработчики создают больше багов
- Только что была добавлена новая сложная фича.
Но это также может означать:
- Изменились процедуры регистрации багов
- В прошлом месяце половина команды ушла в отпуск, поэтому было сделано меньше работы, а теперь все вернулись.
Зависит от того, кто нашел баг — заказчик или тестировщик
Когда баги регистрируются, важно знать, кто и когда их обнаружил. Очевидно, что в лучшем случае тестировщик найдет баг в тестовой среде задолго до того, как фича поступит в прод. Худший из возможных сценариев — обнаружение бага заказчиком. Поэтому если вы обратите внимание на то, какой процент багов находят тестировщики, а какой — заказчики, это может о чем-то вам сказать. Особенно если вы посмотрите на метрику в динамике.
Если ваша команда начала отслеживать эту метрику, и в первый месяц 75 % багов нашли тестировщики, а 25 % — заказчики, у вас будет «базовая линия» для сравнения. Если же во втором месяце 85 % багов были найдены тестировщиками, а 15 % — заказчиками, то можно сделать вывод, что ваша QA-команда стала лучше работать.
Метрики — обоюдоострый меч
Их можно использовать для наглядной демонстрации того, насколько хорошо работает QA-команда, нужно ли нанимать больше сотрудников, и есть ли проблемы в процессах релиза. Также метрики можно использовать в качестве оружия, манипулировать ими или геймифицировать. Внимательно рассмотрев количество багов в контексте, вы подберете метрики, которые будут полезны в вашем случае.
Книга Джеквони The Complete Software Tester
