Почему традиционный QA не поспевает за AI-разработкой

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

Это не парадокс. Это предсказуемый результат ускорения одной половины жизненного цикла при нетронутой второй. Написание кода подешевело. Доказательство того, что он работает, — нет. Эта статья о том, почему традиционное обеспечение качества — практики, инструменты, оргструктура — не может закрыть этот разрыв, не изменив форму, и что значит «изменить форму».

Асимметрия, которую никто не планировал

QA строился вокруг скрытой предпосылки: производить изменения дорого и медленно, поэтому проверять их можно примерно так же дорого и медленно. Команда, писавшая несколько сотен строк в день, могла сопровождаться QA-функцией, проверявшей несколько сотен строк в день. Они масштабировались вместе.

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

Три предпосылки, которые больше не выполняются

Традиционный QA не столько ошибочен, сколько устарел. Он держится на трёх предпосылках, разумных десять лет назад и ложных сейчас.

Предпосылка 1: кто-то может поддерживать тесты

Любой набор тестов, требующий человеческого авторства, масштабируется с человеческим трудом. Когда инженеры писали код медленно, команда QA держала набор примерно актуальным. Когда команда с ИИ мёржит крупные диффы по многим поверхностям каждый день, рукописные наборы отстают в первый же день и не догоняют.

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

Предпосылка 2: продукт достаточно стабилен для тестирования

Классические end-to-end тесты предполагают, что UI стоит на месте между релизами. UI, созданный ИИ, на месте не стоит. Компоненты перегенерируются, тексты меняются, макеты перестраиваются, селекторы переезжают. Тесты, привязанные к конкретной структуре DOM, тратят больше времени на ремонт, чем на отлов реальных дефектов, и команда учится не доверять красной сборке.

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

Предпосылка 3: рискованный код — тот, что вы написали

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

Покрытие строк говорит, что строка выполнилась. Оно ничего не говорит о том, работает ли ещё поведение, от которого зависит пользователь. Набор может быть зелёным на 90% и полностью слепым к сломавшемуся чекауту, потому что тест проверял, что функция запустилась, а не что клиент смог заплатить.

Что реально нужно, чтобы «поспевать»

Если проблема в асимметрии, решение — дать QA тот же рычаг, что изначально ускорил разработку. Конкретно, должны стать истинными три вещи.

Покрытие должно генерировать себя. Если каждый тест пишет человек, вы снова в линейном узком месте. Единицей покрытия должно быть намерение — «вернувшийся пользователь может завершить чекаут», — и система должна выводить и заново выводить конкретные шаги при изменении продукта. Это разница между описанием поведения и описанием мебели.

Результаты должны быть надёжными без разбора. Набор, который сообщает о расхождениях, но не отличает реальный сбой от шума, лишь переносит человеческое узкое место с написания тестов на чтение ложных тревог. Сбои нужно воспроизводить и подтверждать до того, как они дойдут до человека, чтобы красный результат надёжно означал «что-то реально сломано».

Проверка должна идти непрерывно, а не в фазе. Предрелизные QA-ворота — это пакетный процесс, а пакетные процессы ограничивают пропускную способность. Когда изменения непрерывны, проверка тоже должна быть непрерывной — это отдельная дисциплина со своими компромиссами, разобранная в статье Непрерывное тестирование против непрерывного мониторинга.

Форма QA, которая масштабируется

Сложите это — и картина меньше похожа на «фазу в конце» и больше на «систему, идущую рядом с разработкой». Продукт подключают; система изучает его потоки, ранжирует их по влиянию на бизнес, генерирует end-to-end покрытие и держит его актуальным по мере изменений кода — подтверждая реальные сбои и прикладывая вероятные причины, а не вываливая на команду сырые расхождения.

Это категория, под которую создан BuniOD: quality-аналитика, масштабирующаяся вместе с разработкой на скорости ИИ, а не раздавленная ею. Смысл не в том, чтобы убрать людей из качества, а в том, чтобы перестать тратить человеческое внимание на механику (поддержку селекторов, перезапуск чек-листов, разбор флаки-результатов) и направить его туда, где нужно суждение.

Возражения, которые стоит принять всерьёз

Два возражения возникают часто, и оба справедливы.

«Разве AI-тесты не будут иметь те же баги, что и AI-код?» Могут, если тесты выведены из того же ошибочного намерения. Средство — заземление: покрытие нужно выводить из наблюдаемого поведения продукта и его критичных для бизнеса потоков, а не из пересказа кода. Тест, проверяющий, что «итог равен сумме позиций минус скидки», заземлён в бизнес-правиле, а не в том, что случайно вычислила реализация.

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

Конкретный пример: дифф, который никто толком не прочитал

Вот как разрыв проявляется на практике. Продакт-менеджер с ИИ-ассистентом выпускает изменение онбординга — добавляет шаг, предзаполняющий данные компании по домену email. Это 180 строк в четырёх файлах. У него работает. Два ревьюера аппрувят за пару минут каждый, читая в основном описание, а не логику. Мёржится и деплоится.

Дефект: для пользователей, чей домен не резолвится в известную компанию, шаг предзаполнения бросает исключение, и ошибку глотает try/catch, ничего не логирующий. Эти пользователи видят пустой шаг и уходят. Регистрации из этого сегмента тихо падают на 15%.

Пройдёмся, почему традиционный QA это упускает. Нет упавшего юнит-теста, потому что счастливый путь работает. Ручная регрессия не покрывает, потому что поток новый — нет прошлой версии для регрессии, и никто ещё не написал ручной кейс для ветки с нерезолвящимся доменом. Покрытие строк выглядит нормально, потому что путь выполняется в счастливом случае. Все классические сигналы зелёные, а реальный сегмент пользователей сломан.

Поймало бы это покрытие, выведенное из намерения потока — «новый пользователь может завершить онбординг», — прогнанное с реалистичной вариацией входов, включая нерезолвящийся домен. Это не тест, который кто-то должен был вспомнить написать; это свойство потока онбординга, которое сгенерировала бы и держала актуальным система, исследующая продукт. Дефект не экзотический. Это ровно та тихо сломанная ветка, что становится обычной, когда изменения выходят быстрее, чем кто-либо успевает их полностью прочитать.

Заключение

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

«Поспевать» не значит нанять больше тестировщиков или писать больше скриптов; и то и другое масштабируется линейно против экспоненциального входа. Это значит сменить единицу покрытия на намерение, сделать это покрытие самоподдерживающимся, валидировать сбои до человека и вести проверку непрерывно, а не в фазе. Команды, совершившие этот сдвиг, превратят свою новую скорость в отгруженный прогресс. Те, кто нет, продолжат превращать её в риск — недоумевая, почему движение быстрее не ощущается как улучшение.

Если хотите увидеть, как выглядит обеспечение качества, масштабирующееся вместе с AI-разработкой, а не против неё, — именно это призван показать BuniOD.