Как оценивать работу специалиста, отвечающего за автотесты, метрики и KPI?

Привет, Хабр! Меня зовут Андрей, я SDET-специалист в компании SimbirSoft. В этой статье мы разберём, какие метрики действительно применимы к специалисту по автотестированию и как их корректно использовать. Будет полезно для тимлидов команд по обеспечению качества, автотестировщиков и любых специалистов, которые хотят оценить метрики автотестирования.

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

Однако возникает вопрос: как оценить вклад конкретного специалиста по автотестированию?

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

Но на практике оценить SDET-специалиста сложнее, чем кажется. Частая ошибка — пытаться применить к нему те же метрики, что и к разработчику или к QA-специалисту (ручному тестировщику). Это создаёт неверные стимулы и подменяет реальные цели погоней за цифрами.

Например:

• Ориентация на «количество написанных тестов» приводит к раздуванию кодовой базы бесполезными проверками.

• Погоня за процентами «тестового покрытия» заставляет игнорировать критичные сценарии ради формальных показателей.

• Фокус на «количестве найденных дефектов» может спровоцировать создание нестабильных тестов, которые генерируют ложные срабатывания, либо сместить внимание инженера с профилактики регрессии на поиск лёгких ошибок.

В результате метрики растут, а реальное качество продукта — нет.

Из реальной практики: в одном из проектов у нас измеряли эффективность автотестировщика по проценту упавших тестов в регрессии. Сотрудник начал выпиливать все нестабильные проверки, чтобы поднять процент «успешности». В итоге покрытие упало, а в прод ушли серьёзные баги. Другой пример: KPI «время выполнения тестов» привёл к тому, что тесты стали запускаться только на минимальном наборе данных — экономия 30%, но потеряли 50% проверок.

Поэтому прежде чем внедрять метрики, важно понять: что именно мы хотим измерить? Качество кода автотестов? Влияние на скорость релизов? Надежность? И главное — что из этого действительно зависит от SDET, а что от команды или инфраструктуры?

Основные метрики измерения эффективности

Рассмотрим традиционные метрики эффективности, относящиеся к QA-направлению (куда часто входит и специалист по автотестированию):

Проблема в том, что почти каждая из этих метрик начинает ломаться, если превратить её в персональный индикатор. Это не значит, что данные метрики бесполезны, скорее наоборот: многие из них полезны как индикаторы состояния системы. Но далеко не все подходят для персонального KPI SDET.

Давайте разберём каждую из вышеперечисленных метрик подробнее.

1. Тестовое покрытие

Можно измерять через % покрытия:

• требований,

• объема кода,

• функциональности,

• тест-кейсов.

Формула для требований: 

Покрытие юнит-тестами анализируется через инструменты анализа кода, интеграционные и E2E-тесты — через отчёты TMS (система управления тестированием). Поскольку автотесты пишутся постепенно, можно указывать процент прироста покрытия или плановый процент на конец отчетного периода.

Что можно считать хорошим результатом?

Для критичного функционала — 80–90% покрытия кода или требований, для вспомогательного — 50–60%. 

Опасно гнаться за 100%, поскольку это часто ведёт к избыточным тестам и поддержке мусора. 

На что обратить внимание: покрытие не показывает качество проверок. Лучше смотреть на покрытие именно критических путей (core paths).

У нас был проект, где покрытие юнит-тестами достигало 95%, но прод падал каждую неделю, поскольку тесты проверяли сеттеры и геттеры, а не бизнес-логику. Я настоял на внедрении мутационного тестирования (PITest). Оказалось, что реальная эффективность тестов была не выше 50%. Так что рекомендую использовать покрытие как грубый ориентир, но обязательно дополнять анализом того, что именно покрыто.

2. Количество найденных дефектов

Если автотесты находят дефекты, значит, они работают 🙂 Эта метрика определенно полезна. Данные можно получить из баг-трекинговой системы, если в ней корректно настроены метки для дефектов, указано получение дефекта с прогона автотестов, а также данные инициатора, который завёл дефект.  Считать нужно не только количество, но и критичность найденных багов. Один блокирующий баг ценнее десяти косметических.

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

На что обратить внимание?

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

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

