ИИ в тестировании ПО: что изменилось, а что нет

Что ИИ в тестировании ПО действительно изменил

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

• Тот, кто чинит, часто не человек. Когда падение разбирает агент, пишущий код, формат вывода важнее дашборда. Скриншот больше не считается результатом.

Что не изменилось

Что стало сложнее

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

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

Привычка, которую стоит завести

Намеренно сломайте что-нибудь и убедитесь, что проверка загорелась красным. Это займёт минуту и это единственное доказательство того, что проверка — сгенерированная или написанная руками — вообще связана с вашим продуктом.

Метрика, которая вводит в заблуждение быстрее всех

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

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

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

С чего начать

Дашборд закрывает то же самое для тех, кто не хочет ничего ставить локально, а полный набор команд описан в репозитории CLI.

Если пайплайном владеет другая команда, GitHub App — путь наименьшего сопротивления: это вебхук, он ничего не меняет в вашем репозитории и срабатывает, когда ваша сборка сообщает, что новая версия развёрнута. Если же вы хотите видеть проверку прямо в репозитории, то шаг GitHub Actions делает именно это.

Что TestSprite делает с той частью, которая стала сложнее

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

Проблема независимости решается тем, где находится проверка. Она прогоняет развёрнутое приложение против описанного вами поведения, а не против собственных допущений кода, — именно это делает её информативной, когда и реализация, и её юнит-тесты пришли от одного и того же агента.

Что не изменилось — не изменилось и здесь: вы по-прежнему решаете, что считать правильным, а тестовые данные и окружения по-прежнему на вас. Выигрыш в том, что покрытие перестаёт отставать от скорости, с которой появляется код.