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