Автоматизированное тестирование нового поколения: как ИИ меняет жизнь тестировщика

В крупных компаниях зоопарк фреймворков автоматизации убивает эффективность. Мы создали централизованное решение на основе Perfeccionista‑framework, подключили к нему RAG и MCP‑сервер для работы с LLM, и теперь языковые модели понимают контекст наших тестов. Главный вывод: будущий QA‑инженер — это промпт‑инженер с глубокими предметными знаниями

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

Меня зовут Владимир Михаленков, моя основная деятельность — разработка и тиражирование централизованного фреймворка автоматизированного тестирования в Сбере. Расскажу, как мы обуздали технологический зоопарк и научили языковые модели понимать, чего от них хотят QA‑инженеры.

Как разнообразие инструментов тормозит тестирование

На Земле существует около 7 000 языков, на которых общаются более 3 500 этнических групп. Языков программирования более 4 000, а инструментов для разработки и тестирования ещё больше. Казалось бы, просто занимательная статистика, но она очень наглядно проецируется на мир ИТ.

Есть многонациональные страны, а есть крупные компании с огромным зоопарком технологий. Есть государства, ограниченные несколькими этносами, — так же как небольшие фирмы с минимально необходимым инструментарием.

Проблематика такого разнообразия:

Сложная адаптация при переходе между командами. Один технологический стек далеко не всегда бесшовно интегрируется в другой. С одной стороны, для роста сотрудника это плюс — расширяет компетенции. С другой — временные затраты на обучение ^[1] и простой в работе.

Массовое изобретение велосипедов. Команды тратят уйму времени на описание одних и тех же операций, используя разные слова и собственный синтаксис. На выходе — та же функциональность, но иначе оформленная.

В одном только департаменте B2C мы получили более 50 разных фреймворков автоматизации на Java, решающих практически идентичные задачи. Параллельная разработка в таком формате — это всегда трата денег и времени. И это не про запуск пачки тестов в многопоточном режиме, где каждый поток выполняет полезную уникальную задачу. Здесь мы, по сути, гоним параллельно один и тот же тест, только написанный по-разному.

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

Итог: велосипеды, дубли, костыли и толпа однотипных фреймворков.

Один фреймворк, чтобы править всеми

В этот момент в наших головах было посеяно зёрнышко сомнения, и мы начали думать: а что со всем этим делать? Правильно: написать ещё один фреймворк, но такой, который инкапсулирует в себе лучшие решения и практики из остальных.

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

• Как оркестрировать тесты?

• Как запускать многопоточно, чтобы не пересекался контекст?

• Смогут ли пользователи легко расширить решение, если чего-то не хватит из коробки?

• Совместимо ли оно с существующими инструментами?

Нам крупно повезло: у коллеги уже были ответы. Так появился Perfeccionista-framework ^[2] — набор библиотек и оркестратор автотестов с открытым кодом, который решает эти проблемы на корню.

Коротко о главном:

• Ограничение окружения (environment) каждого теста. Позволяет запускать тесты многопоточно без риска разделения ресурсов и контекста между потоками

• Ядро можно обёртывать вокруг любого фреймворка: JUnit 4, JUnit 5, TestNG, Gherkin и так далее

• Бесконечная расширяемость архитектуры. Именно этим мы и занимаемся, потому что на одной оркестрации далеко не уедешь.

Мы начали оборачивать Perfeccionista всем самым популярным и необходимым:

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

• Добавили работу с REST, БД, Kafka, базовую обёртку Allure.

• Разработали матчеры для удобных ассертов.

• Собрали по крупицам всё, что нужно QA-инженерам в банке: от прикладных технологий до работы со специфическими автоматизированными системами.

При чём тут ИИ?

Примерно здесь вы начинаете замечать неладное и смотреть с подозрением: «Мы про новую эру в автотестах пришли послушать, про ИИ поговорить, а ты нам про джаву и классические фреймворки рассказываешь». И будете правы. Но без контекста дальше будет сложно.

Кто пользуется ИИ? (опрос, который я провёл в зале)

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

Викторина «Побудь в шкуре языковой модели»

На митапе я провёл викторину, и вы тоже можете в ней поучаствовать. Задача: Представьте, что вы — языковая модель, и получили запрос:

Напиши автотест: GET на example-address.ru ^[3], проверь код 200 и поле result со значением success.

На выбор три варианта ответа:

1. лаконичный на Python;

2. лаконичный на Kotlin;

3. подробный на Java с RestAssured.

Голоса распределились по-разному, но всегда с перевесом в одну сторону.

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

Мы попадаем в ловушку: модель из коробки не знает, что конкретно вы от неё хотите.

Ловушка Джокера: модель и контекст

Модель ничего не знает про контекст нашего фреймворка, потому что он находится в контуре банка и на нём она не обучалась. Есть серьёзные ограничения, которые не позволяют напрямую дообучать модель на всём, что внутри периметра.

