КОРУС показал «полуавтомат» для ИИ в тестировании: эталон задаёт человек, а не система

Доклад назывался «Автоматизация тестирования с помощью ИИ: идеи, гипотезы, результаты», материал о нём компания опубликовала на Хабре. Команда разобрала, какие подходы не сработали, и пришла к рабочей схеме. Тезиса о замене тестировщиков аналитиками в анонсе нет: речь о распределении ролей между человеком и машиной.

Что не сработало у команды КОРУС?

Первая гипотеза: генерировать тесты «из выгрузки», то есть из данных, которые уже лежат в системе. Докладчица назвала такой подход тавтологией. Если ожидаемый результат взят из той же системы, тест подтверждает то, что в ней уже записано, включая ошибки.

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

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

Что понадобится для схемы «полуавтомат»?

Ниже моя адаптация схемы из доклада к повседневной работе, а не пересказ конкретного стека КОРУС: инструменты команда в анонсе не называла.

• Нейросеть для подготовки сценариев проверки. Из доступных в РФ, YandexGPT и GigaChat.
• Доступ к рабочей версии продукта с настоящим интерфейсом: сайт, форма, личный кабинет, чат-бот.
• Человек, который знает, как продукт обязан себя вести. Это эталон, его не заменить выгрузкой.
• Таблица или документ, где фиксируется итог: прошло, не прошло, кто подтвердил.

Как собрать полуавтомат по шагам?

1. Человек описывает ожидаемое поведение словами: что пользователь делает и что должен увидеть. Это и есть истина для проверки.
2. Нейросеть получает описание и готовит сценарии проверки, включая нестандартные случаи.
3. Человек отсеивает лишнее и правит сценарии, если машина что-то выдумала. Галлюцинация (когда ИИ уверенно выдумывает то, чего не было) здесь встречается в виде несуществующих кнопок или полей.
4. Сценарии прогоняются через реальный интерфейс, а не через программный обход.
5. Человек сверяет результат с эталоном из первого шага и подтверждает, есть ошибка или нет.

Пример промпта для второго шага:

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

Что делать с этим прямо сейчас, по ролям?

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

Маркетологу стоит проверять лендинги, формы и чат-боты глазами пользователя. Отчёт «всё работает» от системы аналитики не заменяет живой прогон заявки через интерфейс.

Предпринимателю в РФ и СНГ при заказе разработки полезно спросить подрядчика, кто задаёт эталон проверок и как тестируется интерфейс. Схема не требует зарубежных сервисов: подготовку сценариев закрывают YandexGPT или GigaChat.

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