А если багов не найдено вовсе? Это не значит, что тесты «идеальные». Возможно, они стабильны, но не видят реальные дефекты. Отсутствие ошибок может означать как высокое качество продукта, так и низкую чувствительность проверок.

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

3. Плотность дефектов

Формула:  

Пример: 20 багов при 100 тест-кейсах → 0,2 дефекта/тест-кейс для модуля 1.

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

Если на один тест приходится больше одного дефекта (ПД > 1), это часто признак того, что тест проверяет слишком много логики одновременно. В идеале каждый тест должен иметь одно утверждение (assert), тогда сбой указывает на конкретную проблему, а не на группу ошибок.

Высокая плотность дефектов — не всегда плохо. При тестировании новой функциональности значение 0,6-0,8 может быть нормой. В стабильном регрессе даже 0,2 — повод насторожиться.

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

4. Скорость закрытия дефектов

Это командный показатель, зависящий как от работы QA и разработчиков, так и от выстроенных процессов по исправлению бага в команде. Данные можно получить из TMS, а после проанализировать динамику.

Хороший результат: время от создания до закрытия дефекта сокращается от спринта к спринту. Для критических багов — не более 1–2 дней, для тривиальных — до 5 дней. 

На что стоит обратить внимание? 

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

5. Эффективность тестов

Формула:

Показывает, какой процент багов выявляется до релиза, а не пользователями.

Хороший результат: 80–90% для зрелого продукта, 50-70% для нового. Важный нюанс: если эффективность тестов 95%, а в проде каждый релиз находится 1–2 серьёзных бага, значит, либо автотесты не закрывают критичные сценарии, либо их мало. И наоборот – 60% эффективности может быть отлично для стартапа с ручным регрессом. 

Совет: считайте эту метрику отдельно для регрессионных автотестов и отдельно для ручного тестирования. Смешивание автотестов и ручного тестирования в одну метрику размывает диагностическую ценность. Если эффективность упала с 80% до 60% — непонятно, что именно чинить: переписывать тесты или пересматривать процесс ручного тестирования.

6. Соотношение пройденных/проваленных тестов

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

Приемлемое значение: 90–95% успешных тестов в стабильной системе. Если падает ниже 80%, тогда ищите flaky-тесты или проблемы окружения. 

Обратите внимание: если тесты всегда зелёные (100% успеха), возможно, они ничего не проверяют. Нормально, когда небольшой процент тестов периодически падает из-за реальных багов.

7. Время выполнения тестов

Автоматизатор тестирования может влиять на этот показатель через:

• корректную подготовку данных,

• многопоточный запуск,

• оптимизацию кода автотестов.

Данные берутся из TMS или отчётов о прогоне.

Хороший результат: время выполнения регресса должно расти медленнее, чем количество тестов. Оптимально — сокращение времени в 2–3 раза по сравнению с ручным прогоном. 

Совет из практики

Один мой коллега оптимизировал набор тестов с двух часов до 15 минут, но потерял стабильность — тесты стали падать из-за гонок, поэтому пришлось вернуть часть синхронизаций. Золотая середина – время, которое укладывается в ночной прогон CI/CD (обычно 1-2 часа).

8. Успешность регресса

Под автоматизацию чаще всего попадают смоук- и регрессионные сценарии. Здесь также важно актуализировать автотесты и обеспечить стабильное окружение.

Формула:  

Хороший результат: >95% для регресса. Если ниже, то сначала проверьте тесты, возможно, среди них есть нестабильные flaky-тесты.

Из личного примера: у нас на проекте была метрика успешность регресса, которая составляла 85%, показатель низкий. Оказалось, что 10% падений было утеряно из-за того, что dev-среда перезагружалась во время прогона. После переноса на выделенный стенд показатель вырос до 97% без изменения кода тестов. Так что всегда проверяйте, чья это зона ответственности.

Метрики, которые подойдут для SDET 

Давайте рассмотрим метрики, относящиеся только к автотестированию.

Сокращение времени тестирования за счёт автотестов

Подсчет времени выполнения кейсов вручную и последующее измерение времени прогона автотестов. Метрика позволяет оценить экономию ресурсов и ROI (окупаемости инвестиций) автоматизации. Может показать, насколько эффективно внедрение автотестов и сколько времени оптимизирует проект за счет внедрения автоматизации.

