В одном B2C-департаменте Сбера насчитали больше 50 Java-фреймворков для автоматизации, хотя решали они примерно одни и те же задачи. На этом фоне ИИ в тестировании внезапно упирается не в качество модели, а в старую добрую корпоративную проблему: у каждой команды свой стек, свой синтаксис и свой маленький зоопарк.
Об этом сообщает Habr / Карьера со ссылкой на рассказ Владимира Михаленкова, который занимается развитием централизованного фреймворка автотестов в Сбере. Логика у кейса довольно приземлённая: пока внутри компании десятки однотипных инструментов, языковой модели сложно дать внятную задачу. Она не знает локальный контекст, не понимает внутренние соглашения и поэтому выдаёт не тот код, который реально можно взять, скомпилировать и запустить в конкретной команде.
Проблема, которую описывает Михаленков, знакома почти любой крупной разработке. Когда команды растут независимо, они начинают собирать свои инструменты вокруг похожих сценариев: оркестрация тестов, работа с API, проверки, отчёты, интеграции с базами и очередями. Формально это развитие экспертизы, по факту часто получается дорогая коллекция велосипедов. Переход инженера между командами требует адаптации к очередному локальному диалекту. Время уходит не на покрытие продукта тестами, а на дописывание инфраструктуры и разбор костылей, которые накопились под дедлайны, горящий регресс и конец спринта. Сбер формулирует это без особой романтики: параллельная разработка в таком режиме означает, что компания по сути много раз решает одну и ту же задачу разными способами.
Ответом стал централизованный подход на базе Perfeccionista-framework — открытого набора библиотек и оркестратора автотестов, который в компании взяли за основу и начали развивать дальше. По описанию автора, решение умеет изолировать окружение каждого теста, чтобы многопоточный запуск не смешивал контексты и ресурсы. Ядро можно оборачивать вокруг разных фреймворков, включая JUnit 4, JUnit 5, TestNG и Gherkin. Поверх этого в Сбере добавили то, без чего банковский QA быстро начинает нервно смеяться: работу с REST, базами данных, Kafka, базовую обвязку Allure и матчеры для ассертов. Идея не в том, чтобы всех насильно посадить на один инструмент за один день, а в том, чтобы дать общий слой, в который можно встроить привычные сценарии и перестать плодить почти идентичные решения.
Самое интересное начинается там, где к этому стеку подключают LLM. В теории запрос вроде «напиши автотест: GET, код 200, поле result = success» выглядит понятным. На практике модель легко ответит на Python, Kotlin или Java с любым набором библиотек, потому что ей никто не объяснил, в каком именно окружении должен жить результат. Для демо это нормально, для промышленного тестирования нет. Нужен код, который соответствует конкретному стеку, соглашениям и внутренним абстракциям. И вот здесь ИИ в тестировании натыкается на неприятный барьер: корпоративный фреймворк находится внутри защищённого контура, модель на нём не обучалась, а просто «доучить её на всём внутреннем» нельзя ни организационно, ни технически, ни с точки зрения контроля качества.
Схема, которую описывает Сбер, выглядит сейчас одной из самых практичных. Команда адаптировала документацию под работу с моделью, векторизовала её, положила в RAG и подключила к LLM через MCP-сервер. Дальше агент при запросе не гадает на кофейной гуще и не вспоминает случайный туториал из открытого интернета, а идёт за релевантным контекстом в корпоративное хранилище знаний. Модель получает не весь массив документации разом, а только те фрагменты, которые нужны для текущей задачи. Это снижает шум в контексте и позволяет насыщать систему внутренними знаниями без прямого переобучения базовой модели. Плюс подход масштабируется: каждая команда может держать собственный сервер с описанием своих инструментов и передавать этот контекст в общую LLM-инфраструктуру.
Но даже после этого магия не включается автоматически. Автор отдельно подчёркивает: если запрос сформулирован абстрактно, результат всё равно будет плавающим. Поэтому в центре истории не только RAG и MCP, но и банальный, местами скучный, зато очень полезный промпт-инжиниринг. Вместо «напиши тест» приходится задавать роль, стек, требования к endpoint, заголовкам, проверкам, логированию, вложениям в Allure, обработке сетевых ошибок и структуре проекта. И это уже важный сигнал для рынка. ИИ в тестировании не отменяет QA-инженера и не превращает автотесты в кнопку «сделать красиво». Он повышает цену предметного знания: нужно понимать продукт, инфраструктуру, ограничения фреймворка и уметь переводить всё это в точную инструкцию для модели. Иначе LLM будет писать гладкий, убедительный и совершенно бесполезный код.
Для разработчиков, QA-лидов и IT-руководителей вывод здесь довольно трезвый. Прежде чем подключать генеративный ИИ к инженерным процессам, неплохо бы разобраться с собственным технологическим бардаком. Иначе модель станет не ускорителем, а дорогим зеркалом, которое просто покажет масштаб внутренней несогласованности. Централизация фреймворков, единые соглашения, нормальная документация и понятные интерфейсы для инструментов в 2026 году выглядят не скучной платформенной рутиной, а условием, без которого автоматизация следующего поколения не взлетает.
Главный тезис Михаленкова звучит жёстко, но похоже на правду: будущий QA-инженер всё больше становится промпт-инженером с глубоким знанием домена. Вопрос уже не в том, придут ли языковые модели в автотесты, а в том, какие команды успеют подготовить для них среду, где модель действительно помогает работать, а не просто производит ещё один слой шума поверх старых костылей.