LLM как помощник тестировщика: от экспериментов к ИИ агенту

Всем привет! На связи Арслан, тимлид команды тестирования компании «Совкомбанк Технологии». В этой статье я поделюсь опытом ^[1] успешного внедрения методов искусственного интеллекта ^[2] и больших языковых моделей (LLM) в тестирование программного обеспечения. 

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

Путь нашей команды начался с экспериментов с базовыми GPT-моделями и привел к созданию собственного ИИ агента для генерации тест-кейсов.

В этой статье рассмотрим:

• Как мы решали проблему языкового барьера и недостатка контекста у модели.

• Как техники промпт-инжиниринга повысили качество автоматически генерируемых тестов.

• Почему мы перешли о разовых экспериментов к полноценному внутреннему решению.

• Какие метрики эффективности получили и с какими вызовами столкнулись.

1. Начало: эксперименты с LLM «из коробки» 

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

На первом этапе мы использовали стандартные GPT-мдели без дообучения или интеграции с RAG (Retrieval-Augmented Generation). Основная цель — выяснить, насколько ИИ способен ускорить  ручное тестирование без сложных доработок.

1.1. Первые вызовы 

1.1.1. Языковой барьер 

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

1.1.2. Отсутствие контекста 

Модель не знала: 

• Бизнес-логику нашего приложения

• Особенности интеграций. Например, принципы работы с Госуслугами, системой быстрых платежей

• Требования регуляторов. Например, ЦБ РФ и PCI DSS

1.1.3. Сложность с промптами 

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

1.1.4. Безопасность данных 

Использование публичных LLM для работы с конфиденциальными банковскими данными было недопустимым. 

1.2. Решения 

1.2.1. Промпт-инжиниринг: структурированный подход 

Мы разработали шаблон для промптов, включающий: 

Task (Задачу)

• Начинайте с глагола действия: создать, написать, проанализировать

• Четко формулируйте цель

Пример: 

– Создай детальный чек-лист для тестирования функции восстановления пароля.

Context (Контекст)

Включает три ключевых аспекта:

• Биография пользователя: кто использует результат

• Определение успеха: что должно получиться

• Среда использования: где и как будет применяться результат

Пример:

– Для мобильного приложения интернет-магазина нужно проверить функцию восстановления пароля. Пользователь — среднестатистический покупатель с базовыми навыками работы с телефоном.

Examples (Примеры)

• Всегда предоставляйте примеры желаемого формата

• Это помогает ИИ лучше понять требования

Пример:

ID | Шаги | Ожидаемый результат

TC_01 | 1. Открыть страницу входа… | Пользователь успешно вошел в систему…

Persona (Персона)

• Определяет стиль ответа

• Конкретная роль

Пример:

– Опытный тестировщик с акцентом на функциональное тестирование.

Format (Формат)

• Укажите точный формат ответа

• Можно использовать табличную форму, списки, текстовые блоки

Пример формата:

Тип документа: Чек-лист

Структура: Номер | Действие | Критерий успеха

Tone (Тон)

• Определяет стиль общения

• Может быть формальным, неформальным, требовательным, дружелюбным

Пример тона:

«Профессионально-нейтральный тон для корпоративной документации»

1.2.2. Создание базы знаний и библиотеки промптов 

• База знаний: Документировали архитектуру, интеграции, требования регуляторов.

• Библиотека промптов: Шаблоны для типовых задач: генерация тестовой документации, анализ бизнес требований, объяснение кода и т. д.

1.2.3. Защищенная среда 

Развернули локальную LLM внутри корпоративного периметра, чтобы исключить утечки данных. 

2. От экспериментов к решению 

Здесь расскажу, как наша команда превратила разрозненные эксперименты в полноценное рабочее решение. Вы узнаете об архитектуре нашего ИИ-агента и его преимуществах перед ручными методами работы.

После успешных тестов был разработан внутренний ИИ агент для генерации тест-кейсов. 

2.1. Архитектура решения 

• Frontend: Веб-интерфейс с авторизацией через Active Directory / Keycloak.

• Backend: Интеграция с Qwen API для генерации тестов.

• Связь с инструментами: Автоматическая загрузка тест-кейсов в TestIT, получение данных задач из YouTrack и документации из Confluence.

ИИ-агент интегрирован в единый конвейер обработки требований — от автоматического парсинга входных данных (YouTrack, Confluence, документы) до валидации и выгрузки готовых тест-кейсов в TestIT, что сокращает ручные операции на 80%.

2.2. Преимущества 

•  Экономия времени: Генерация десятков тест-кейсов теперь занимает минуты (раньше — часы). 

• Масштабируемость: Легко адаптируется под новые проекты. 

• Стандартизация: Все тест-кейсы соответствуют единому шаблону. 

2.3. ИИ агент vs Библиотека промптов

Наглядное сравнение двух подходов поможет понять, в каких случаях стоит инвестировать в разработку собственного ИИ-решения, а когда достаточно библиотеки промптов.

2.4. Метрики эффективности:

Конкретные цифры, которые показывают, насколько эффективным оказалось наше решение и какие ресурсы потребовались для его реализации.

Затраты на разработку:

• Подготовка базовой библиотеки промптов: ~20 часов

• Создание и структурирование базы знаний: ~ 40 часов

• Разработка ИИ агента (включая интеграции): ~120 часов

• Тестирование и доработка решения: ~ 60 часов

Экономия времени в процессе использования:

Наибольшая эффективность достигается при комбинированном подходе, где ИИ агент используется для генерации базовых тест-кейсов, а QA-инженеры сосредотачиваются на сложных сценариях и проверке результатов. Такой подход дает совокупную экономию времени до 30% на работу с тестовой документацией при гарантированном качестве тестирования.

3. Заключение и дальнейшие шаги 

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

3.1. Итоги 

• GPT не заменит тестировщика, но может стать мощным инструментом для автоматизации рутинных задач.

• Качество генерации напрямую зависит от контекста и промптов. 

• Безопасность — критически важный аспект при работе с LLM в fintech. 

3.2 Следующие шаги:

• Интеграция с новыми LLM 

• Улучшение RAG подхода

• Внедрение MCP протокола

• Разработка новых ИИ агентов 

А вы используете LLM в тестировании? Делитесь опытом в комментариях!