Инструменты UI-тестирования: что проверить, прежде чем выбрать

Инструменты UI-тестирования, проверка первая: что будет при редизайне

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

Просите вендора не рассказывать об этом, а показать на демонстрации.

Проверка вторая: кто напишет двухсотый тест

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

Проверка третья: как выглядит падение для того, кто будет его чинить

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

Проверка четвёртая: считается ли успешным прогон, не дошедший ни до одной проверки

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

Упражнение, которое стоит провести

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

Что конкретно спрашивать про падения

Успешный прогон вам покажет любой вендор. Полезные пять минут любой демонстрации — это просьба показать упавший; смотреть здесь надо на три вещи.

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

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

И сможет ли с этим работать агент. Всё чаще баг чинит не человек, и это меняет представление о хорошем отчёте о падении сильнее, чем что-либо ещё за последнее десятилетие.

Издержки, которые есть у любого из них

Та же настройка доступна в панели TestSprite, если вы не хотите ничего ставить локально. Остальные возможности CLI — в репозитории CLI.

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

Как TestSprite отвечает на эти четыре проверки

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

Четвёртую стоит проверить самостоятельно на любом пробном периоде, в том числе на нашем. Сломайте сохранение так, чтобы данные не сохранялись, и убедитесь, что проверка краснеет.

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