Всем привет! Меня зовут Татьяна Веселова. Я руководитель направления ELMA в департаменте CRM&BPM.
На каждом проекте и перед релизом аналитики мы всегда проводим тестирование функционала: проверяем формы, роли, согласования и сценарии, которые могли не заработать или сломаться после очередной доработки. Выделенных тестировщиков у нас нет, поэтому эта рутина регулярно съедала время у тех, кому нужно заниматься требованиями, документацией, архитектурой и клиентами.
Я решила с помощью ИИ создать инструмент для тестирования, который будет делать все сам и автоматизирует рутину аналитиков. Спойлер — всесильного ИИ не случилось, но после трех итераций у нас появился инструмент, который снизил нагрузку аналитиков примерно на 30%. В статье расскажу, как я к нему шла и в конце поделюсь выводами.
Почему для тестирования понадобился ИИ
Итерация первая: ИИ проводит тесты по выгрузке конфига
Итерация вторая: подключаем тестирование по API
Итерация третья: делаем playwright
Готовое решение: ИИ + человек
Итоги и выводы эксперимента
Почему для тестирования понадобился ИИ
Наша команда занимается внедрением и кастомизацией low-code платформы для автоматизации бизнес-процессов ELMA 365.
В командах внедрения у нас есть руководители проектов, разработчики и аналитики. Выделенных тестировщиков нет. Эту часть на себя берут разработчики и аналитики.
Разработчики — когда пилят новый функционал, создают код и им нужно проверить, а работает ли он вообще.
Аналитики — когда проверяют корректность работы созданной кастомизации (новый бизнес-процесс, скрипты, плагины и т. д.) и проводят регрессионное тестирование, чтобы убедиться, что новые доработки ничего не сломали.
Тестирование, которое проводят аналитики, забирает много времени. Для каждого сценария нужно создать тест-кейсы, прогнать их, обработать результаты. И так для каждого нового релиза, даже если по результатам презентации системы клиенту внедрили минорные правки.
Но у аналитиков и так много работы: они пишут технические задания, готовятся ко встречам и проводят их, работаютсъ с аналитикой, моделируют архитектуру. В общем, время, которое они тратят на тестирование, можно было бы потратить на более креативные, сложные задачи.
А еще есть клиенты, которые спрашивают — «Есть же ИИ, почему вы до сих пор это все делаете руками»?
«И правда, почему»? — подумала я и решила навайбкодить инструмент, который автоматизирует тестирование для аналитиков.
Итерация первая: ИИ проводит тесты по выгрузке конфига
Ожидания были следующие: мы отдаем инструменту выгрузку конфига, а он:
изучает конфиг;
придумывает тест-кейсы для проверки процессов;
прогоняет тесты;
выдает отчет: что не сработало, какие правки нужно внести. Если чего-то не хватило для проверки — запрашивает эти данные.
Инструмент я вайбкодила с помощью Claude, консультировалась с разработчиком для проработки архитектуры решения и чтобы погрузиться в нюансы ELMA365. Мой запрос был достаточно простым, не учитывал особенности работы платформы, каких-то ограничений. Я работала самостоятельно, по минимуму привлекая команду.
Первая версия была готова через пару недель. Мы запустили тестирование и ….получили «прекрасные» зеленые тесты.
Стали разбираться и поняли: ИИ проверял не логику процесса и корректность сценариев, а функциональность отдельных элементов интерфейса. Например, он убеждался, что обязательная форма действительно не позволяет отправить данные без заполнения, и выдавал результат: «все работает».
Но эта информация не помогала понять, проходит ли пользовательский сценарий целиком, срабатывают ли нужные условия. По сути, инструмент подтверждал то, что мы и так знали, — ценности для тестирования такие проверки не давали.
Итерация вторая: подключаем тестирование по API
Я решила, что настройка взаимодействия по API решит проблему.
Как перестроила процесс:
ИИ получает выгрузку и формирует на ее основании сценарии тестов;
по API подключается к системе и создает записи в бэке: заполняет нужные поля и формы.
Внесла правки, запустила инструмент — тесты опять зеленые.
Пошла разбираться с коллегами, что пошло не так. Выяснила, что в этом случае тесты полностью игнорировали UX. ИИ не проверял, насколько корректно отрабатывают формы в самом интерфейсе, логику на формах, обязательность полей заполнения определенным данными, сложные последовательности, которые запускались по определенным условиям. Он просто вносил данные в нужные поля и успешно завершал процесс.
Итерация третья: делаем playwright
Обсудили результаты с разработчиком и решили перейти к тестированию через Playwright. Теперь инструмент должен был заходить в систему через браузер под учетной записью конкретного пользователя и последовательно выполнять те же действия, что и человек в реальном сценарии.
Подход сработал, но частично. ИИ действительно научился проходить сценарии в браузере, но часто останавливался на середине и не доводил процесс до нужного финального статуса.
Например, один из процессов связан с подготовкой договора. Нужно заполнить карточку, отправить документ на согласование другому пользователю, получить апрув и утвердить договор. ИИ запускал тест, проверял формы и отдельные правила, но в какой-то момент останавливался и не доводил сценарий до конца.
Стали разбираться дальше и выяснили: инструмент не понимал, к какому итоговому статусу должен прийти процесс. Мы попытались исправить это с помощью документации по системе и технического задания к новому конфигу, где описаны нужные процессы. Но этих данных все равно не хватало. ИИ не всегда мог однозначно определить ожидаемый результат конкретного сценария.
Кроме того, полноценная end-to-end-проверка требует входа в систему под разными учетными записями с корректно настроенными ролями. А в текущей реализации инструмент не мог самостоятельно управлять такими переходами.
Так мы пришли к важному выводу: полностью исключить человека из процесса не получится. ИИ может эмулировать действия пользователя и выполнять сценарии в браузере, валидировать сами сценарии и ожидаемые результаты должен аналитик.
Готовое решение: ИИ + человек
Я оставила мечту о всесильном ИИ и при помощи и содействии коллег пришла к тому, что решение будет полуавтоматическим.
Далее сформулировала список того, что должен делать в этом решении искусственный интеллект:
проанализировать решение: выявить логику, сценарии, роли, под которыми пользователи должны выполнять разные тесты, и структурировать эту информацию в виде сценариев про проверки;
подготовить тестовые записи для прогона;
провести тестирование через браузер: отработать как реальный пользователь;
убрать за собой: удалить из системы записи, которые создавались для тестов;
подготовить отчет для аналитика.
Чтобы ИИ мог корректно работать с конфигурацией, ему нужна информация о возможностях и ограничениях платформы. Поэтому в систему загрузили базу знаний вендора: справку по доступным методам, правилам разработки, стандартным объектам и модулям ELMA365, а также их назначению и взаимосвязям.
Одной базы знаний по платформе недостаточно. Для тестирования важны документы по конкретной конфигурации. Это ПМИ, технические задания и другие артефакты, где описаны реализуемые сценарии, бизнес-логика, правила заполнения полей, условия согласований и ожидаемые финальные статусы процессов.
Чтобы валидировать сценарии, важно указать, что требуется заполнить в формах, до какого статуса довести процесс, к запуску тестов подключается аналитик.
И так как учетные данные пользователей в инструменте не хранятся — даже если это тестовые записи, аналитик нужен еще и для того, залогинится в систему под нужными ролями и предоставить доступ к этим сессиям ИИ.
Как все работает
В результате обработки этих требований пришли к комплексному полуавтоматическому решению.
Работает оно следующим образом:
Что требуется проверить — сценарии тестов. Их ИИ берет либо из документации, либо генерирует на основании ПМИ и конфига. Структурирует и выдает для валидации аналитику.
Вопросы, если они есть. ИИ может не определить ожидаемый результат сценария: до какого статуса нужно довести процесс, какие условия должны выполниться, каким должен быть итог проверки. В таких случаях он строит предположения, а уточнения запрашивает у человека.
Процессы. Для каждого сценария аналитик указывается ожидаемый финальный статус процесса — результат, которого система должна достичь при успешном выполнении теста.
Роли. В этой вкладке ИИ указывает, какие роли ему нужны для проверки. Аналитик нажимает на ссылку, логинится в системе под учеткой пользователя с ролью, которая будет использоваться в процессе.
После того как мы ответили на все вопросы и убедились, что инструмент нас правильно понял, мы нажимаем кнопку «Прогон».
В конце теста, когда инструмент прогонит сценарии для всех указанных ролей и правил, он выдаст отчет: что прошло успешно, а что нет, какие есть ошибки и что требуется исправить.
На основании этого отчета аналитик делает выводы, проверяет систему, дорабатывает те ответы, которые должны были получиться, и запускает тест повторно.
Итоги и выводы эксперимента
Пока инструмент работает в тестовом режиме, но мы уже видим, что затраты аналитиков на регрессионное и функциональное тестирование сократились примерно на 30%.
Ключевой вывод для меня оказался в том, что даже специалист без глубоких знаний в области разработки и аналитики в конечном счете может создать полезный продукт для команды — если разберется с проблемой и будет готов действовать итерационно.
При этом важно помнить о проектировании. На первых этапах я достаточно просто формулировала задачу — «автоматизируй тестирование», и ИИ предлагал мне варианты, которые выглядели логично, но в контексте реального тестирования ELMA365 приводили не туда.
Поэтому для таких задач особенно важно с самого начала привлекать коллег-экспертов, вместе с ними детализировать задачу, разбираться с особенностями и ограничениями системы, четче прописывать ожидаемые результаты.
ИИ действительно помогает в относительно короткие сроки собрать инструмент, но без участия людей, которые знают предметную область, его ценность будет невелика.
