Три итерации до полезного ИИ: как мы автоматизировали тестирование в ELMA365

Всем привет! Меня зовут Татьяна Веселова. Я руководитель направления ELMA в департаменте CRM&BPM.

На каждом проекте и перед релизом аналитики мы всегда проводим тестирование функционала: проверяем формы, роли, согласования и сценарии, которые могли не заработать или сломаться после очередной доработки. Выделенных тестировщиков у нас нет, поэтому эта рутина регулярно съедала время у тех, кому нужно заниматься требованиями, документацией, архитектурой и клиентами.

Я решила с помощью ИИ создать инструмент для тестирования, который будет делать все сам и автоматизирует рутину аналитиков. Спойлер — всесильного ИИ не случилось, но после трех итераций у нас появился инструмент, который снизил нагрузку аналитиков примерно на 30%. В статье расскажу, как я к нему шла и в конце поделюсь выводами. 

Почему для тестирования понадобился ИИ
Итерация первая: ИИ проводит тесты по выгрузке конфига
Итерация вторая: подключаем тестирование по API
Итерация третья: делаем playwright
Готовое решение: ИИ + человек
Итоги и выводы эксперимента

Почему для тестирования понадобился ИИ

Наша команда занимается внедрением и кастомизацией low-code платформы для автоматизации бизнес-процессов ELMA 365. 

В командах внедрения у нас есть руководители проектов, разработчики и аналитики. Выделенных тестировщиков нет. Эту часть на себя берут разработчики и аналитики.  

• Разработчики — когда пилят новый функционал, создают код и им нужно проверить, а работает ли он вообще.

• Аналитики — когда проверяют корректность работы созданной кастомизации (новый бизнес-процесс, скрипты, плагины и т. д.) и проводят регрессионное тестирование, чтобы убедиться, что новые доработки ничего не сломали.

Тестирование, которое проводят аналитики, забирает много времени. Для каждого сценария нужно создать тест-кейсы, прогнать их, обработать результаты. И так для каждого нового релиза, даже если по результатам презентации системы клиенту внедрили минорные правки. 

Но у аналитиков и так много работы: они пишут технические задания, готовятся ко встречам и проводят их, работаютсъ с аналитикой, моделируют архитектуру. В общем, время, которое они тратят на тестирование, можно было бы потратить на более креативные, сложные задачи. 

А еще есть клиенты, которые спрашивают — «Есть же ИИ, почему вы до сих пор это все делаете руками»?

«И правда, почему»? — подумала я и решила навайбкодить инструмент, который автоматизирует тестирование для аналитиков. 

Итерация первая: ИИ проводит тесты по выгрузке конфига

Ожидания были следующие: мы отдаем инструменту выгрузку конфига, а он: 

• изучает конфиг;  

• придумывает тест-кейсы для проверки процессов; 

• прогоняет тесты; 

• выдает отчет: что не сработало, какие правки нужно внести. Если чего-то не хватило для проверки — запрашивает эти данные. 

Инструмент я вайбкодила с помощью Claude, консультировалась с разработчиком для проработки архитектуры решения и чтобы погрузиться в нюансы ELMA365. Мой запрос был достаточно простым, не учитывал особенности работы платформы, каких-то ограничений. Я работала самостоятельно, по минимуму привлекая команду. 

Первая версия была готова через пару недель. Мы запустили тестирование и ….получили «прекрасные» зеленые тесты. 

Стали разбираться и поняли: ИИ проверял не логику процесса и корректность сценариев, а функциональность отдельных элементов интерфейса. Например, он убеждался, что обязательная форма действительно не позволяет отправить данные без заполнения, и выдавал результат: «все работает».

Но эта информация не помогала понять, проходит ли пользовательский сценарий целиком, срабатывают ли нужные условия. По сути, инструмент подтверждал то, что мы и так знали, — ценности для тестирования такие проверки не давали.

Итерация вторая: подключаем тестирование по API

Я решила, что настройка взаимодействия по API решит проблему. 

Как перестроила процесс: 

• ИИ получает выгрузку и формирует на ее основании сценарии тестов;  

• по API подключается к системе и создает записи в бэке: заполняет нужные поля и формы. 

Внесла правки, запустила инструмент — тесты опять зеленые. 

Пошла разбираться с коллегами, что пошло не так. Выяснила, что в этом случае тесты полностью игнорировали UX. ИИ не проверял, насколько корректно отрабатывают формы в самом интерфейсе, логику на формах, обязательность полей заполнения определенным данными, сложные последовательности, которые запускались по определенным условиям. Он просто вносил данные в нужные поля и успешно завершал процесс. 

Итерация третья: делаем playwright

Обсудили результаты с разработчиком и решили перейти к тестированию через Playwright. Теперь инструмент должен был заходить в систему через браузер под учетной записью конкретного пользователя и последовательно выполнять те же действия, что и человек в реальном сценарии.

Подход сработал, но частично. ИИ действительно научился проходить сценарии в браузере, но часто останавливался на середине и не доводил процесс до нужного финального статуса.

