Как использовать метрики в тестировании, чтобы ускорить релиз цифрового продукта
Метрики в тестировании — пустая трата времени или объективный показатель качества и скорости разработки? Когда применяются и что дают цифровому продукту? Вместе с начальником QA-отдела Fusion Tech постараемся разобраться в этих вопросах и выяснить, какие метрики и как влияют на процесс разработки.
QA-метрики — это инструменты, которые помогают в измерении качества программного продукта и в поиске проблемных мест в ходе реализации проекта.
КОГДА СТОИТ ИСПОЛЬЗОВАТЬ МЕТРИКИ?
Необходимость внедрения и применения метрик должна определяться каждой отдельной командой на конкретном проекте. Чтобы понять, нужен ли этот инструмент и какой именно, определитесь с результатом, который хочется получить в итоге. Часто в статьях на тему тестирования можно увидеть подобные фразы про метрики: “контролируют процесс QA”, “дают объективные показатели о готовности продукта”, “показывают эффективность команды и отдельного сотрудника” и так далее. Может сложиться впечатление, что метрика — это универсальная серебряная пуля от всех проблем, которая разве что не убивает вампиров и оборотней. Но так ли это на самом деле?
Задача метрики — увеличить скорость реализации проекта на всех этапах, налаживая процесс разработки и уменьшая количество и длительность исправления багов.
Представим такую ситуацию: в предыдущем месяце процент возвратов проекта (от разработчика к тестировщику и обратно) колебался в районе 3%, а в этом — увеличился до 15%. Можно подумать, что команда разработки стала работать в 5 раз хуже и пора доставать запылившийся кнут из кладовки. Но в реальной жизни может оказаться, что в предыдущем месяце были простые задачи по верстке, а в следующем — формируется компонент со сложной логикой или требования к задачам описаны не полностью. Это пример того, что конечный результат стоит рассматривать на основе анализа данных метрик, чтобы понимать, где случилась просадка и почему.
ЧЕМ МЕТРИКИ ПОМОГАЮТ ПРОЕКТУ?
Метрики позволяют замечать отклонения системы от предполагаемого результата по таким параметрам, как скорость, качество, производительность процесса создания цифрового продукта, и вовремя подключаться для устранения проблем. Использование качественных и количественных показателей в тестировании и разработке ПО в целом сокращает выход продукта в релиз и гарантирует его жизнеспособность.
Цели сбора метрик:
- Анализ работы системы (оценка совокупности метрик, как показатели меняются во времени, мониторинг новых процессов/идей).
- Поиск проблемных мест: накопление задач, ожидающих тестирования; количество задач в процессе тестирования; время, затраченное на проведение регресса; количество найденных и закрытых багов; количество отклоненных багов; среднее время исправления багов.
- Анализ найденных проблем.
КАКИЕ ПРОБЛЕМЫ МОЖНО ЗАФИКСИРОВАТЬ С ПОМОЩЬЮ МЕТРИК?
1. Низкая пропускная способность*
* Пропускная способность — это количество задач, которое проходит через команду разработки за определенный промежуток времени от стадии требований до выхода продукта в релиз.
Допустим, разработчик способен решить 10 задач за 2 недели, тогда у команды тестирования должны быть возможности и ресурсы их обработать. Если QA недостаточно и один сотрудник может протестировать только 3 задачи из 10, то пропускная способность в релиз будет равна 3. И обратная ситуация — если QA способен протестировать 10 задач, а разработчик может закрыть только 3, то КПД (коэффициент полезного действия) останется также на отметке 3. Как в армии на марш-броске: время, за которое подразделение пробежало дистанцию, будут фиксировать по последнему солдату, то есть подразделение (как единая система) в целом будет бежать со скоростью самого медленного бойца.
В подобной ситуации метрики помогают нам зафиксировать тот факт, что у нас где-то образовалась "пробка" или, наоборот, есть избыточный ресурс, и по итогу прийти к системному равновесию: 10 задач мы получаем в рамках спринта (1 цикла разработки) и 10 задач поступают в конце в продакшн.
2. Большое количество возвратов задач
Возвраты проекта от тестировщика к разработчику из-за уточнения требований и найденных ошибок могут стать одной из причин недостаточной пропускной способности. Что будет, если QA вернет на предыдущий этап (создания продукта) слишком много задач с багами? Как минимум, увеличится нагрузка на отдел тестирования в дальнейшем, так как помимо новых задач придется просматривать переделанные.
Возьмем случай из нашей практики: на небольшом проекте QA-инженер перестал справляться с нагрузкой из-за большого количества задач. На проект добавили еще одного, но это облегчило ситуацию ненадолго. В скором времени проблема повторилась, снова появились “пробки”, так как уже два QA отдавали с усердием еще больше задач, которые после корректировки возвращались на тестирование. Стало ясно, что следует подумать над оптимизацией процессов, а не над расширением штата.
Метрики подсвечивают проблему на ранних этапах, позволяют понять, что идет не так, и быстрее включиться в ход реализации проекта для ее скорейшего решения. Без них команда упускает драгоценное время и вместо разработки новых функций происходит лишь фиксирование выявленных багов.
3. Слишком длинная петля возвратов
Возвраты к предыдущим этапам нужно рассматривать еще и с позиции того, насколько длинную петлю они составляют. То есть на каком из этапов разработки была обнаружена проблема. Если мы выявили баги на этапе формирования требований, то исправление пары строк текста в техническом задании (ТЗ) будет стоить дешевле, чем переделывание кода и повторное тестирование (короткая петля возврата). Обнаружение проблемы в бизнес-логике после разработки, напротив, делает петлю возврата слишком длинной. Она сначала приведет нас к бизнес-аналитику для исправления требований, а после к системному аналитику и далее по цепочке, пока мы снова не дойдем до этапа тестирования.
Аналогично с предыдущим пунктом, чем короче петля возвратов, тем меньше времени требуется на устранение дефектов, и дешевле обходится разработка продукта.
4. Отсутствие баланса между качеством и пропускной способностью
Хорошо это или плохо, но мы живем в капиталистическом мире, где рынок решает все. Можно очень много времени потратить на то, чтобы разработать продукт идеальным до пикселя, но не забываем, что конкуренты не дремлют. Пока вы будете тратить время на доведение всего и вся до совершенства, они выпускают продукты с новыми возможностями. Да, их проекты могут иметь мелкие недочеты, но они уже первые, к их разработке приковано внимание целевой аудитории. Поэтому увлекаться избыточным тестированием — непозволительная роскошь.
Метрики в данном случае помогают распределять и планировать время на тесты более эффективно для выхода новых фичей (функций) без удара по качеству.
КАКИЕ БЫВАЮТ МЕТРИКИ?
На просторах интернета можно найти впечатляющее количество различных метрик. Каждая команда использует свои в зависимости от проекта, предстоящих задач и предыдущего опыта. Подбор нужных для работы метрик обычно осуществляется на этапе планирования тестирования и контроля.
Инструменты, которые чаще используются в нашей компании:
- Метрика “Очередь”: время накопления задач, ожидающих тестирования.
Помогает планировать ресурсы и предотвращать или убирать заторы на проекте.
- Метрика “Плотность дефектов”: количество дефектов в модуле / общее количество дефектов.
Помогает понять, что требует наибольшего внимания при разработке.
- Метрика “Повторно открытые ошибки”: количество повторно открытых ошибок / общее количество ошибок.
Помогает выявить пробелы в QA и добавить дополнительные сценарии тестирования.
- Метрика “Среднее время жизни дефекта”: время, потраченное на исправление дефектов / количество дефектов.
Помогает в планировании релизов (мы примерно можем понять, сколько времени уйдет на исправление дефектов), а также в оценке того, насколько эффективно команда разработки реагирует на баги.
- Метрика “Количество ошибок, найденных на проде”: количество дефектов после релиза / количество дефектов в итерации.
Позволяет понять, насколько стабильно работает продукт после релиза.
КОРОТКО О ГЛАВНОМ:
- Метрики — полезный, но лишь дополнительный инструмент. Они могут подсветить проблему, зафиксировать, в каком месте что-то пошло не так, но не укажут прямо на причину.
- Выбранные метрики следует приводить к единому виду, чтобы было легче ориентироваться на показатели прошлого и отслеживать динамику прогресса будущем.
- С этой же целью (наблюдение за результативностью действий) необходимо проводить анализ метрик с периодичностью раз в спринт, месяц и так далее.
- Не стоит применять этот инструмент для оценки эффективности конкретных людей или внедрять метрики ради метрик, не задавая вопрос: “Что я хочу измерить, и как мне это поможет в работе?”
Старайтесь выбирать те метрики, которые будут максимально полезны для проекта, или доверьтесь команде профессионалов, которые протестируют продукт на всех этапах разработки и быстрее доведут его до релиза.
Новости из мира IT-технологий, о трендах индустрии, бизнес-сервисах и не только — в ТГ-канале или на сайте Fusion Tech.
Читайте также:
Тестирование ПО – важная составляющая любого процесса разработки, которая позволяет контролировать качество информационного продукта в процессе его создания. Чем раньше находятся и исправляются баги, тем меньше требуется денежных затрат заказчика, усилий разработчика и нервных клеток проектного менеджера. Мы во Fusion Tech советуем клиентам выбират…