tgoop.com/testing_and_life/1510
Last Update:
метрики качества для стартапов, продуктовых компаний и аутсорса
настраивать метрики под специфику бизнеса – это важный момент, который многие упускают из виду. не бывает универсального набора метрик, который идеально подойдёт всем. стартап, продуктовая компания и клиентская разработка (аутсорс) требуют разных подходов, потому что цели и ресурсы у них совершенно разные.
дисклеймер: ниже приведены только примеры, они не применимы для любой компании в вакууме, а даны как отправная точка, о чём можно подумать, когда собираете свой набор метрик.
стартап на ранней стадии
стартапы часто работают в условиях нехватки ресурсов и времени, где скорость важнее идеального покрытия тестами. но это не значит, что качество можно сбросить со счетов. вот несколько метрик, которые помогут стартапу контролировать ситуацию без излишней бюрократии:
Количество багов с приоритетом Critical+ на проде (цель: тренд не должен расти)
важнейший показатель для стартапа – это отсутствие серьёзных сбоев в проде. критичные баги, влияющие на бизнес, – это красный флаг. важно следить за трендом: если он растёт, нужно принимать меры.
Test reliability: процент багов на демо/проде, некоррелирующих с проведёнными тестами (цель: тестировать то, что нужно)
эта метрика показывает, насколько тестирование отвечает реальным потребностям пользователей продукта. если баги на проде не связаны с тем, что тестировалось, значит, что-то идёт не так с процессами или тестовым покрытием.
Time to test (цель: тренд не растёт или падает)
время на тестирование должно либо оставаться стабильным, либо уменьшаться. для стартапа важно сохранять гибкость и не тратить слишком много времени на проверки, которые могут тормозить релизы. если время на тесты растёт, возможно, это сигнал к тому, чтобы оптимизировать процессы.
продуктовая компания
в продуктовой компании ключевая цель – это стабильность и улучшение качества в долгосрочной перспективе. здесь важно отслеживать и процессы, и результат. вот несколько метрик, которые помогут удерживать баланс:
Test coverage + requirements traceability quality (цель: высокое покрытие требований + высокое качество покрытия относительно требований)
тестовое покрытие можно отслеживать по-разному: от процента фичей, протестированных до выхода в прод, до степени покрытия тестами различных уровней (юнит, интеграционные и т.д.). важно, чтобы команда чётко определила, что для них значит "протестировано", и следила за этим.
% of Declined issues (цель: невысокий, тренд не растёт)
важно не только находить баги, но и следить за тем, насколько они релевантны. declined баги (дубли или "работает как задумано") не должны превышать 10% от общего числа. если их больше, это может сигнализировать о проблемах с требованиями, их пониманием командой или коммуникацией внутри команды. или о том, что наш беклог не очень хорошо себя чувствует и в нём сложно что-то найти.
% of Requirements reviewed before development start (цель: стремиться к 100%)
ещё одна важная метрика – это то, как требования проходят ревью перед началом разработки. чем раньше выявляются проблемы, тем лучше.
Эффективность оценки трудозатрат (цель: растёт или не снижается тренд попадания в эстимейты по задачам тестирования)
оценка трудозатрат – важный элемент в долгосрочном планировании. если фактические затраты сильно отклоняются от планируемых, нужно пересматривать подход к оценке или декомпозиции задач.
Backlog health (цель: делать хорошо, плохо не делать)
эта метрика (даже комплекс метрик) отслеживает, насколько здоров ваш бэклог и насколько легко вам планировать на будущее. сюда входит количество актуальных задач, сколько из них требуют дополнительной проработки, сколько давно не обновлялись. это позволяет вовремя удалять устаревшие задачи и оставлять в приоритете актуальные фичи.
продолжение ниже
BY Тестирование и жизнь • про работу для живых людей
Share with your friend now:
tgoop.com/testing_and_life/1510