Крылатый гений сидит среди инструментов. Циркуль, весы, молоток, рубанок. Всё под рукой. Но он бездействует, подперев голову. Не от лени. Он видит проблему и понимает: имеющиеся инструменты не дают ответа.

Внедрение нейросетей всколыхнуло индустрию. Мы переживаем эпоху, схожую с Ренессансом. Все говорят о космических возможностях, о том как агенты изменят разработку. А я предлагаю посмотреть на то, что уже есть в руках.

Мастера северного Возрождения видели божественное в деталях. Не в грандиозных замыслах, а в складках ткани, в отражении света на металле. Может, и нам стоит взглянуть не на космические дашборды с метриками, а на содержимое каждого теста?

Это первая часть большого исследования. Материала получилось много, поэтому разбили на три части. Здесь погружаем в проблему. В следующих частях расскажем наше видение решения и покажем практический инструмент.

С чего всё началось

Меня зовут Михаил Дюжев, я директор департамента обеспечения качества в Ростелекоме. 15 лет в ИТ.

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

И пришли к неприятному выводу: метрик много, графиков ещё больше, а проблемы наши остались там же, где и были. Тесты падали на те же грабли. Ошибки проскакивали в прод. Команда тратила время на поддержку тестов, которые ничего не ловили.

Надо было что-то с этим делать. Поэтому 2026 год мы решили посвятить переоценке собственной работы. И вот что имеем на начало года.

Что мы измеряли раньше

Стандартный набор, который есть в любой команде:

• Количество автотестов

• Покрытие кода

• Pass rate

• Flaky tests

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

Но есть вопрос, на который они не отвечают: насколько хорошо наши тесты ловят ошибки?

И есть проблема масштаба. Когда автотестов тысячи, человек физически не может проконтролировать качество каждого. Начал писать тест, разработка зависла на смежной задаче, отложил. Вернулся через неделю, что-то упустил, дописал как получилось. Тест зелёный, в CI попал, метрики выросли. Эта история стара как мир и встречается везде.

Количество тестов растёт. Покрытие растёт. А ошибки в проде всё равно случаются. Автотесты проходят, CI зелёный, релиз выкатывается. Потом приходит обратная связь от пользователей.

Мы стали разбираться. Но не как обычно - искать конкретный пропущенный кейс и дописывать тест. Решили переосмыслить сам подход к оценке.

Что мы увидели внутри тестов

Взяли случайную выборку из 50 тестов и посмотрели на assertions. Типичная картина:

assertThat(response.getStatusCode()).isEqualTo(200);

Один assertion. Проверка статуса.

Формально тест корректен. Он зелёный. Метрика покрытия от него выросла. Но что он реально проверяет?

Такой тест не заметит, если API вернёт 200 с пустым телом. Или с неправильными данными. Или со сломанной структурой JSON. Он фиксирует, что сервер ответил. Не фиксирует, что сервер ответил правильно.

Мы посчитали: из 50 тестов в выборке 34 проверяли только status code. Ещё 11 добавляли проверку «тело не пустое». И только 5 тестов детально проверяли содержимое ответа.

Это не значит, что 68% тестов бесполезны. Они выполняют свою функцию - фиксируют, что endpoint доступен и отвечает. Но они не отвечают на вопрос: правильно ли работает бизнес-логика?

Что мы поняли

Традиционные метрики измеряют объём и стабильность работы. Это важно. Но есть ещё одно измерение: глубина проверок.

Количество тестов показывает, сколько сценариев покрыто. Не показывает, насколько глубоко каждый сценарий проверен.

Покрытие кода показывает, какие строки выполнялись. Не показывает, проверялся ли результат выполнения.

Pass rate показывает стабильность. Не показывает полноту проверок.

Мы не предлагаем отказываться от этих метрик. Мы предлагаем дополнить их метриками качества самих проверок.

Что мы предлагаем: глубина проверок

Полезли в исследования. Google публиковал работы про Mutation Testing at Scale. Microsoft писал про State Coverage. Академические работы про Oracle Problem копились с 80-х годов.

Оказалось, что вопрос «как оценить качество проверок в тесте» задавали давно. И ответы есть. Просто они не дошли до массовой практики.

Мы собрали эти подходы и адаптировали под свои задачи. Ключевая идея: дополнить метрики объёма метриками глубины проверок.

