tgoop.com/testing_and_life/1508
Last Update:
продолжим нашу нерегулярную рубрику про работу с метриками
прошлый пост был про теорию «делайте хорошо, плохо не делайте», но всем всегда хочется чего-то более практического. к сожалению, как у типичного менеджера, у меня есть только один универсальный рецепт, как сделать правильно: пробовать и смотреть на результаты, учиться на ошибках и снова пробовать.
но давайте рассмотрим некоторое количество примеров с балансировкой количественных и качественных метрик, чтобы было чуть понятнее, о чём вообще речь.
метрики – это инструменты, которые могут помочь нам понять, что происходит с проектом, и принимать более обоснованные решения. но сами по себе метрики могут давать неполную картину, поэтому важно комбинировать разные показатели, чтобы лучше видеть, где мы находимся и куда движемся.
вот несколько примеров, как это можно сделать:
1. тренд количества найденных дефектов на проде + удовлетворённость пользователей + количество пользователей
- если на проде начинают чаще находить баги, это тревожный сигнал. но важно также учитывать, насколько пользователи в целом довольны приложением и сколько их вообще. если количество пользователей растёт, а удовлетворённость не снижается, возможно, эти баги не такие уж и критичные. однако, если дефектов становится меньше, а пользователи начинают больше жаловаться или прекращают пользоваться приложением, нужно срочно что-то делать.
2. время на выполнение тестов + актуальность документации / стабильность стендов
- если тесты занимают всё больше времени, это может говорить о разных проблемах, начиная от усталости команды, заканчивая разросшимся и неактуальным набором тестов или нестабильностью энвов. поэтому прежде, чем решать, что надо работать быстрее, стоит посмотреть, как выглядит окружающая тестировщиков действительность в виде документации, стендов и тп.
3. скорость работы команды (например, lead time) + удовлетворённость команды
- скорость работы команды – важный показатель, но он мало значит, если команда при этом выгорает. если lead time хороший, но команда жалуется на перегрузку, это сигнал, что нужно пересмотреть процессы и распределение задач.
4. процент покрытия требований тестами + баланс матрицы трассируемости требований + тренд оценки ревью
- покрытие требований тестами – это основа качества, но важно, чтобы это покрытие было сбалансированным и отражало все ключевые аспекты. баланс матрицы трассируемости показывает, насколько требования охвачены тестами, а тренд оценки ревью помогает понять, как качественно эти тесты реализованы. все три метрики в связке (и ещё пачечка других)) дают понимание, насколько полно и качественно мы тестируем продукт.
5. количество багов на модуль приложения умноженное на коэффициент важности этого модуля
- не все баги одинаково полезны. если баг найден в ключевом модуле, это может иметь более серьёзные последствия, чем аналогичный баг в менее критичном компоненте. умножив количество багов на коэффициент важности модуля, можно получить более точную оценку того, насколько серьёзна проблема и куда стоит направить ресурсы в первую очередь.
все эти пары и комбинации метрик помогают получить более объёмную картину происходящего, вовремя замечать проблемы и находить баланс между различными аспектами работы. метрики – это не самоцель, а инструмент для улучшения процессов. пробуйте разные подходы, анализируйте результаты, учитесь на своих ошибках и корректируйте курс. так можно найти тот самый баланс, где все счастливы и проект движется в правильном направлении.
BY Тестирование и жизнь • про работу для живых людей
Share with your friend now:
tgoop.com/testing_and_life/1508