«ИИ-тестировщик»: от идеи к реализации

Привет, Хабр! На связи Денис Киров, руководитель отдела тестирования компании «ДОМ.РФ Технологии». В этой статье я расскажу, как проходило внедрение ИИ в процессы тестирования в нашей команде.

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

Применение ИИ в тестировании

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

·         Тестирование требований – тут может помочь NLP (Natural Language Processing)

·         Генерация тестовых кейсов

·         Генерация API тестов

·         Генерация отчётной документации

·         Генерация UI автотестов

Далее мы попробовали немного детализировать то, что мы хотим, а именно:

1)    Тестирование требований – анализ текста на отсутствие неоднозначности, логических ошибок аналитики.

2)    Генерация тестовых кейсов – нам нужно, чтобы ИИ генерировал тестовые кейсы аналогично тому, как это делают функциональные тестировщики (ФТ) – то есть по спецификации, которая может храниться на внутрикорпоративном Confluence, в Jira, а также в формате OpenAPI/Swagger.

3)    Генерация API тестов – мы хотим, чтобы автоматически генерировались API тесты на том стеке технологий, который мы используем в работе, а это Postman. Также хорошо уметь генерировать тесты на Java + RestAssured и Python + Requests, чтобы их могла использовать команда автоматизации.

4)    Генерация отчетной документации – основная «боль» наших ФТ – это оформление документа «ПМИ» (Программа и методика испытаний), которую мы должны сдавать раз в квартал заказчику по техническому заданию на квартал. Это трудозатратная и однообразная активность, которую очень хочется автоматизировать.

5)    Генерация UI автотестов – хотим автоматизировать часть рутинной активности, например, формирование PageObject и составлений xpath локаторов.

Основными целями внедрения ИИ мы определили:

·         Сократить time to market

·         Сократить время, которое сотрудники тратят на выполнение рутинных задач

·         Повысить качество разрабатываемых нами продуктов

·         Повысить удовлетворённость наших сотрудников и направить освободившееся время на развитие и прокачку скиллов.

Формирование требований к решению

            После того, как мы определились с целями, мы перешли к формированию требований к решению, которое будет внедряться. Основные требования были следующие:

·         Решение должно уметь генерировать тестовые кейсы, а также тестовые данные для сгенерированных кейсов

·         Решение должно поддерживать возможность интеграции с Jira и Confluence, для того, чтобы в автоматизированном режиме забирать оттуда необходимую информацию

·         Решение должно быть либо OpenSource, либо входить в реестр отечественного ПО, так как мы госкомпания и закупать зарубежные решения не можем

·         Решение должно уметь генерировать автотесты

·         Решение должно иметь возможность интегрироваться с TMS TestIT, так как мы храним тестовую документацию в нём

·         Решение должно быть безопасным, обеспечивать контроль отправляемых данных и кастомизироваться

Далее мы приступили к исследованию различных вариантов решений.

Исследование вариантов решения

Мы сравнили 3 решения на рынке, которые так или иначе подходят для решения поставленной задачи (таблица 1)

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

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

·         Необходимо обучать сотрудников правильному написанию промптов

·         Качество выданного результата GPT зависит от уровня подготовки сотрудника

·         Подготавливать данные для запроса в GPT и обрабатывать полученный результат необходимо вручную

·         Отсутствие контроля отправляемых в GPT данных

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

Реализация своего решения

Мы начали с подбора стека технологий и проработки архитектуры.

По стеку мы разбили планируемую реализацию на 2 этапа: MVP и продуктивное решение.

Также мы определили набор библиотек, которые будем использовать:

•      Telebot – библиотека для реализации ботов в Telegram, позволяет быстро настроить и запустить бота

•      Requests – удобная библиотека для отправки REST-API запросов

•      G4f – библиотека, позволяющая использовать gpt (open AI) без регистрации и создания аккаунтов

•      Jira – библиотека, позволяющая настроить интеграцию с Jira без самостоятельной реализации взаимодействия

•      Psycopg2 – библиотека для взаимодействия с СУБД PostgreSQL

•      Confluence – библиотека, позволяющая настроить интеграцию с Confluence без самостоятельной реализации взаимодействия

•      Spacy – NLP библиотека, имеющая российский словарь

Также были проработаны основные функции в формате пользовательского пути. На рисунке 3 изображены функции для ручного тестировщика, на рисунке 4 – функции для ручных тестировщиков и автоматизаторов. 

После проработки архитектуры и понимания, какие функции нам нужны, мы приступили к разработке решения и в рамках MVP реализовали весь запланированный объём функциональности. Также мы придумали название для решения – «Ассистент тестировщика».

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

Рассмотрим, как работает ассистент, на примере генерации тестовых кейсов по описанию из тикета в Jira:

1) Пользователь выполняет команду /help и получает в ответ набор функций, который может использовать (рисунок 5).

2)    Пользователь выполняет одну из предложенных команд, например, /getcasejira (рисунок 6). В ответ возвращается набор дальнейших шагов. В случае выполнения первого запроса – добавляется пункт с передачей токена для получения информации из Jira, в текущем кейсе пользователь уже был авторизирован и сессия сохранена в системе, поэтому повторный ввод токена не требуется.

3)    Пользователь передаёт инструмент генерации, а также идентификатор тикета, по информации из которой будет проходить генерация (рисунок 7).

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

4)    Пользователю также приходит сообщение, в котором описана вариация – можно вызвать метод /getMoreCases, который сгенерирует дополнительные кейсы без дублирования уже готовых, благодаря сохранению контекста беседы. Либо можно отправить текущий объём кейсов в комментарий к тикету, либо в TMS (рисунок 8).

5)    В случае вызова функции генерации дополнительных кейсов после завершения операции отправляем в Jira полученный результат (Рисунок 9).

6)    В случае отправки кейсов в TMS TestIT – вызываем метод /sendToTestit, передаем название проекта и секции, куда добавляем сгенерированные кейсы (Рисунок 10).

В указанной секции с тестовыми кейсами создаётся «подсекция» со сгенерированными кейсами, название которой пишется по определённому набору правил — для кейсов из Jira – {Идентификатор тикета}: {Название тикета} (Рисунок 11).

Как попробовать нашего «ассистента» тестировщика

Мы решили предоставлять данный инструмент всем желающим, поэтому разместили всё необходимое для разворачивания на Github —  https://github.com/domrf-tech-qa/gpt-bot/tree/main

Мы выложили исходный код, все заинтересованные могут поучаствовать в развитии нашего ассистента, а также кастомизировать его под свои задачи и цели. Также мы предоставили готовый собранный docker контейнер, ссылка на docker hub указана в readme.md, а также инструкция по развёртыванию (рисунок 12) и пользовательские инструкции.

Что необходимо для старта:

·         Сервер с unix подобной ОС

·         Наличие docker на сервере

·         Доступ к ресурсу api.telegram.org

·         Доступ к внешним GPT-моделям

Оценка внедрения

На текущий момент пользовательское тестирование успешно завершено, мы оценили влияние внедрения на различные метрики и увидели отличные результаты (рисунок 12)

1)    Лучше всего для решения наших задач показал себя YandexGPT3 pro

2)    Благодаря внедрению ассистента покрытие автотестами наших продуктов выросло на 20%

3)    Время на разработку API тестов сократилось на 30%

4)    Время на подготовку артефактов тестирования сократилось на 30%

5)    Время поставки изменений сократилось на 10%

6)    Время на разработку API тестов сократилось на 50%

Заключение

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