Всем привет! Меня зовут Алена Метенева, я руководитель направления по тестированию в Росгосстрахе. Я специализируюсь на внедрении ИИ‑инструментов в процессы тестирования. И сегодня хочу рассказать вам о том, как мы в Росгосстрахе провели пилот по внедрению нейросетей в тестирование и как сейчас масштабируем результаты на другие команды.
В апреле я выступала на SQA Days 38 с докладом «От пилота до стандарта: масштабирование практик тестирования с помощью AI». Подготовка к SQA Days заняла ощутимый кусок времени: нужно было упаковать месяцы пилота и последующих исследований в историю, которая укладывается в тайминг выступления, и при этом не утонуть в деталях (а их очень и очень много!).
Во время конференции мне удалось пообщаться с коллегами из разных компаний. У кого‑то из них уже есть устоявшийся пайплайн с ИИ, кто‑то только выбирает инструменты, у кого‑то ‑жёсткие рамки по информационной безопасности и другой стек. Эти разговоры дали несколько инсайтов, и в итоге я решила написать цикл статей на Хабре: в формате статьи удобнее по шагам разобрать весь процесс и погрузиться в детали.
Разгружаем инженеров
В разных компаниях, и больших, и маленьких, проблемы тестирования примерно одинаковые: QA‑инженеры перегружены работой, они не успевают вести нормальную документацию, не успевают автоматизировать регресс, вынуждены идти на компромиссы ради скорости поставки, а в итоге выгорают от такого режима работы.
Линейное расширение команд, как правило, не помогает: стоит нанять еще людей, как нагрузка подстраивается под новую вместимость. В Росгосстрахе мы решили проверить гипотезу: можно ли снять часть рутины и ускорить shift‑left за счёт нейросетей и при этом сохранить контроль качества на стороне человека.
Как мы провели пилот
Мы собрали небольшую команду: два фронтенд‑разработчика и я как QA‑инженер. Передо мной стояла задача исследовать применимость ИИ в тестировании и встроить его в существующие процессы так, чтобы результат можно было воспроизвести и перенести на другие команды.
В качестве инструмента мы выбрали Cursor AI. Из соображений информационной безопасности исследования ограничили фронтендом конкретного продукта.
Важный момент: мы использовали Cursor в ручном режиме — чат, промпты, задания, самостоятельная валидация результатов. Отдельно настраиваемых «агентов», которые ходят по репозиторию без присмотра, на первом этапе не было.
Почему не агенты?
Почему мы не пошли в историю с агентами? Потому что полная автоматизация за счет ИИ — это точно не то, с чего нужно начинать. У многих людей до сих пор высокий порог недоверия к ИИ. А кто‑то, наоборот, чересчур полагается на искусственный интеллект и абсолютно не валидирует выходные данные. Кто‑то может просто бояться, что ИИ его заменит.
Чтобы научить людей спокойно и уверенно использовать ИИ‑инструменты в своей работе, надо научить их это делать руками. Чтобы каждый мог попробовать разные промты, проанализировать результаты. Увидеть, от чего зависит качественный ответ, в каких случаях можно больше рассчитывать на корректный и полный ответ, а в каких от нейронки мало что можно добиться.
Только тогда у человека появляется уверенность в том, что он может контролировать ход работы ИИ на этапах подготовки данных и ревью. А еще уверенность в том, что без человека ИИ все‑таки не способен работать со стабильным уровнем качества. Вот тогда уже можно пробовать переходить к написанию агентов и подобным вещам, принимая во внимание все ограничения, которые были обнаружены на этапе ручного использования ИИ.
Три процесса, которые мы усилили ИИ
Итак, с чего же все началось? Для начала я выделила три подпроцесса тестирования, где нейросеть может дать максимальный эффект при аккуратном применении:
Тестирование требований
Генерация тестовой документации
Генерация автотестов
Т.е. полноценный shift‑left на максималках за счет ИИ. Важный момент — собственно ручное тестирование мы никак не заменяем. QA‑инженеры продолжают тестировать самостоятельно, но получают значительный буст за счет быстрого тестирования требований, быстрого тест‑дизайна и своевременной автоматизации регресса.
Ну и, как полагается в настоящем шифт‑лефте, в следующей статье начнем с анализа требований.
Краткое резюме. Минимум, без которого эксперимент не взлетит
Доступ к инструментам — каким бы ни был ваш корпоративный выбор (Cursor, другая IDE с LLM, отдельный чат — методология остаётся той же).
Понимание процессов и продукта — модель не заменит доменные знания; она множит то, что вы ей дадите.
Время на эксперименты — без выделенных временных ресурсов будет сложно.
Поддержка и ресурсы — согласованные деньги на лицензии (если нужно) и добровольцы в команде пилота.
Подумайте о том, как вы будете определять, успешен ли ваш проект или нет. Какие метрики вам для этого нужны? Если для вас важно ускорить поставку продуктов на прод, то сокращение человеко‑часов будет подходящей метрикой. Если вас устраивает скорость поставки, но не устраивает количество багов на проде, подберите соответствующие этой цели метрики.
Не забывайте об основном ограничении:
Даже при одинаковых входных данных и промптах ответ модели будет отличаться от запуска к запуску. Поэтому этап ревью результатов нельзя пропускать ни в коем случае.