Читайте в Telegram
|
Во многих компаниях уверены, достаточно подключить нейросеть, и тестирование ускорится. В ГК MD Audit подошли к этому вопросу иначе: сначала создали единый контекст, описали правила, дали агентам инструменты, а контроль оставили за человеком.
Результат: оформление баг-репорта сократилось с пяти до одной минуты, а объем задач, на который раньше уходила неделя, теперь закрывают за пару дней. Как построить систему, где ИИ не эксперимент, а рабочий инструмент, рассказывает Екатерина Гаврилова, QA Tech Lead MDA в MD Audit (ГК Softline).
Как мы собрали единый контекст
Работа с искусственным интеллектом в команде QA - это не просто написание промпта. Чтобы ИИ стабильно приносил пользу, необходимы взаимосвязанные элементы: контекст, правила, инструменты и контроль.
Контекст определяет, что ИИ знает о системе. Речь не об архиве документов, а о единой модели продукта, которая включает роли пользователей, матрицу доступа, бизнес-логику, связи между сущностями, требования к тестовой документации и накопленные знания команды. Чтобы создать такую модель, мы начали не с выбора модели ИИ, а с аудита источников: собрали техническую документацию, материалы из Confluence, требования и знания ведущих специалистов. Все это мы свели в единый Git-репозиторий в формате Markdown - там хранятся описание системы, ролевая модель, бизнес-правила и эталонные шаблоны тестовых артефактов (чек-листов, тест-кейсов, баг-репортов), а Git обеспечивает контроль версий и возможность отката.
База знаний постоянно обновляется, при появлении новой функциональности сначала создаем ее описание, затем актуализируем материалы по затронутым модулям, и, после проверки, изменения попадают в основную ветку репозитория. Такой подход поддерживает единую версию знаний, доступную и специалистам, и ИИ-агентам.
Формирование тестовых артефактов тоже автоматизировано. Если раньше чек-листы и тест-кейсы нам приходилось писать вручную и переделывать при каждом изменении требований, то теперь ИИ-агент на основе актуального контекста готовит первую версию, а тестировщик проверяет, дополняет и корректирует ее. Это сокращает рутинную работу и помогает держать документацию в актуальном состоянии без лишних усилий.
Инструменты и MCP: от генерации текста к выполнению действий
Если ИИ ограничен текстовой генерацией и не может выполнять операции в целевых системах, его практическая ценность снижается. Требуется агент, способный создавать тестовые данные, заводить задачи в Jira, запускать проверки в браузере, обращаться к API - то есть выполнять действия, аналогичные действиям тестировщика, но с большей скоростью и без человеческого фактора.
До внедрения системного подхода в Softline (MD Audit) мы фиксировали типичные проблемы: документация устаревала быстрее, чем обновлялась, автотесты отставали от релизного цикла, создание новых проверок постоянно откладывалось. При этом была четко определена граница автоматизации: формализуемые процессы передаются агенту, тогда как исследовательское тестирование, поиск нестандартных сценариев и принятие решений в неоднозначных ситуациях остаются за человеком.
Для интеграции с внешними сервисами наша команда использует открытый протокол Model Context Protocol (MCP), который позволяет подключать ИИ к файловой системе, API, базам данных и корпоративным сервисам. Достаточно один раз описать правила взаимодействия с конкретным инструментом, после чего агент выполняет необходимые действия по простой команде.
Одной из первых интеграций стала с Jira. Раньше подготовка полноценного баг-репорта со скриншотами, шагами воспроизведения, ожидаемым и фактическим результатом занимала до пяти минут. В течение дня число таких отчетов может достигать нескольких десятков. Теперь тестировщик кратко описывает проблему в свободной форме, агент с использованием контекста и шаблона формирует готовый отчет. Специалисту остается проверить и при необходимости скорректировать. Время оформления дефекта сократилось до одной минуты.
По тому же принципу организована подготовка тестовых данных. Агент знает, какую функциональность необходимо проверить, понимает структуру системы и умеет создавать нужные объекты через API или пользовательский интерфейс. Тестировщик описывает сценарий, после чего агент формирует JSON-запрос, отправляет его через API и возвращает идентификаторы созданных сущностей, которые сразу можно использовать в тестировании.
Также мы настроили интеграцию с Playwright, этот инструмент применяется не только для автотестов, но и во время ручного тестирования. Пока специалист анализирует новую функциональность и сложные сценарии, агент параллельно выполняет типовые проверки в браузере. Для этого тестировщик передает последовательность действий и ожидаемый результат, после чего получает отчет о выполнении сценария и найденных отклонениях.
Это не замещает исследовательское тестирование, но снимает значительный объем повторяющейся работы. Само распределение задач в команде изменилось, пока одни специалисты занимаются архитектурным анализом и оценкой рисков, ИИ готовит тестовые данные, прогоняет типовые сценарии и оформляет дефекты.
Обучение команды как ключевой фактор внедрения
Наиболее сложным препятствием оказался не технический, а человеческий аспект. Архитектура и интеграции настроены и функционируют, но первые результаты в нашей команде появились у тех, кто глубоко знал продукт и активно экспериментировал. Остальным специалистам было сложнее - доступ к ИИ не гарантировал результат.
Поэтому следующим этапом стало обучение. Мы отказались от разовых лекций в пользу регулярного практического цикла. Новый ИИ-инструмент сначала показываем на короткой встрече, затем каждый сотрудник применяет его на учебной или рабочей задаче. После этого команда разбирает результаты: что получилось, где возникли ошибки и как можно улучшить подход, а затем цикл повторяется уже на другом сценарии.
Мы проводим групповые сессии и индивидуальные разборы «один на один». Второй формат особенно эффективен, когда специалист освоил базовые возможности, но не использует весь потенциал инструмента. Совместный разбор одной-двух реальных задач, демонстрация формулировки запросов и интерпретации ответов, корректировка действий агента - после такого взаимодействия сотрудник начинает самостоятельно находить новые способы автоматизации.
Регулярные встречи QA-команды также нам помогают. На них мы обсуждаем завершенные задачи, разбираем успешные промпты и инструкции, новые интеграции и практические результаты. Обмен опытом позволяет быстро тиражировать успешные подходы внутри команды и не ограничивать использование ИИ несколькими энтузиастами.
Об измеримых результатах
Любую автоматизацию имеет смысл оценивать не по количеству внедренных инструментов, а по тому, как меняется скорость и качество работы команды. В Softline (MD Audit) мы проводили измерение ключевых метрик до и после внедрения.
Самый заметный эффект связан с оформлением дефектов в Jira. Если раньше подготовка одного баг-репорта со скриншотами, шагами воспроизведения и описанием результатов занимала до пяти минут, то теперь агент выполняет основную часть работы примерно за минуту. Тестировщик проверяет готовый отчет и при необходимости вносит изменения.
Изменился и объем задач, которые команда успевает выполнить за то же время. Например, при тестировании крупной задачи, содержащей около 20 дефектов, ранее могла уходить неделя, а сейчас та же работа закрывается за пару дней.
Качество тестовой документации также улучшилось. Чек-листы и тест-кейсы больше не приходится регулярно переписывать после изменений в продукте, так как они создаются на основе актуальной базы знаний и обновляются вместе с ней. Команда тратит меньше времени на поддержку документов и больше - на их проверку и развитие.
Архитектура при этом остается независимой от конкретной языковой модели. Для Jira, Confluence и других корпоративных сервисов используются отдельные MCP-серверы, взаимодействие с которыми построено по единому принципу. Основная логика сосредоточена в базе знаний, инструкциях и сценариях работы, поэтому при необходимости языковую модель можно заменить без перестройки процессов.
Часть архитектурных решений мы намеренно не разглашаем. Например, MCP не подключается напрямую к производственным пайплайнам, а работа с корпоративными документами соответствует внутренним политикам безопасности. Эти ограничения не мешают использовать ИИ в ежедневной работе и получать измеримый эффект.
Вывод
За последние два года вокруг ИИ сформировалось множество ожиданий. Часто кажется, что достаточно подключить современную модель - и команда автоматически начнет работать быстрее. На практике это не так.
Главная задача - не выбрать самый «умный» ИИ, а построить систему, в которой он сможет работать предсказуемо. Для этого нужны четыре элемента: единый контекст, понятные правила, инструменты для реальных действий и обязательный контроль со стороны человека. В MD Audit ИИ не заменил тестировщиков, но изменил характер их работы. Он взял на себя задачи, которые легко формализовать: подготовку тестовых данных, генерацию тестовой документации, запуск типовых проверок, оформление дефектов. Специалисты при этом сосредоточены на задачах, требующих опыта, экспертной оценки и нестандартного подхода.
Внедрение ИИ в QA - это непрерывный процесс уверены в Softline. Контекст обновляется, инструменты дорабатываются, команда обучается. Результат такой системы измеряется не отчетами о внедрении, а реальным сокращением времени на рутинные операции и повышением качества тестирования.
