ИИ для тестирования API. Где он помогает, а где обманывает

Проверка не может быть вероятностной

У любой языковой модели есть параметр случайности, поэтому на один и тот же вопрос она отвечает по-разному. Сегодня она скажет, что ответ API корректный, а завтра найдёт в том же ответе проблему. Для черновика письма это не страшно. Для проверки это приговор, потому что смысл проверки в повторяемости. Если результат меняется сам по себе, вы не знаете, что именно сломалось, релиз или инструмент.

Вторая беда в том, что модель не показывает основания. Она пишет «всё в порядке» и не объясняет, какое поле смотрела и по какому правилу. Прийти с таким к разработчику нельзя, потому что первый же вопрос про конкретное поле остаётся без ответа. Проверка ценна ровно тем, что называет нарушенное ожидание, а не настроение модели.

Проверять за нейросетью дороже, чем сделать самому

Знакомая история. Модель уверенно выдаёт двести строк проверок, выглядит убедительно, а внутри половина привязана к полям, которых в ответе нет. Чтобы это увидеть, приходится прочитать всё и сверить с документацией, то есть выполнить ту самую работу, которую вы хотели отдать. На выходе времени ушло больше, а доверия к результату меньше.

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

Где нейросеть действительно помогает

Будет нечестно сказать, что она бесполезна. Она хорошо работает там, где ошибка не стоит ничего, а результат всё равно проверит человек.

• Черновик идей. Спросить, что ещё стоит проверить в этом методе, и получить список, из которого вы возьмёте четверть.
• Объяснение чужого формата. Незнакомый XML или мутное поле в документации она распишет быстрее, чем вы найдёте нужную страницу.
• Тестовые данные. Придумать сто правдоподобных адресов или наименований товара скучно, и это как раз её работа.
• Черновик текста. Описание дефекта, письмо, заготовка отчёта.

Заметьте, во всех четырёх случаях решение о том, что считать нормой, остаётся за вами. Как только это решение отдаётся модели, начинаются сюрпризы.

Ваши ответы API в чужой модели

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

Что мы сделали вместо этого

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

Кому это близко

Если вам говорят, что проверки теперь нужно отдать нейросети, а вы понимаете, что после неё придётся перепроверять всё руками, вы не ретроград. Вы просто отвечаете за результат. Инструменту проверки положено быть скучным, повторяемым и объяснимым, и в этом нет ничего старомодного.

Рядом полезно почитать сравнение с Postman, правила для JSON и XML и поиск логов в Kibana.