Пирамида тестирования как архитектура задач для ИИ-агентов

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

Пирамида тестирования — модель, которую QA-инженеры знают с первого года работы. Внизу — много дешёвых и быстрых тестов: unit-тесты отдельных функций, API-проверки изолированных эндпоинтов. Выше — системные тесты, которые проверяют пользовательские сценарии внутри одной информационной системы. На вершине — E2E-тесты, которые гоняют сквозной бизнес-процесс через несколько систем сразу. Главное правило: если цель проверки достижима на уровень ниже — делай там. Проверять расчёт комиссии через UI, открывая браузер и заполняя форму платежа, когда можно отправить POST /api/payments и посмотреть поле commission в ответе — расточительство.

Но пирамида — не просто «хорошая практика». Она вытекает из архитектуры продукта и иерархии требований. Task описывает, что делает конкретный компонент — backend-эндпоинт или форма на фронтенде. User Story описывает, как пользователь взаимодействует с системой. Feature описывает бизнес-процесс, который затрагивает несколько систем сразу. Каждый уровень требований порождает свой уровень тестов — и свой объём контекста, который нужно передать модели.

Автор QA Assist Михаил Фёдоров разбирает это на примере фичи «Промокоды при оформлении заказа». Один Feature затрагивает три информационные системы — магазин, личный кабинет и админку — и порождает компонентные тесты для каждого backend и frontend-компонента, системные тесты для каждой User Story и E2E-тесты для всей фичи целиком. На уровне компонентного теста модели достаточно знать спецификацию одного эндпоинта: POST /orders/apply-promo принимает код, валидирует его, возвращает скидку или 400 с описанием ошибки. Контекст компактный, задача чёткая — LLM справляется хорошо. На уровне E2E модель должна понимать, как магазин, личный кабинет и админка взаимодействуют между собой, какие данные передаются на каждом шаге и что именно нужно проверить на границах систем. Контекст вырастает многократно.

Это объясняет наблюдение, которое часто списывают на «галлюцинации» или общую ненадёжность языковых моделей: LLM закономерно хуже справляется с задачами верхних уровней пирамиды. Не потому что модель плохая, а потому что E2E-тест требует контекста, который физически не помещается в окно или теряет связность при большом объёме. Решение, которое применяет QA Assist, — декомпозиция по уровням пирамиды. Агенты системы получают задачи порциями: сначала компонентные тесты по отдельным Task, затем системные по User Story, и только потом E2E по Feature. Каждый раз модель работает с минимально необходимым контекстом для своего уровня.

Подход перекликается с общей логикой работы с LLM в production-системах: большие задачи нужно дробить не произвольно, а по смысловым границам, которые уже заложены в архитектуре продукта. Пирамида тестирования как раз и задаёт эти границы — она существовала задолго до языковых моделей, но оказалась удобным интерфейсом между структурой требований и возможностями ИИ-агента.