Вот как это выглядит на практике:

Уровень 0. Тест без проверок. Да, такие бывают. Вызвали метод, ничего не проверили. Покрытие засчиталось.

Уровень 1. Проверка status code. Сервер ответил 200. Хорошо, но что он ответил?

Уровень 2. Проверка наличия тела. Ответ не пустой. Уже лучше, но что в нём?

Уровень 3. Проверка полей верхнего уровня. В ответе есть поле id, есть поле status. Прогресс.

Уровень 4. Проверка вложенных структур. user.email существует и содержит @. user.address.city не пустой.

Уровень 5. Проверка форматов и типов. created_at соответствует ISO 8601. price это число, не строка.

Уровень 6. Проверка бизнес-логики. total равен сумме позиций минус скидка. Статус заказа изменился корректно.

Разница существенная. Тест уровня 1 фиксирует только доступность сервера. Тест уровня 6 проверяет корректность бизнес-логики.

Вторая ось: покрытие полей

Глубина проверок - это одна метрика. Вторая - сколько полей вообще проверяется.

Endpoint возвращает 12 полей. Тест проверяет 2: id и status. Остальные 10 полей могут вернуть что угодно, тест этого не заметит.

Мы ввели для себя понятие State Coverage: отношение проверенных полей к общему количеству полей в схеме. Формула простая:

State Coverage = проверенные_поля / все_поля × 100%

Если у вас 17% - это слабый тест. 50% - средний. 75% и выше - хороший.

Комбинация двух метрик даёт понимание реального качества теста. Высокая глубина при низком покрытии полей - тест глубоко проверяет малую часть ответа. Низкая глубина при высоком покрытии - тест поверхностно смотрит на всё.

Что это даёт

Когда мы добавили эти метрики к существующим, картина стала полнее. Теперь мы видим не только сколько тестов написано и какой процент проходит, но и насколько глубоко каждый тест проверяет систему.

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

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

Почему публикуем сейчас

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

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

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

Это не попытка продать готовое решение. Это приглашение к разговору.

Что дальше

Это первая часть из трёх. Здесь мы обозначили идею: традиционные метрики можно дополнить метриками глубины проверок.

Во второй части расскажу подробнее про методологию оценки. Как именно считать глубину проверок. Какие ещё метрики мы используем. На чём основаны подходы Google и Microsoft, которые мы адаптировали.

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

Упражнение: прочувствуйте сами

Для лучшего понимания проблематики предлагаем небольшой эксперимент со своими автотестами. Займёт минут 20, но впечатления останутся надолго.

Шаг 1. Соберите картину

Выгрузите текущие метрики: количество тестов, покрытие, pass rate. Посмотрите на цифры. Скорее всего, они выглядят неплохо. Запомните это ощущение.

Шаг 2. Загляните под капот

Возьмите случайную выборку из 10-20 тестов. Именно случайную, не те что «точно хорошие». Откройте код и посмотрите на assertions. Посчитайте: сколько тестов проверяют только status code? Сколько заглядывают в тело ответа? Сколько проверяют что-то осмысленное про бизнес-логику?

Если после этого шага вам не стало немного грустно, значит у вас всё хорошо и вам можно поделиться опытом здесь же на Хабре!

Шаг 3. Мысленный эксперимент

Представьте: в одном из endpoint сломалась логика расчёта. Цены, скидки, баланс - что угодно важное. Но сервер по-прежнему отвечает 200 и возвращает JSON. Посмотрите на свою выборку. Сколько тестов заметят проблему?

Вот это ощущение и есть разница между метриками объёма и метриками качества.

Материалы по теме

Мы не стали переписывать уже существующие материалы по метрикам автоматизации тестирования. Их много, и они хорошо раскрывают тему. Предлагаем изучить самостоятельно:

Про метрики тестирования в российских компаниях:

Авито: мутационное тестирование на 1500 сервисов

Wrike: как мы используем метрики в разработке автотестов

ЮMoney: дашборд тестировщика и сбор метрик

Исследования, которые легли в основу нашего подхода:

Google: State of Mutation Testing at Google (ICSE 2018)

Microsoft Research: State Coverage - Software Validation Metrics beyond Code Coverage (SOFSEM 2012)

The Oracle Problem in Software Testing: A Survey (IEEE TSE 2015)