Как понять, где команда буксует в тестировании: 5 примеров на основе дашборда DoQA
Когда тестирование идет «вслепую», то баги прорываются в прод, релизы задерживаются, а QA-лиды тратят время на выяснение причин пропуска дефектов. Понять, где именно система дает сбой, помогают аналитические дашборды. В недавно вышедшей фиче системы управления тестированием DoQA — четыре виджета, которые в реальном времени собирают метрики по тестированию. Рассказываем про 5 признаков того, что команда буксует, и как определить их по дашбордам DoQA.
Признак №1 — количество новых артефактов падает
Что происходит
Вы замечаете, что за выбранный период в пространстве не появилось ожидаемое количество новых тест-кейсов, чек-листов или прогонов.
Что это может значить
- У команды нет ресурса на актуализацию документации.
- У команды нет ресурса на актуализацию документации.
- В спринтах не хватает времени на покрытие новых фич тестами.
- Появились новые задачи, а тестирование не успевает за разработкой.
Что делать
Оцените баланс между задачами и возможностями команды. При резком росте артефактов проверьте, не дублируется ли документация и достаточно ли детально она описывается. При падении — есть риск снижения покрытия.
Признак №2 — растет доля незавершенных прогонов
Что происходит
Визуально заметно, что большинство прогонов завершаются не полностью: много тестов остаются со статусом «Пропущен», «Сломан», «Заблокирован».
Что это может значить
- Тестировщикам не хватает информации по задачам.
- Не хватает ответственности за завершение прогона.
- Есть узкие места в продукте, которые постоянно ломаются.
- Тестирование не успело актуализировать документацию к моменту регресса.
Что делать
Проанализируйте стабильность регрессов. Выделите тесты, которые чаще всего оказываются в статусе «Заблокирован» или «Сломан», и устраните причины.
Признак №3 — загрузка на команду распределяется неравномерно
Что происходит
Один человек создает большую часть артефактов и запускает прогоны, при этом остальные активны эпизодически. Или в пространстве слишком мало действий по сравнению с ожидаемыми результатами.
Что это может значить
- Задачи распределены хаотично.
- Участники не понимают, что за ними закреплено.
- QA-лид не видит, кто что делает.
Что делать
Назначайте ответственных, проверяйте распределение прогонов. Используйте сравнительную аналитику по пользователям, чтобы понять, кто справляется, а кому может потребоваться помощь.
Признак №4 — количество активных прогонов растет, а результат не меняется
Что происходит
Прогоны создаются, но не завершаются. Или зависают надолго. Количество прогонов «в работе» растет, а общее число завершенных почти не увеличивается.
Что это может значить
- Команда тестирует вразнобой.
- Нет дедлайнов или понятного процесса закрытия прогона.
- Часть тестов никто не берет в работу.
Что делать
Проверьте, кто назначен исполнителем, задайте критерии завершения, следите за прогонами в режиме реального времени.
Признак №5 — одни и те же ошибки повторяются из релиза в релиз
Что происходит
Процент статусов «Провален» и «Сломан» в похожих тестах держится стабильно от релиза к релизу. Картина не улучшается, баги рецидивные.
Что это может значить
- Ретро не приводят к изменению документации.
- Команда не отслеживает динамику по проблемным зонам.
Что делать
Используйте тренды для баг-ретро: выясняйте, какие тесты чаще всего падают и почему. Обновите регрессионный набор и добавьте причины отказов — это поможет точнее работать с проблемами и снижать их количество.
Дашборды в DoQA — не просто красивые графики. Проверить это вы можете сами.
Чтобы увидеть, как работает аналитика и какие инсайты можно из нее извлекать, начните с бесплатного триала DoQA. За 14 дней вы успеете протестировать дашборды на своей команде, оценить прозрачность и настроить процессы.
Узнать больше о возможностях DoQA можно в Telegram-канале.