Как не заблудиться в лесу метрик QA: классический и Data-Driven подходы

Со временем каждая компания сталкивается с необходимостью создания системы метрик, показывающих эффективность тестирования. Как не утонуть в море данных и создать действительно работающую систему оценки качества? Когда пора переходить с метрик из учебников на метрики, решающие реальные задачи бизнеса? Об этом рассказывает Руслан Остропольский, директор по продукту в Test IT, и объясняет разницу между классическим и прогрессивным data-driven подходами.

Что такое классический подход

Классический подход к метрикам тестирования — основа, которую часто преподают в университетах и на курсах. Этот подход включает около 100 показателей, дающих общую картину процессов качества. 

Метрики тестирования делятся на четыре основные категории, каждая из которых включает множество подкатегорий:

1. Качество тестирования: тестовое покрытие, пропуски дефектов, качество тест-дизайна.

2. Проектное планирование: прогресс, учет рисков, прогнозирование затрат.

3. Качество продукта: дефекты, NPS/CSAT, характеристики ПО.

4. Эффективность тестирования: скорость, ROI, работа с дефектами, автотесты.

В классическом подходе используется множество инструментов для расчетов и визуализации — системы для управления тестированием, таск-трекеры, open source frameworks и инструменты аналитики. 

Таким образом удается сформировать десятки срезов и видов метрик. Это одновременно и хорошо, и не совсем удобно: 

• Метрик слишком много, на практике не все они нужны 

Выбрать из 100 метрик подходящие бывает сложно, из-за чего часто компании считают ненужные показатели. Так фокус на реальных бизнес-целях теряется.

• Разброс инструментов 

Много систем, где лежат данные. Сбор и интерпретация метрик требуют огромного количества ручной работы. Это долго, дорого и неудобно.

• Разный взгляд на метрики и ожидания от них

Метрики, полезные для QA, могут оказаться бесполезными для топ-менеджмента или стейкхолдеров. В итоге не все заинтересованные стороны изучают метрики и непонятно, что делать с собранными данными.

При всех перечисленных недостатках классический подход остается важным этапом для большинства команд QA. Через этот метод проходят почти все, чтобы освоить базовые принципы работы с метриками и научиться их применять.  

Что такое Data-driven подход 

Data-Driven — это методика, основанная на использовании реальных данных для принятия решений и оптимизации процессов. В отличие от классического подхода, где упор делается на фиксированные шаблонные метрики, здесь главная цель — интерпретация данных в контексте бизнес-целей.

Перечислю особенности Data-Driven подхода:

• Это более умный и сложный метод, который требует глубокого погружения, особенно на этапе проектирования интеграции 

Нужно постоянно анализировать данные и при запуске метрик отталкиваться от целей. При этом достаточно один раз собрать данные в едином хранилище, далее они собираются автоматически. Процесс можно автоматизировать и забыть про ручную сборку данных.

• Можно создавать уникальные метрики

Те, что идеально соответствуют целям компании и обеспечивают более точную оценку и управление качеством продукта. К примеру, в Test IT мы используем метрику «вес бага», которая помогает оценить общее качество продукта. Для расчета этой метрики мы берем все зарегистрированные баги и присваиваем им веса в зависимости от их приоритета. Так мы получаем единый показатель, который отражает, насколько «здоров» наш продукт. 

• Построить метрики можно в любых срезах и видах

Несмотря на то что разброс систем большой, как и в классическом подходе, работать с ними легко за счет выгрузки всех данных в единое пространство. 

• Правильные названия метрик и их визуализация на вас

Специалист прототипирует дашборд как продукт. Названия виджетов должны отталкиваться от целей, а при их построении важно понимать, для чего нужен конкретный дашборд и какую проблему он поможет решить.

Выбор метрики

Метрики должны быть инструментом для принятия решений, направленных на достижение бизнес-целей. Например, если ваша цель — сократить время выпуска релиза с двух недель до двух часов, важно определить ключевые показатели, которые на это влияют. 

В Data-Driven подходе количество метрик может исчисляться сотнями или даже тысячами. Чтобы не теряться в этом массиве данных, создается иерархия метрик — своеобразное дерево, где на вершине находится ключевая North Star метрика. 

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

Выбор главной метрики зависит от двух факторов:

1. Цели компании. Например, если приоритетом является скорость релизов, эта метрика становится основной, а показатели качества занимают нижние уровни дерева.

2. Существующие проблемы. Если продукт страдает от высокой забагованности, фокус смещается на этот показатель, а связанные метрики, такие как качество тестирования и эффективность тест-анализа, выстраиваются вокруг него.

Кстати, упростить работу с данными также помогает Пирамида Минто за счет визуализации всех зависимостей:

Верхушка пирамиды — ключевые метрики (North Star Metrics).

Следующий уровень — динамика ключевых метрик. Показатели, которые иллюстрируют, как и почему изменяются главные метрики.