Одно из главных ограничений: модель нельзя произвольно переобучить или не дообучить. Эта проблема касается многих компаний. Вы скажете: «Ну, это всего лишь один фреймворк, про него не так много информации». Верно. Но только представьте, сколько инструментов из смежных областей существует. Дообучение на них может очень сильно исказить поведение ^[4] модели.

Наше решение: единый подход и единый (хоть и не полностю унифицированный) техстек. Мы не даём модели вариативности — она отлично работает с понятными прямолинейными инструкциями. Но дать ей информацию про конкретный контекст мы не можем, упираемся в ограничения. Вот такая ловушка Джокера.

Как мы выкрутились

Мы адаптировали документацию под работу с моделью, векторизовали её и положили в RAG (Retrieval-Augmented Generadon). Вся эта конструкция подключается к модели через MCP-сервер.

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

• не перегружать контекст самой модели;

• при необходимости до бесконечности насыщать её своим специфическим контекстом.

Любая команда может сделать собственный сервер, где будет храниться контекст её инструмента, и передать его в общую модель. Resolved, done!

Но не тут-то было.

Самые продвинутые скажут: «Инструмент и инструмент, RAG’ом сыт не будешь. На тот абстрактный запрос даже с контекстом фреймворка не будет конкретного ответа». И снова будут правы.

Промпт-инжиниринг: превращаем абстракцию в конкретику

Вот так мы плавно подобрались к тому, как меняется жизнь тестировщика сегодня.

С фреймворком понятно: контекст чёткий и ясный. Но даже с ним без достаточно проработанного промпта результат не будет таким, как вы ожидаете. А если единого подхода или централизованного продукта нет?

Мир меняется, технологии и подходы — тоже. Это значит, что нам самим необходимо меняться. И, возвращаясь к нашей теме: вы просто обязаны в какой-то степени стать промпт-инженерами. В идеале — уже быть ими. Где и как получить этот навык — выбор каждого. Интернет переполнен руководствами, статьями и книгами. Всё в ваших руках.

Вернёмся к нашей задачке. В чём была ошибка ^[5] первого запроса?

Напиши автотест, в котором отправляется GET-запрос… Проверяет, что код ответа = 200… и значение success…

Правильно: абстрактно, без ролей и конкретики. Как модель должна выбирать, если ей не дали инструкций? Конечно, на свой вкус ^[6] и цвет.

А теперь переработаем запрос так, чтобы он дал ожидаемый ответ:

Ты — senior QA automation engineer на Java. Напиши полноценный автотест с использованием следующего стека

Технологии:

• Rest Assured 5.x

• JUnit 5 (Jupiter)

• Maven

• Allure Framework

• SLF4J для логирования

Требования к тесту:

1. Отправь GET-запрос на endpoint: hyps://api.example.com ^[7]

2. Добавь заголовки: Content-Type: application/json, Accept: application/json

3. Проверь статус-код ответа = 200

4. Проверь, что Content-Type ответа = application/json

5. Проверь, что JSON-ответ содержит поле result со значением success

6. Оберни выполнение запроса в Allure step с описанием

7. В случае неудачи: прикрепи к отчёту Allure attachment с полным ответом сервера, с деталями запроса (URL, заголовки, параметры), и залогируй ошибку через SLF4J

8. Добавь обработку исключений для сетевых ошибок

9. Используй чистый Java-код с соблюдением best pracùces

Дополнительно:

• Предоставь pom.xml с зависимостями

• Покажи структуру тестового класса

• Добавь комментарии к ключевым частям

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

По сути, это стирает границу между ручным тестировщиком или тестировщиком-автоматизатором и промпт-инженером. Чтобы написать автотест, нужно научиться использовать качественный промпт (включая входные данные и сценарий), а затем проверить, правильный ли результат. Даже больше: можно отправить сгенерированный тест в другую модель или агент и попросить проверить.

Будущее QA-инженера: от рутины к инженерии

Что это значит для всех нас? Лишь то, что востребованы будут фуллстеки и T-shaped- специалисты. Агенты уже сейчас могут закрыть бо́льшую часть рутинных задач, а в будущем смогут ещё больше: от генерирования тестовых сценариев из требований до анализа результатов прогона и заведения бага.

Следующий этап — это даже не столько промптирование (оно должно стать базовым навыком), сколько глубокие знания в прикладных областях. Потому что нужно будет эти самые модели настраивать, докручивать и контролировать.

Проведу аналогию с автомобильным заводом. Роль ручного закручивания гаек больше не требуется, это делает робот. Но нужен человек, чтобы этого робота спроектировать, настроить и обслужить.

Не читайте это как: «человек больше не будет нужен». Читайте как: «мы живём в очень динамично развивающемся мире, и этот мир диктует правило: развиваюсь я — развивайся и ты вместе со мной».

Обретайте новые навыки, изучайте тренды рынка, и вы всегда будете востребованными специалистами.

Спасибо за внимание ^[8]!

Делитесь в комментариях: используете ли вы языковые модели в тестировании и как справляетесь с проблемой контекста? Давайте обсудим, куда движется профессия.