Где команда получила ускорение почти в 9 раз, почему на другом сценарии выиграла всего 11 часов и зачем считать настройку агента частью тестирования
|
770 кейсов вручную |
210 ч ручной цикл |
658 кейсов с агентами |
24 ч цикл с ревью |
Что вы вычеркиваете первым, когда поставка уже близко?
У многих тестировщиков есть сценарий, который воспроизводится стабильнее большинства автотестов: перед поставкой обязательно выясняется, что на полный регресс времени уже нет.
Разработка закрывает последние замечания, функциональные требования (ФТ) продолжают уточняться, а каждое исправление может задеть уже проверенный сценарий. У QA при этом вполне конкретный список работ: подробно описать тест‑кейсы, связать их с требованиями, пройти регресс, добавить негативные проверки и автоматизировать хотя бы стабильную часть.
Но на всё это вместе времени катастрофически не хватает, как говорится — «некогда объяснять». И команда начинает вычеркивать. Сначала подробные кейсы заменяются чек‑листом. Затем регресс сужается до самых опасных участков. Автотесты переносятся на следующий этап. В большинстве проектов сроки в итоге побеждают: систему нужно передать, даже если проверить удалось меньше, чем в идеале хотелось бы.
В банковском ПО этот компромисс особенно неприятен: кредитный конвейер или система открытия счетов продолжают меняться после первой поставки, сегодняшний сокращенный регресс становится завтрашней ручной перепроверкой, а неявное правило из функционального требования — замечанием уже на приемке.
Я руковожу тестированием более 5 лет и прекрасно знаю эту ситуацию. Поэтому вопрос был простой: можем ли мы с помощью агентов делать подробные тест‑кейсы, нормальный регресс и автотесты в тех сроках, которые есть у проекта?
От 210 часов к 24 — и почему одной этой цифры недостаточно
На одном из модулей разрабатываемого нами кредитного конвейера подготовка набора тест‑кейсов вручную занимала 210 часов. С агентами полный сопоставимый цикл, включая ревью тестировщиком, занял 24 часа. Получилось почти в 9 раз быстрее.
Для нас это означало, что подробные тест‑кейсы можно готовить и на проектах, где раньше по срокам оставался только чек‑лист. А если есть подробные кейсы и связь с требованиями, проще проводить регресс и переходить к автотестам.
Дальше результаты были менее ровными. В UI‑автоматизации агент подготовил 315 автотестов по 487 исходным кейсам; настройка заняла 33 часа против примерно 70 часов ручной разработки по оценке команды. На backend‑задаче выигрыш составил всего 11 часов. Еще один пилот вообще не дал мгновенной экономии: большая часть времени ушла на настройку агента и разбор требований.
Дальше я расскажу, из чего же сложились эти 24 часа, почему на других задачах результат был скромнее и в каком случае агент вообще не смог написать нормальные автотесты.
Почему мы выбрали довольно обычный модуль, а не самый сложный
Для первого замера мы взяли привычный нам за 20 лет внедрений модуль кредитного конвейера для физических лиц. По сложности это вполне обычный для нас участок. Так и было задумано: на знакомом процессе проще проверить результат и не потратить весь выигрыш на выяснение того, что именно придумала модель.
Функциональное требование состояло из двух сопоставимых частей. Первая описывала заполнение персональных данных и адресов клиента. Вторая — сведения о занятости, анкету, документы и сканы. Первую часть команда уже обработала вручную: 770 тест‑кейсов потребовали 210 часов. Для второй подключили агентов: 658 тест‑кейсов были готовы за 24 часа, включая ревью тестировщиком.
Внутри этих 24 часов около 16 заняла работа с агентами и подготовка материала, еще 8 — проверка человеком. По полному циклу мы получили ускорение почти в 9 раз.
С цифрой есть нюанс, поэтому поясню, что именно мы сравнивали. Это были части одного функционального требования, близкие по объему и относящиеся к одному проекту. В 24 часа вошло ревью тестировщиком. Если считать только время генерации, сравнение было бы некорректным.
Один идеальный промт или четыре отдельные роли
Схема сложилась из четырех этапов.
Сначала агент анализирует функциональное требование: делит его на блоки, ищет пробелы, готовит вопросы. Ответы дает бизнес‑аналитик. Мы запретили агенту самостоятельно достраивать отсутствующую логику. Если не описано, как система должна вести себя в конкретном случае, значит, нужен вопрос, а не правдоподобная догадка.
Затем test‑designer готовит атомарные тест‑кейсы с шагами и предусловиями и связывает их с пунктами требования. После него включается reviewer: проверяет полноту и оформление, возвращает замечания. Эти два агента работают циклом, пока reviewer не перестает находить проблемы.
Последнее решение принимает уже спасибо‑что‑живой тестировщик. Он смотрит, достаточно ли проверок, можно ли выполнить сценарий, не потерян ли контекст. Если человек возвращает материал, агент исправляет набор и дополняет постоянные инструкции. Так замечание становится правилом для следующих задач, а не одноразовой правкой.
На этом месте все обычно спрашивают про галлюцинации. По нашему опыту, агент нормально держится в рамках задачи, если инструкции короткие и в них явно записаны ограничения. Но результат всё равно проверяет тестировщик. Ответственность на агента переложить нельзя — и в этом наша, обладателей естественного интеллекта, главная прерогатива, на мой взгляд. Этот хлеб еще очень долго и трудно будет отобрать.
Что именно получает агент и что обязан вернуть?
Итак, на вход мы передаем функциональные требования, связанные материалы, расшифровки сокращений, шаблон тест‑кейса и ограничения. Если документ ссылается на справочник или другую страницу, содержимое ссылки тоже должно попасть в доступный контекст. Ссылка без документа для агента равна отсутствующему требованию.
Результат от агента по имени Test‑designer — набор атомарных кейсов с предусловиями, шагами, ожидаемым результатом и привязкой к пункту ФТ. Второй ИИ‑агент aka Reviewer должен проверить полноту комбинаций, соответствие шаблону и наличие трассировки. Соответственно, вершина эволюции человек принимает не текст как таковой, а пригодность набора к прохождению и регрессу.
Поэтому мы заранее старательно и занудно фиксируем состав входных материалов и требования к результату. Модель и инструкции могут меняться, а критерии приемки тест‑кейсов остаются теми же.
658 тестов — это классное покрытие?
658 тест‑кейсов удобно вынести в заголовок. А вот принимать работу по одной этой цифре я бы точно не стал. Почему?
Большой набор может содержать дубли, слишком широкие сценарии или формальные вариации одной проверки. Поэтому мы смотрим на связь с требованиями, атомарность, воспроизводимость и пригодность для регресса. У каждого кейса должен быть понятный источник: какой пункт он проверяет и что изменится, если этот пункт перепишут.
Трассировка нужна после первой же доработки. По ней видно, какие проверки повторить и какие кейсы изменить. Без связи с требованиями набор из сотен сценариев быстро устаревает.
Пока у нас нет единой идеальной методики, я, пожалуй, воздержусь заявлять публичный процент роста покрытия. Ускорение почти в 9 раз мы измерили. Набор прошел ревью и был принят.
Следующий шаг — одинаково строго измерять долю требований с проверками, возвраты после ревью, пригодность кейсов к автоматизации и замечания на приемке.
Почему на автотестах не получилось тех же 9 раз?
С тест‑кейсами агент показал почти девятикратное ускорение. В автоматизации картина получилась неровной — и именно поэтому она полезна.
Для UI‑ и API‑проверок мы используем Playwright. В одном сценарии передали агенту 487 тест‑кейсов. С первого прохода он подготовил 315 автотестов, то есть около 65% массива. Это были проверки форм, без сквозных e2e‑сценариев и интеграций. Настройка агента потребовала 33 часа тестировщика. Ручную разработку с нуля команда оценила примерно в 70 часов.
Надо обязательно отметить, что 315 сгенерированных тестов нельзя просто отправить в pipeline — их нужно проверить. И все же разница достаточно велика, чтобы автоматизация появилась там, где раньше ее могли исключить из сметы еще на старте.
На backend‑задаче выигрыш оказался поскромнее: 50 тестов вместе с фреймворком и отладкой заняли 49 часов без агентов. С агентами те же 50 тестов, разработка правил и отладка потребовали 38 часов. Экономия — 11 часов. Дополнительный эффект получили при разборе ошибок: при корректной swagger‑документации эту работу агент выполнял автоматически.
На выходе, помимо автотествов, мы получили версии агентов для UI‑автоматизации и backend‑автоматизации, которые можем использовать в дальнейшем на других проектах с минимальной донастройкой.
Что показал пилот без мгновенной экономии
На другом проекте работа с агентом заняла 23 часа, причем больше половины времени ушло на разбор функционального требования и настройку правил. Как пример моментальной экономии этот результат не годится.
Но одновременно именно этот замер полезен по другой причине. Если не учитывать разбор материалов, настройку, тестовые данные, ревью и отладку, результат будет выглядеть лучше, чем есть на самом деле. Мы считаем всё время, которое потребовалось до приемки результата.
У первичной настройки есть шанс окупиться на следующих однотипных требованиях: контекст уже разобран, инструкции накоплены, типовые замечания учтены. Безусловно, пока повторных замеров нет, это гипотеза. В ближайшие месяцы мы собираемся проверять ее на серии задач и разделять разовые затраты на настройку и стоимость каждого следующего прогона.
В еще одном сценарии агент плохо справился с автотестами из‑за исходных тест‑кейсов. Человеку они были понятны, но часть шагов восстанавливалась из опыта и знания системы. Агент эти шаги восстановить не смог. Сейчас мы дописываем их и готовим тестовые данные, после чего вернемся к автотестам.
Где заканчиваются цифры и начинаются допущения?
У этого кейса есть ограничения. Части функционального требования были сопоставимы по объему и относились к одному проекту, но не были идентичными. Поэтому «почти в 9 раз» — результат конкретной пары задач, не коэффициент производительности модели.
210 и 24 часа — зафиксированные трудозатраты. Оценка примерно в 70 часов для ручной UI‑автоматизации — экспертная, а не результат параллельной контрольной разработки. Сравнение backend‑тестов ближе к прямому замеру, но и там в вариант с агентом вошла разработка новых правил, которые могут повторно использоваться дальше.
Пока что мы не считали стоимость токенов, сопровождения инструкций и обновления автотестов на длинном горизонте. Эти расходы не отменяют полученного ускорения, но нужны для разговора о совокупной стоимости владения. Следующая серия замеров должна показать, окупается ли первичная настройка на повторяющихся задачах и сколько живут накопленные правила.
Что же тогда меняется в работе тестировщика
После первых экспериментов я стал иначе смотреть на разделение ручного и автоматизированного тестирования. Специалист, который раньше в основном проходил сценарии вручную, теперь может управлять подготовкой автотестов: поставить задачу, проверить структуру, оценить результат, вернуть на доработку. Для этого все равно нужны технические знания, но порог входа становится ниже.
Повседневная работа тестировщика начинает напоминать работу лида на небольшом участке. Он управляет связкой из требований, вопросов к аналитику, тест‑кейсов, ревью, регресса и автоматизации. Агент берет объём рутины, человек — решения.
Роль QA при этом никуда не исчезает. Кто‑то должен заметить, что тесты формально корректны, но проверяют не то; что предусловие невозможно выполнить; что модель пропустила значимую ветку. Это по‑прежнему работа тестировщика.
Агент освобождает ему время на проверки, которые раньше не помещались в сроки: регресс, подготовку автотестов, оценку последствий доработок.
Что же на самом деле банковский контур разрешает агенту?
Работа с агентами в банковских проектах начинается с режима доступа к информации. Документы передаются в обезличенном виде. Сокращения нужно расшифровать, связанные материалы — собрать, ссылки из ФТ — раскрыть в доступном контексте. Если половина смысла живет в головах команды или на недоступных страницах, агент его при всем своем энтузиазме и желании не восстановит.
Есть и инфраструктурное ограничение. Когда разработка и тестирование ведутся на стендах заказчика, подключение агента к прохождению сценариев или подготовке автотестов может оказаться недоступным. Это выясняется до пилота, а не после презентации результатов.
Особенно прозрачно эта зависимость видна на API. При подробном и актуальном описании API подготовка автотестов проходит без серьезных препятствий. Основные задержки в нашем эксперименте возникали там, где документация содержала ошибки или описывала поведение недостаточно подробно. Агент в этом смысле работает как жесткий приемщик: он не обладает проектной памятью и сразу упирается в то, что команда годами компенсировала устными договоренностями.
Резюмируя — перед запуском мы проверяем три вещи: достаточно ли подробно описаны требования, можно ли использовать агента на инфраструктуре проекта и кто будет проверять результат.
Как проверить подход на своем проекте?
Начните со знакомого и измеримого участка. Экзотический процесс производит больше впечатления на демо, но хуже подходит для первого расчета. Нужны ручная база для сравнения, ограниченный фрагмент требований и специалист, который быстро распознает ошибку.
Считайте полный цикл. Время аналитика, настройку агента, подготовку данных, генерацию, ревью и отладку. Иначе вы измеряете скорость появления текста на экране.
Разделите автора и проверяющего. Связка test‑designer и reviewer дает более устойчивый результат, чем последовательные просьбы одному агенту «проверить себя еще раз».
Запрещайте догадки явно. Недостающая бизнес‑логика должна превращаться в вопрос к аналитику. Это правило защищает лучше длинного списка общих пожеланий к качеству.
Проектируйте тест‑кейсы с учетом следующего шага. Подробные предусловия, атомарные сценарии и явные ожидаемые результаты нужны уже сейчас, если позже вы хотите получить автотесты или поручить агенту прохождение проверок.
И не пытайтесь доказать успех количеством сгенерированных кейсов. Лучший результат — набор, который команда приняла, связала с требованиями и способна использовать после следующего изменения системы.
Минимальный план пилота
1. Выберите один ограниченный фрагмент требований, по которому есть ручная база или надежная экспертная оценка.
2. До запуска зафиксируйте, что входит в трудозатраты: анализ ФТ, вопросы аналитику, настройка, генерация, ревью и отладка.
3. Опишите контракт результата: структура кейса, обязательные поля, трассировка и запрет на необоснованные допущения.
4. Разделите роли test‑designer и reviewer и сохраните замечания человека как постоянные правила.
5. После приемки измерьте не только часы и количество кейсов, но и возвраты, дубли, пропуски, долю пригодных к автоматизации сценариев.
6. Повторите эксперимент на однотипной задаче. Только второй запуск покажет, можно ли повторно использовать сделанные настройки или всё придется собирать заново.
Каких данных пока не хватает рынку?
Мне было бы интересно сопоставить наш результат с замерами других команд: сколько времени занимает повторный запуск после настройки, какая доля сгенерированных кейсов переживает человеческое ревью без возврата, как быстро деградируют автотесты при изменении интерфейсов и API.
Без этих показателей трудно понять, что именно дало экономию и повторится ли она на следующей задаче. Если вы уже считаете их на своих проектах, делитесь было бы интересно сравнить методики в комментариях.
Куда мы идем дальше
Мы подключаем агентов к новым проектам для анализа требований и подготовки тест‑кейсов. Там, где позволяет качество входа и инфраструктура, добавляем генерацию автотестов. Отдельно проверяем сценарии нагрузочного тестирования.
Сейчас у нас есть 3 разных результата: почти девятикратное ускорение при подготовке тест‑кейсов, экономия 11 часов на backend‑автотестах и пилот, где настройка заняла столько же времени, сколько раньше занимала ручная работа. Поэтому общего коэффициента для всех проектов у нас еще практически нет.
На старте агент может и не уменьшить оценку тестирования: настройка тоже требует времени. Но подробные тест‑кейсы и автотесты можно использовать повторно после доработок. Тогда экономия появляется на следующих регрессах, приемке и сопровождении.
Раньше мы регулярно отказывались от части проверок, потому что они не помещались в сроки. В эксперименте с кредитным конвейером та же работа заняла 24 часа вместо 210. Теперь эти часы мы можем потратить на дополнительное покрытие и регресс.
Я считаю результат весьма перспективным, если после внедрения агента тестировщик не просто быстрее оформил документ, а проверил больше и оставил после себя набор, который можно повторно запустить при следующем изменении системы. И такая борьба за качество способна не только удовлетворить внутренний перфекционизм команды заказчика, но и кратно повысить компетенции даже самых начинающих участников проекта.
Автор: Zhidkov_Vitaliy
