Фаза 10Курс ADLC

Фаза 10. Testing: агент-QA берёт стратегию и прогон

Код прошёл ревью и смёржен. Теперь — проверка, что продукт делает то, что обещали: тест-стратегия, кейсы, регрессия, вердикт готовности к релизу. Фаза QA.

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

Роль человека сегодня

QA-инженер или SDET: строит тест-стратегию, пишет кейсы и автотесты, гоняет регрессию, проводит приёмочное тестирование, выносит вердикт «готово ли к релизу». Классически — смесь ручного и авто-тестирования, тест-планы, баг-репорты, роль привратника качества у релиза.

Разложим. Генерация тест-кейсов из требований — механическая работа. Прогон — давно машинный. Поиск краевых случаев — комбинаторика, где машина сильнее. А вот одно звено особое: кто-то должен знать, каким должен быть правильный ответ. Это оракул — и он есть слабое место тестирования в принципе, не только у агента.

Что передаём агенту

QA-агент держит роль качества. Из prd/backlog с критериями приёмки он выводит тест-стратегию, генерирует кейсы от unit до e2e, гоняет их, находит дефекты и заводит их обратно на доску, выносит вердикт release-readiness. Он решает не «прогнать тесты», а «достаточно ли покрыт риск, чтобы катить».

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

Архитектура агента

State-machine фазы

Входы

prd/backlog с acceptance criteria (ф.4), architecture (ф.5), собранное приложение после ревью (ф.9).

Агент держит роль

Инструменты: генерация тест-кейсов; автотест-раннеры; e2e и браузерная автоматизация; фаззинг; анализ покрытия; заведение багов в трекер.

Артефакт

тест-стратегия + набор автотестов + отчёт покрытия + вердикт release-readiness.

Передача дальше: вердикт готовности → Release (ф.11); заведённые дефекты → Planning и Implementation (ф.7 / ф.8). Вердикт release-readiness как артефакт — это то, что раньше жило суждением человека-QA. Агент делает его явным и обоснованным: не «вроде готово», а «покрыты такие-то риски на таком-то уровне, вот непокрытое, вот моя оценка готовности». Суждение о готовности перестаёт быть непрозрачным.

Входы: prd/backlog с acceptance criteria (ф.4), architecture (ф.5), собранное приложение после ревью (ф.9).
Инструменты: генерация тест-кейсов; автотест-раннеры; e2e и браузерная автоматизация; фаззинг; анализ покрытия; заведение багов в трекер.
Артефакт: тест-стратегия + набор автотестов + отчёт покрытия + вердикт release-readiness.
Триггер: код прошёл ревью (ф.9) / собран билд.
Передача дальше: вердикт готовности → Release (ф.11); заведённые дефекты → Planning и Implementation (ф.7 / ф.8).

Вердикт release-readiness как артефакт — это то, что раньше жило суждением человека-QA. Агент делает его явным и обоснованным: не «вроде готово», а «покрыты такие-то риски на таком-то уровне, вот непокрытое, вот моя оценка готовности». Суждение о готовности перестаёт быть непрозрачным.

Где ломается

Оракул-проблема. Тест проверяет поведение против ожидаемого — но кто сказал, каким должно быть ожидаемое? Если и требования писал агент (ф.4), и тесты пишет агент, возникает замкнутость: система проверяет себя против собственного представления о правильном. Согласованность не равна корректности. Это не слабость конкретной модели — это структурная дыра, общая с человеческим QA; просто у людей она пряталась за занятостью тестировщика, а здесь обнажается.

«Зелёные тесты ≠ работающий продукт». Агент проверяет то, что придумал проверять. Неизвестные-неизвестные — риски, которые никто не догадался заложить в стратегию, — вне поля. И «ощущение» продукта (удобно ли, не раздражает ли) плохо ловится тест-кейсом.

Ответственность за пропущенный дефект. Дефект, доехавший до пользователя, — вопрос ответственности. Агент расширяет покрытие, но не становится тем, с кого спрашивают за пропуск.

Что остаётся человеку

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

остаток человека ≈ 33%

Провокация / тезис

Тестирование — это генерация и проверка гипотез о поведении системы против спецификации; всё это агент делает шире, быстрее и непредвзятее человека. Слабость фазы не в исполнении, а в оракуле: кто определяет правильный ответ. И это не новая проблема, созданная AI, — это старая дыра тестирования, которая у людей маскировалась дефицитом внимания тестировщика, а в автономном контуре выходит на свет. Незаменимо не тестирование, а оракул для критичного — и он приходит от человека там, где ошибиться нельзя.

Сквозной кейс

«Витрина» на этой фазе

QA-агент строит для «Витрины» сквозной e2e-сценарий: гость собрал витрину → покупатель оформил заказ → прошла оплата → пришло уведомление. Гоняет его на каждом билде. И именно здесь ловится подтверждение того, что ревью (ф.9) вернуло на доработку: QA-агент прогоняет краевой случай с повторным вебхуком оплаты — и проверяет, что после фикса идемпотентности заказ не дублируется. Регрессия на платёжный контур теперь в наборе навсегда, бесплатно, на каждом билде.

Но обратите внимание на границу. QA-агент проверяет, что заказ «оплачен» согласно тому, как правильное поведение описано в требованиях. Если само определение «когда заказ считается оплаченным» было бы ошибочно уже в PRD — агент честно оттестировал бы неверную спецификацию и выдал зелёный вердикт. Здесь оракул для платёжного контура — то место, где фаундер «Витрины» один раз говорит «правильно вот так», и это единственная точка фазы, которую нельзя отдать агенту. Артефакт → тест-стратегия + прогон «Витрины», вердикт готовности.

На практике

Как это устроено — инженерные разборы

Отдельные howto из практики, где фаза показана на работающем коде и артефакте.

Eval как release-критерий: как ловить agent drift до прода, а не послеEval как release-критерий — это и есть оракул из фазы тестирования.

Читать дальше

Строите AI-driven доставку у себя?

Проектирование ADLC-контура: где агент держит роль, а где остаётся человек-принципал — под вашу команду и продукт.

Написать на почту

Движок перехода

Next Move Engine — система, которая доводит команду до автономного цикла доставки.

Next Move Engine →