Автоматизированное тестирование UI и коэффициент сопровождения

Что снижает этот показатель в автоматизированном тестировании UI

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

Момент, когда набор тестов умирает

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

Никто не решает перестать доверять набору тестов. Доверие размывается само.

Как защитить этот показатель

• Чините нестабильные тесты, прежде чем добавлять новые. Непопулярно и верно. Новый тест, добавленный в набор, который все игнорируют, не имеет ценности.

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

• Относитесь к перезапуску как к находке. Если тесту понадобился перезапуск, что-то не так с самим тестом или с окружением. Зафиксируйте это, а не идите дальше.

Структурная часть

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

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

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

Как вернуть упавший показатель

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

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

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

Запускайте там, где падения обходятся дешевле всего

На каждом pull request, чтобы падение указывало на одно изменение, а не на неделю изменений.

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

• GitHub Actions встраивает этот шаг в ваш собственный workflow, настраиваемый из терминала.

Как TestSprite защищает этот показатель

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

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

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