Например, один из процессов связан с подготовкой договора. Нужно заполнить карточку, отправить документ на согласование другому пользователю, получить апрув и утвердить договор. ИИ запускал тест, проверял формы и отдельные правила, но в какой-то момент останавливался и не доводил сценарий до конца.

Стали разбираться дальше и выяснили: инструмент не понимал, к какому итоговому статусу должен прийти процесс. Мы попытались исправить это с помощью документации по системе и технического задания к новому конфигу, где описаны нужные процессы. Но этих данных все равно не хватало. ИИ не всегда мог однозначно определить ожидаемый результат конкретного сценария.

Кроме того, полноценная end-to-end-проверка требует входа в систему под разными учетными записями с корректно настроенными ролями. А в текущей реализации инструмент не мог самостоятельно управлять такими переходами.

Так мы пришли к важному выводу: полностью исключить человека из процесса не получится. ИИ может эмулировать действия пользователя и выполнять сценарии в браузере, валидировать сами сценарии и ожидаемые результаты должен аналитик. 

Готовое решение: ИИ + человек

Я оставила мечту о всесильном ИИ и при помощи и содействии коллег пришла к тому, что решение будет полуавтоматическим. 

Далее сформулировала список того, что должен делать в этом решении искусственный интеллект: 

• проанализировать решение: выявить логику, сценарии, роли, под которыми пользователи должны выполнять разные тесты, и структурировать эту информацию в виде сценариев про проверки; 

• подготовить тестовые записи для прогона; 

• провести тестирование через браузер: отработать как реальный пользователь; 

• убрать за собой: удалить из системы записи, которые создавались для тестов; 

• подготовить отчет для аналитика. 

Чтобы ИИ мог корректно работать с конфигурацией, ему нужна информация о возможностях и ограничениях платформы. Поэтому в систему загрузили базу знаний вендора: справку по доступным методам, правилам разработки, стандартным объектам и модулям ELMA365, а также их назначению и взаимосвязям.

Одной базы знаний по платформе недостаточно. Для тестирования важны документы по конкретной конфигурации. Это ПМИ, технические задания и другие артефакты, где описаны реализуемые сценарии, бизнес-логика, правила заполнения полей, условия согласований и ожидаемые финальные статусы процессов.

Чтобы валидировать сценарии, важно указать, что требуется заполнить в формах, до какого статуса довести процесс, к запуску тестов подключается аналитик. 

И так как учетные данные пользователей в инструменте не хранятся — даже если это тестовые записи, аналитик нужен еще и для того, залогинится в систему под нужными ролями и предоставить доступ к этим сессиям ИИ. 

Как все работает

В результате обработки этих требований пришли к комплексному полуавтоматическому решению.

Работает оно следующим образом: 

• Что требуется проверить — сценарии тестов. Их ИИ берет либо из документации, либо генерирует на основании ПМИ и конфига. Структурирует и выдает для валидации аналитику.

• Вопросы, если они есть. ИИ может не определить ожидаемый результат сценария: до какого статуса нужно довести процесс, какие условия должны выполниться, каким должен быть итог проверки. В таких случаях он строит предположения, а уточнения запрашивает у человека. 

• Процессы. Для каждого сценария аналитик указывается ожидаемый финальный статус процесса — результат, которого система должна достичь при успешном выполнении теста. 

• Роли. В этой вкладке ИИ указывает, какие роли ему нужны для проверки. Аналитик нажимает на ссылку, логинится в системе под учеткой пользователя с ролью, которая будет использоваться в процессе.  

После того как мы ответили на все вопросы и убедились, что инструмент нас правильно понял, мы нажимаем кнопку «Прогон».

В конце теста, когда инструмент прогонит сценарии для всех указанных ролей и правил, он выдаст отчет: что прошло успешно, а что нет, какие есть ошибки и что требуется исправить.

На основании этого отчета аналитик делает выводы, проверяет систему, дорабатывает те ответы, которые должны были получиться, и запускает тест повторно.

Итоги и выводы эксперимента

Пока инструмент работает в тестовом режиме, но мы уже видим, что затраты аналитиков на регрессионное и функциональное тестирование сократились примерно на 30%.  

Ключевой вывод для меня оказался в том, что даже специалист без глубоких знаний в области разработки и аналитики в конечном счете может создать полезный продукт для команды — если разберется с проблемой и будет готов действовать итерационно. 

При этом важно помнить о проектировании. На первых этапах я достаточно просто формулировала задачу — «автоматизируй тестирование», и ИИ предлагал мне варианты, которые выглядели логично, но в контексте реального тестирования ELMA365 приводили не туда. 

Поэтому для таких задач особенно важно с самого начала привлекать коллег-экспертов, вместе с ними детализировать задачу, разбираться с особенностями и ограничениями системы, четче прописывать ожидаемые результаты. 

ИИ действительно помогает в относительно короткие сроки собрать инструмент, но без участия людей, которые знают предметную область, его ценность будет невелика.