Хороший результат: окупаемость автоматизации за 3–6 месяцев для часто прогоняемых сценариев. 

Совет: ROI имеет смысл считать накопительно— за 3, 6,12 месяцев. В первые месяцы затраты почти всегда превышают выгоду, но это нормально: автоматизация — это инвестиция, а не мгновенная экономия.

Количество flaky-тестов

Flaky-тесты — это тесты, которые дают разные результаты при одинаковых условиях.

Формула:  

Можно учитывать как ложноположительные, так и ложноотрицательные автотесты.

Приемлемое значение: <5% от общего числа тестов. Если >10% — это уже серьёзная проблема, поскольку теряется доверие к автоматизации. 

Совет: заведите привычку раз в две недели выделять время на починку flaky-тестов. И обязательно логируйте и анализируйте, почему тест получился нестабильным.

Индивидуальные vs. командные метрики

Часть метрик — индивидуальные, часть — командные. Важно, чтобы сотрудник понимал, где его личный вклад, а где результат работы команды.

Совет: составьте таблицу зон ответственности. 

Например:

 — Индивидуальные: качество кода автотестов, прирост покрытия, количество flaky-тестов, время выполнения тестов (оптимизации).

 — Командные: эффективность тестов, плотность дефектов, скорость закрытия багов.

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

Системы постановки целей

Выбор системы оценки эффективности — это не просто вопрос HR-процедур. Это инструмент, который определяет, на чём  будет концентрироваться сотрудник в течение отчётного периода. Для SDET правильный выбор особенно важен: его работа находится на стыке разработки, тестирования и инфраструктуры, и неверно выбранные метрики могут привести к тому, что инженер будет оптимизировать не то, что нужно бизнесу.

KPI (ключевые показатели эффективности) — для оперативного контроля (количественные, краткосрочные показатели).  

MBO (управления по целям) — для стратегических, гибких целей.

Обе методики предполагают совместную постановку задач с сотрудником.

Пример KPI

 Пример MBO

Эти метрики также могут быть привязаны к бонусной системе.  

В случае MBO оценка может проводиться по проценту выполнения целей:

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

Опыт оценки эффективности

Приведу случай из практики. На одном из проектов SDET-инженера оценивали по трём KPI:

• тестовое покрытие (должно быть >80%),

• количество пройденных тестов (не менее 95%) и

• количество заведенных дефектов (не менее 10 в спринт).

Первое, что он сделал, написал около сотни простых тестов на покрытие, чтобы набрать более 80%. Как потом оказалось — они почти ничего не проверяли, но KPI был выполнен.

Второе — он стал маркировать как баги даже минимальные отклонения в UI, лишь бы набрать 10 штук. В итоге команда стала негативно относится к нему, да и польза для продукта была близка к нулю.

После этого на ретроспективе командамы пересмотрелиа метрики: убрали количество дефектов, добавили «время восстановления после падения автотестов» (MTTR) и «долю критических сценариев, покрытых автотестами». И главное — перестали привязывать KPI к бонусам напрямую, а использовали MBO с качественной оценкой. Работа пошла веселее, а тесты реально стали ловить баги.

Что показывает этот опыт: когда метрика становится целью, она перестаёт работать как метрика. SDET-инженер перестал ориентироваться на цифры и начал смотреть на реальное качество продукта. Покрытие упало до 60%, но эти тесты реально ловили баги. Количество заведённых дефектов сократилось до 3-4 в спринт, но это были настоящие проблемы, а не отклонения в 1 пиксель.

KPI полезны как ориентир, но опасны как цель. Хороший SDET знает, когда отступить от цифры ради реального результата.

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

Выводы

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

Существуют и другие методики управления эффективностью, например OKR (Objectives and Key Results), KRA (Key Result Areas). Выбор зависит от специфики проекта. При внедрении любой методики не забывайте раскрывать ее важные этапы: постановку задач, контроль реализации, обеспечение команды необходимой информацией по метрикам, мотивацию команды.

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

Удачной автоматизации и зелёных прогонов!

Спасибо за внимание!

Больше авторских материалов для SDET‑специалистов от моих коллег читайте в соцсетях SimbirSoft — ВКонтакте и Telegram.