Testing Pyramid as a Task Decomposition Tool for AI-Agents in QA Assist
The QA Assist system of 11 AI-agents faced a classic problem: a language model cannot cover an entire project in a single request due to context window limitati

Когда языковая модель становится тест-дизайнером, классическая теория QA неожиданно приобретает новое измерение. Именно об этом — третья статья Михаила Федорова в его серии о системе QA Assist, опубликованная на Хабре. На этот раз автор объясняет, почему пирамида тестирования, придуманная задолго до эпохи нейросетей, оказывается критически важной для AI-агентов с ограниченным контекстным окном.
QA Assist — система из 11 специализированных AI-агентов для автоматизации тестирования программного обеспечения. В первой статье серии Федоров описал архитектуру: как агенты разделены по ответственности, как взаимодействуют и что умеют. Во второй — честно показал реальность внедрения: задача, которая на бумаге выглядит как четыре часа работы, в корпоративной среде превращается в неделю согласований, встреч с безопасниками и правок инфраструктурного конфига.
Третья статья поднимается на уровень выше — к вопросу, как правильно формулировать задачи для AI, чтобы получить качественный и воспроизводимый результат. Пирамида тестирования — один из базовых принципов разработки. В основании лежат быстрые и дешёвые юнит-тесты, проверяющие функции и методы в изоляции.
В средней части — интеграционные тесты, проверяющие взаимодействие компонентов. На вершине — медленные и дорогие end-to-end тесты, имитирующие реальный пользовательский сценарий. Классическое соотношение: много юнитов, меньше интеграционных, минимум E2E.
Такая структура экономит время на запуск тестов и упрощает отладку: когда падает юнит, сразу понятно, что именно сломалось. Проблема возникает в тот момент, когда вместо инженера тесты проектирует языковая модель. LLM работает в рамках контекстного окна — фиксированного объёма токенов, который модель удерживает за один сеанс генерации.
Для небольших задач это некритично. Но если попросить нейросеть написать полный тестовый набор для большого приложения одним запросом, результат становится предсказуемым: либо часть бизнес-логики потеряется за краем контекста, либо модель выдаст поверхностные сценарии без погружения в реальные зависимости и граничные случаи. Именно здесь пирамида тестирования перестаёт быть теорией из учебника и становится практическим инструментом декомпозиции.
Метафора автора — скормить слона нейросети по кусочкам — точно описывает суть подхода. Большую задачу разбивают на слои согласно пирамиде: сначала агенты генерируют юнит-тесты на уровне функций, затем переходят к интеграционным сценариям, и только в финале — к E2E. Каждый слой умещается в контекстное окно модели и обрабатывается изолированно, без потери качества из-за переполнения контекста.
Такой подход даёт несколько конкретных преимуществ. Каждый запрос к модели становится фокусированным: агент получает чёткий скоуп, определённый контракт на вход и конкретный артефакт на выходе. Ошибки локализованы — если юнит-тест написан неверно, это видно немедленно, а не спустя несколько итераций, когда поверх него уже строится интеграционный сценарий.
Наконец, пирамида задаёт естественный порядок зависимостей: E2E строятся поверх проверенного фундамента, а не параллельно с ним. Федоров не претендует на изобретение колеса. Сам автор признаёт: это применение давно известного инженерного принципа к новому контексту.
Но в этом и главная мысль: AI не упраздняет базовые принципы разработки, а делает их ещё более значимыми. Понимание пирамиды тестирования теперь нужно не только QA-инженеру, но и тому, кто проектирует архитектуру запросов к языковым моделям. Для команд, которые рассматривают AI-инструменты для автоматизации тестирования, это практический урок: сначала спроектируй декомпозицию задачи, потом доверяй её модели.
Слон съедается по кусочкам — и это не ограничение технологии, а единственно рабочая архитектура.