О каких метриках нужно знать тестировщику, чтобы работать эффективнее
Как правило, есть два типа заказчиков, которые обращаются за услугами тестирования: первым нужно удостовериться, что продукт соответствует установленным критериям качества, а вторым — полностью выстроить процессы тестирования с нуля.
Во втором случае я, как тимлид тестирования, выявляю критерии качества, составляю тестовые стратегии, подбираю команду и выстраиваю процессы. Контролировать один такой проект несложно, но если количество проектов растет, то держать в поле зрения каждый из них становится проблематично. Нужно постоянно быть в контексте ситуации, переключаться между проектами и мониторить, что в них происходит.
Я понял, что мне необходим инструмент, который поможет оперативно реагировать на изменения в процессе тестирования. Этим инструментом стали метрики — они позволяют видеть информацию о работе продукта в моменте и кодифицировать ее, а также делать данные прозрачными и недвусмысленными. Кроме того, имея перед глазами список показателей, которые можно считать, легче понять, как улучшить продукт и процессы на проекте.
Любой проект имеет цель, и заказчику необходимо знать, насколько он к ней близок — будь то удовлетворение потребности пользователя или рентабельность проекта. Метрики выражают эти показатели в цифрах и делятся на несколько основных групп: продуктовые, метрики качества и метрики производительности.
Продуктовые метрики — ключевой показатель эффективности работы команды перед заказчиком. Именно эти метрики ведут к принятию решений о развитии продукта, помогают делать его более клиентоориентированным и показывают, как пользователи воспринимают продукт.
Основные виды продуктовых метрик:
- метрики привлечения — средний доход на пользователя и пожизненная ценность клиента. Показывают, насколько проект прибыльный;
- метрики вовлеченности пользователей за определенный период: DAU — за день, WAU — за неделю, MAU — за месяц;
- коэффициент удержания клиента — retention rate. По этой метрике можно увидеть, как часто пользователь возвращается к продукту. Retention rate также помогает понять, действительно ли внедряемые изменения идут продукту на пользу;
- метрики востребованности функционала.
Может показаться, что QA-специалист не должен вникать в метрики, которые ближе к продакт-менеджменту и маркетингу, чем к тестированию. Но на деле продуктовые метрики нередко оказывают влияние на работу тестировщика.
Приведу пример. В моей практике была работа с мобильным приложением интернет-магазина, которое скачали 100 пользователей, а заказ из него совершил только один человек. Веб-версия магазина при этом конвертировала в 10 раз лучше. Именно благодаря этим продуктовым метрикам удалось выяснить, что в жизненный цикл заказа закралась ошибка, которая никаким иным способом не регистрировалась.
Еще один пример. Была база данных, которая ежедневно обогащалась сотней новых пользователей, но в какой-то из дней в базу попало всего семь человек. Мы следили за этой продуктовой метрикой и вовремя забили тревогу — в сценарии очевидно что-то сломалось. Нужно было искать проблему и тестировать.
Пример третий. Процент использования приложения на определенном устройстве может помочь с определением процента времени, выделяемого на тесты на этом девайсе, а также общие ресурсы, доступные для тестирования.
Метрики качества определяют верность технических составляющих. Они иллюстрируют не только соответствие продукта техническому заданию или идее, но и насколько эффективно выстроен процесс контроля качества. Отдельно можно вывести метрики производительности: время загрузки, крэши и время отклика.
Я применяю собственную классификацию метрик качества для тестирования: от простейших количественных — сколько багов найдено, сколько тестов написано, сколько времени затрачено на прохождения теста — до производных.
Количественные универсальные — мастхэв на каждом проекте.
- Количество тест-кейсов в разбивке по уровням проверки. Эта метрика позволяет считать уровень тестового покрытия.
- График количества успешных, упавших и пропущенных тест-кейсов. Соотношение упавших и успешных говорит о качестве билда, а пропущенные указывают на скорость устаревания кейсов.
- Соотношение дефектов на тесте и проде. Эта метрика показывает, работает ли тестирование как таковое, хорошо ли оно выстроено на проекте, и сколько дефектов команда пропускает.
Количественные специфические. Метрики, которые используются на проекте по необходимости.
- Количество багов на тест. Эта метрика показывает степень атомарности кейса.
- Скорость прохождения тестов при прогоне. Здесь можно делать выводы о необходимости автоматизации тестирования на проекте.
- Процент разбираемых тестов в контексте автоматизации.
- Прирост и закрытие багов — то, что позволяет анализировать жизненный цикл бага.
- Срок жизни бага.
- Причина возникновения бага: зависимость от среды и зависимость от процесса.
Производные метрики. Для лучшего понимания что из себя представляют такие метрики приведу пример, как мы, взяв количественные показатели, вывели производную метрику для одного из проектов.Тестировщики во время приемки находили баги высокого приоритета на проекте, где severity и priority были слиты в одну сущность. Согласно проектным требованиям этот билд нельзя было пропускать в релиз. Возник вопрос: почему на проекте, где тестирование происходит постоянно, в финальном билде так много багов?
Мы стали разбирать баги и обнаружили, что, несмотря на высокий приоритет, они не влияли на релиз существенным образом. Возникла необходимость создать формулу определения приоритета, и получился такой результат: П=Серьёзность*(Воспроизводимость+Частота).
ㅤ
«Серьезность» показывает, насколько заметен дефект, «Воспроизводимость» — насколько легко баг воспроизвести, а «Частота» — то, как много пользователей столкнется с дефектом. Мы перемножили между собой количественные метрики и получили метрику производную, которая дает новую информацию о продукте. Благодаря ей удалось актуализировать приоритеты багов, исходя из бизнес-потребности.
Также производные метрики могут учитывать:
- частоту встречающихся ошибок по выборке клиентов;
- оценку работ команд с багами;
- время жизни дефекта/время жизни дефекта согласно SLA;
- как конкретная команда работает с дефектом;
- плановый и актуальный показатели работ;
- коэффициент стабильности требований бизнеса.
Инструменты, которые помогут в анализе и сборе метрик:
- Prometheus и Grafana — связка сервисов для сбора показателей и их визуализации;
- Confluence — для контроля показателей работы команды;
- TMS — система управления тестированием, которая помогает не только организовать процесс, но и собрать большое количество разнообразных метрик. В IT Test мы пользуемся собственной разработкой — TMS DoQA. Она стала лучшим импортозамещающим решением на IT-рынке в 2022 году по версии Tagline;
- MetaBase — позволяет считать процент покрытия кода и время, затраченное на тестирование;
- Яндекс Метрика — для контроля продуктовых метрик, понимания пользовательских сценариев и знания, на каких устройствах пользователи запускают продукт.
При выборе метрик в тестировании важно понимать, что они всегда должны истекать из потребности бизнеса, и это нормально, когда в ходе развития проекта метрики модернизируются. Специфические проекты требуют специфических метрик, поэтому к каждому отдельному случаю нужен индивидуальный подход.
Больше экспертных материалов о заказной разработке, дизайне и тестировании в Telegram-канале IT Test.
Простите, но я не могу понять, как это работает. Количество тест-кейсов вообще не покажет уровень тестового покрытия.
"Количество тест-кейсов в разбивке по уровням проверки. Эта метрика позволяет считать уровень тестового покрытия."
К определенному функционалу применим определенный набор проверок. Отсутствие в этом наборе некоторого типа кейсов сообщит о недостаточном уровне тестового покрытия. Второй момент, который позволяет конвертировать количественный показатель числа тест-кейсов в информацию об уровне тестового покрытия, - это атомизация задач и соответствующих им кейсам. На каждый функционал тестирование создает группы задач с разными уровнями и типами проверок. Если по итогу выполнения каждой задачи был создан хотя бы один соответствующий ей тест-кейс, то мы можем говорить о том, что мы достигли хотя бы минимально необходимого уровня тестового покрытия.
Это называется тестирование на пользователях.
Тестировать нужно до того, как код попадет на прод, а не после.