Единственный тестировщик на проекте: три важные метрики

“Если вы единственный тестировщик на проекте, возможно вам дадут множество советов насчет тестовых метрик. Покрытие кода, количество выполненных тестов, количество багов, процент автоматизации и так далее. Если к этому добавят еще и метрики 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.

И вы отслеживаете их таким образом, который максимально удобен лично вам, как единственному тестировщику на проекте.”

Единственный тестировщик на проекте

Kato Coaching


Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас