Почему тесты проходят, но система всё равно сломана
Классы скрытых ошибок в QA automation, которые не приводят к падению CI
Пайплайн прошёл. Логи без ошибок. Значит всё работает.
Но в реальных QA automation системах это предположение часто не выдерживает проверки.
Тесты могут проходить, даже если система сломана.
И это не редкий edge case. Есть несколько типов проблем, которые не приводят к падению CI:
False positives — тест подтверждает поведение, которое уже не соответствует бизнес‑логике. Проверка формально зелёная, смысл потерян.
Missing assertions — тест проходит, потому что не проверяет ничего критичного.
Flaky suppression — флаки ретраят или игнорируют. Шум скрывает реальные проблемы, CI выглядит стабильным.
Duplicated execution — один и тот же набор тестов запускается несколько раз из‑за конфигурации runner'а.
Contract drift — API или поведение системы меняется, но тесты продолжают проверять старые ожидания. Пока не появится явный конфликт — всё зелёное.
В проекте была добавлена пагинация к одному из API эндпоинтов. До изменения ответ выглядел так:
json [{ "id": 1 }, { "id": 2 }]
После — так:
{ "data": [...], "total": 10, "page": 1, "limit": 20 }
API тесты не упали: они проверяли статус и структуру нового формата — всё корректно.
Я была уверена что если API возвращает 200 и схема верна — клиент получает данные.
Но в клиентском коде была строка:
cachedRows = Array.isArray(rows) ? rows : []
Для объекта Array.isArray возвращает false. Список записей стал пустым.
Формально всё работало корректно. Просто данных больше не было.Никаких ошибок в консоли. Никакого 500. Просто пустая страница.
CI остался зелёным — потому что API тесты проверяли API, а не то, как клиент использует ответ.
Дальше сработал каскад: fixture teardown тоже вызывал этот эндпоинт, получал объект вместо массива, не чистил данные — и следующие тесты падали с совершенно другой ошибкой, в совершенно другом файле.
Три теста упали из-за одного изменения shape ответа.
Ни один из них не указал на настоящую причину.
Почему CI это не ловит
CI отвечает на вопрос: «выполнились ли тесты без ошибок?»
Но не отвечает на: «имеют ли тесты смысл относительно текущей системы?»
CI реагирует только на падения. Он не знает про бизнес-инварианты, не отслеживает правильность выполнения и не видит contract drift.
Что с этим делают в зрелых системах
Начинают появляться дополнительные слои:
контрактные тесты (contract testing) — фиксируют ожидания потребителя API
явно наблюдаемость тестов — метрики не как %, а как сигналы поведения
контроль изменений API через diff-инструменты
Ни один из них не заменяет хорошие тесты. Но каждый закрывает слепое пятно, которое тесты не видят.
Финальный вывод
Тесты не доказывают, что система работает.
Они только доказывают, что система не сломалась определённым способом.
Признаки сбоя
CI зелёный
UI показывает пустой список
API возвращает 200
fixture teardown не чистил данные, занимал слот
Скрытое предположение
«Я решила что статус 200 означает, что потребитель по‑прежнему правильно читает ответ»
Как это выглядит в реальной системе
Contract drift — один из тех классов ошибок, которые можно воспроизвести намеренно. В проекте есть buggy branch именно с этим кейсом: API возвращает изменённый shape ответа, все API тесты зелёные, но клиентский код получает пустой список — без ошибок, без 500, просто тишина.
Код и структура проекта: GitHub
Из серии «Тихие отказы в тест-автоматизации»
Разборы таких кейсов с кодом — в Telegram-канале Тесты как система
