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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Технологии:

• Rest Assured 5.x

• JUnit 5 (Jupiter)

• Maven

• Allure Framework

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

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

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

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- специалисты. Агенты уже сейчас могут закрыть бо́льшую часть рутинных задач, а в будущем смогут ещё больше: от генерирования тестовых сценариев из требований до анализа результатов прогона и заведения бага.

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

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

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

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

Спасибо за внимание!

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

Источник: habr.com