- Жалобы пользователей после внедрения новых фич
- Стабильность критически важных пользовательских путей
- Время, потраченное на исследовательское тестирование
“Если вы единственный тестировщик на проекте, возможно вам дадут множество советов насчет тестовых метрик. Покрытие кода, количество выполненных тестов, количество багов, процент автоматизации и так далее. Если к этому добавят еще и метрики DORA — метрики вашей продуктивности как инженера — и вот тогда вы точно почувствуете себя перегруженным этими цифрами.
Вот в чем проблема: когда вы тестируете “соло”, вам нужны метрики, которые дадут вам максимум полезной информации при минимальных затратах.
После многих лет работы с одиночными тестировщиками и небольшими командами я нашел три метрики, которые неизменно приносят пользу.
1. Проблемы в новых фичах, о которых сообщили пользователи
Эта метрика по факту совпадает с одной из DORA-метрик — Change Failure Rate (показатель неудачных нововведений), и она имеет практический смысл для одиночных тестировщиков.
Как отслеживать:
- Создайте простую электронную таблицу с колонками для: Название фичи
- Дата релиза
- Проблемы, о которых сообщили клиенты в первую неделю
- Серьезность проблемы (высокая/средняя/низкая)
- Требовалось ли исправление (хотфикс)
Почему это важно:
Метрика быстро сообщит вам, эффективна ли ваша стратегия для выявления важных проблем до того, как они попадут к клиентам.
Обратите внимание:
Не нужно отслеживать буквально каждую незначительную проблему. Сосредоточьтесь на проблемах, которые серьезно влияют на пользовательский опыт или требуют срочного исправления.
2. Стабильность критически важных User Journey
Эта метрика связана с DORA-метрикой Time to Restore Service (Время восстановления сервиса) и она помогает предотвратить крупные инциденты.
Как ее отслеживать:
- Определите 3-5 наиболее критических пользовательских путей
- Создайте ежедневный красный/янтарный/зеленый статус для каждого:
- Зеленый: Работает как ожидалось
- Янтарный: Незначительные проблемы
- Красный: Journey поломан
- Отмечайте все инциденты и время их устранения
Почему это важно:
Обеспечивает вам и стейкхолдерам мгновенную видимость состояния системы без сложных инструментов мониторинга.
Частая проблема:
Попытка отслеживать слишком много пользовательских путей. Сосредоточьтесь на том, что действительно важно для бизнеса.
3. Распределение времени: Исследовательское и реактивное тестирование
Эта метрика поможет вам поддерживать баланс между проактивной и реактивной работой, поддерживая нужную частоту развертывания.
Как отслеживать:
Используйте лист учета времени с такими категориями:
- Исследовательское тестирование
- Разбор багов
- Регрессионное тестирование
- Поддержка прода
И еженедельно проводите обзор этих метрик.
Почему это важно:
Если вы тратите более 40% своего времени на “реактивные” задачи, это признак того, что в вашей стратегии нужно что-то менять.
Возможная проблема:
Не стоит отслеживать время в мельчайших деталях. Нескольких цифр достаточно, чтобы заметить тенденции.
Несколько советов
Начните с малого
- Начните хотя бы с одной метрики
- Используйте инструменты, которые у вас уже есть (электронные таблицы вполне подойдут)
- Вырабатывайте правильные привычки, прежде чем усложнять
Автоматизируйте там, где это целесообразно
- Используйте конвейер CI/CD для подсчета развертываний
- Настройте простые автоматические проверки для критических путей
- Создайте простой дашборд в существующих инструментах
Эффективные репорты
- Создайте сводный репорт на одной странице
- Ориентируйтесь на тенденции, а не на абсолютные цифры
- Пишите краткие заметки по событиям
Как связаны эти метрики с DORA
Эти метрики естественным образом связаны с ключевыми метриками DORA:
- Метрика “Проблемы клиентов с новыми фичами” помогают отслеживать DORA-метрику “Процент неудачных нововведений”
- “Стабильность критических путей“ связана с “Временем восстановления сервиса”
- Метрика “Распределение времени на исследовательское тестирование” помогает улучшить частоту развертывания и Lead Time.
И вы отслеживаете их таким образом, который максимально удобен лично вам, как единственному тестировщику на проекте.”