К вопросу из чата: что делать с тестами, которые реально пытаются держать запрограммированные сценарии E2E. Я считаю, что это плохая практика, и как раз мой опыт в Microsoft по работе с такими системами показывал, что они тоже дырявые как решето, т.к. формируют safe path, причём часто нереалистичный, который через UI самому пользователю 1:1 даже не повторить. Поэтому по факту там дальше начинается «война и немцы» с мутационными тестами. Тесты быстро распухают больше кода, но качество почти не растёт.

Поэтому для сценарного тестирования я предпочитаю использовать агентов, которые через MCP действуют с приложением как пользователь. Для ускорения могут иногда вызывать что-то и системное. Отличие от «тупых тестов» тестирования агентом примерно как дельтоплан против Шаттла. Это только кажется, что «одно и то же».

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

Но самое главное — ДИАГНОСТИКА. Агент-тестировщик лазает по логам и коду, поэтому результат его работы — крайне развёрнутый отчёт о проблеме и ещё со срезом проблемных данных. Обычно нормальная кодирующая LLM по таким отчётам баги фиксит в one shot.

Конечно, агенты E2E-тестирования не заменяют все автоматические проверки, для этого я использую «доказательное тестирование» с доказательствами в логе, и агент их смотрит тоже. Однако если у вас нет таких агентов вообще, как на моём скриншоте, то у вас проблемы организации поддержки качества. Точнее, ваши методы скорее не оптимальные.

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