Средний уровень — детализация и срезы данных. Здесь рассматриваются аргументы, обоснования и сегменты, объясняющие, что повлияло на изменения.

Основание — точки усилий. Это конкретные действия и зоны для улучшения, которые позволят повлиять на верхушку пирамиды.

Пирамида Минто делает аналитику структурированной и понятной: от общего к частному, позволяя быстро выявлять причины проблем и сосредотачиваться на приоритетных действиях.

Работа с данными

Работа с данными требует контроля их состояния, который можно оценить с помощью индекса здоровья данных, или Data Driven Index. Этот индекс включает в себя три критерия:

• Стабильность. Данные должны обновляться ежедневно и быть доступны в любое время.

• Качество. Полные, достоверные и легко интерпретируемые данные обеспечивают точность анализа.

• Практическая ценность. Метрики и отчеты должны приносить реальную пользу. Например, мы анализируем, какие дашборды и виджеты активно используются, а какие остаются незамеченными. Это помогает оптимизировать отчеты и сделать их более удобными для принятия решений.

 Пример распределения индекса здоровья: 

Визуализация и нейминг

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

Например, дашборд в TMS Test IT может показывать уровень тестов по статусам. Если его назвать просто «Статусы по тестам», это не даст понимания, для чего он нужен. Но если назвать его «Состояние тестовой библиотеки в разрезе состояния статусов», это сразу фокусирует внимание на цели: отследить на каком этапе каждый тест и выявить возможные проблемы. 

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

С помощью TMS Test IT можно создавать дашборды, которые помогают отслеживать ключевые метрики, группировать данные и визуализировать их по времени, проектам и другим атрибутам. Например, хотите понять, где не хватает автоматизации: в TMS можно построить график покрытия автотестами, отфильтровать данные по секциям, и получить четкую картину.

С помощью виджетов специалист может визуализировать загруженность специалистов, понять, хватает ли ресурсов, и где есть возможности для оптимизации.

Чтобы отследить самые тяжелые автотесты, можно воспользоваться отчетом по продолжительности автотестов.

Каждый виджет — это инструмент для достижения конкретной цели. Подробнее об отчетах в системе Test IT читайте в статье по ссылке. 

Как внедрить Data Driven подход 

Я бы посоветовал сперва собрать имеющиеся данные. 

1. Обратиться к бизнесу или продукту. Часто они уже имеют метрики и данные в BI-системах, особенно если речь идет о бизнесовых или продуктовых задачах. 

2. Проконсультироваться с DevOps или разработчиками. У них может быть настроен мониторинг или другие инструменты, которые подойдут для анализа.

3. Провести собственное исследование. Вы можете изучить доступные инструменты, тестировать их и подбирать те, которые лучше всего подходят для ваших задач.

Допустим, перед компанией стоит задача ускорить релизы. Вот что необходимо сделать:

1. Определяем цель. Что значит «быстрые релизы» в вашем контексте? Это могут быть сроки разработки, количество ошибок или время их устранения.

2. Формируем критерии. Определяем показатели, которые будут отражать достижение цели: скорость разработки, стабильность релизов, качество исправлений.

3. Собираем данные. На этом этапе разбираемся, какие источники нам нужны и подключаем их.

4. Аккумулируем собранные данные в едином хранилище.

Настраиваем интеграцию через инструменты, такие как:

— Airflow для автоматизации загрузки данных;

— кастомные интеграции для специфических нужд;

— репликации баз данных, которые создают копии для безопасной работы с информацией.

5. Создаем витрины данных.

Это очищенные, структурированные наборы данных, собранные из различных источников. Витрины упрощают анализ и помогают выделить главное. 

6. Визуализируем показатели.

Наглядность важна для принятия решений. Используем графики, дашборды и отчеты, например, через Yandex DataLens — инструмент для создания интерактивных визуализаций и удобного обмена отчетами.

Интеграционная схема:

Дашборд с общими данными в Yandex DataLens:

Советую регулярно делать срезы данных в динамике (по годам, месяцам), чтобы отслеживать изменения и тренды. Также важен мониторинг, чтобы убедиться, что система работает корректно и не происходят сбои.

Резюме

• Классика работает там, где она уместна, но современные вызовы требуют гибкости и готовности внедрять новые подходы.

• Когда компания становится крупной, объем данных и сложность систем стремительно растут. Data-Driven подход становится не просто опцией, а необходимостью.

• Не все стейкхолдеры одинаково воспринимают данные. Используйте подходы вроде пирамиды Минто и концепцию North Star Metric, чтобы адаптировать подачу информации.

• Умение работать с аналитикой стало базовым навыком для тестировщиков.

• Создавать дашборды нужно не ради визуализации, а ради понимания сути происходящего.

Прямо сейчас вы можете попробовать все виджеты Test IT в облачной версии системы. Бесплатный триальный период Test IT Cloud — 14 дней.