Браузерная проверка отвечает на вопрос, может ли человек пройти реальный интерфейс: открыть страницу, найти нужное действие, заполнить форму и понять результат. Скриншот одной ширины отвечает только на вопрос о внешнем виде одного состояния.
Пройди путь, а не список кнопок
Для приложения заявок задай тестовый маршрут: открыть страницу → перейти к форме → отправить пустые поля → увидеть ошибки → заполнить корректные данные → отправить → получить подтверждение. Затем повтори путь при отключённом интернете или ошибке сервера. Подтверждение должно появляться только после ответа приложения, который означает успешную операцию, а не после клика.
В автоматизации Playwright выбирай элемент по роли и доступному имени, например кнопку с понятной подписью. Официальные рекомендации предупреждают, что длинные CSS/XPath селекторы зависят от внутренней структуры DOM и ломаются при рефакторинге. После действия используй ожидание видимого результата, URL или сообщения состояния. Автоматическое ожидание не заменяет правильное условие.
Проверь четыре группы
Навигация. Главные ссылки ведут на ожидаемые маршруты, внутренние страницы открываются прямым URL, неизвестная страница показывает осмысленный 404. Проверь назад/вперёд и обновление страницы.
Форма. Подписи связаны с полями; клавиатурой можно пройти все действия; ошибка указывает, что исправить; отправка блокирует непреднамеренный повтор; отказ сервера не выглядит успехом. Если форма создаёт данные, подтвердить запись нужно на тестовом backend.
Экран. Пройди несколько CSS viewport ширин: узкий мобильный экран, распространённый ноутбук и увеличенный масштаб. Ищи не пиксельное совпадение, а обрезанный текст, горизонтальную прокрутку, перекрытые кнопки и недоступный диалог. Измени содержимое на длинные названия и пустые данные.
Сеть. В инструментах браузера смотри статус и payload запросов на тестовых данных. Проверь отказ API, задержку и повтор. HTTP 200 говорит о статусе конкретного ответа, но не обязательно о том, что нужный бизнес-эффект завершён.
Составь короткий smoke-тест
Начни с пяти действий, которые критичны для пользователя. Для каждого зафиксируй стартовое состояние, действие и ожидаемый наблюдаемый результат. Затем добавь негативный сценарий к каждому действию с последствиями: неправильный ввод, потеря сети, отказ доступа или пустой ответ. Это удержит проверку компактной и предметной.
Добавь отдельный маршрут клавиатурой: начни с адресной строки, переходи через Tab, смотри видимый фокус, открывай меню клавишей и закрывай диалог ожидаемым способом. Проверь, что после ошибки фокус и сообщение остаются понятными. В мобильной ширине не оценивай только уменьшенный desktop: проверь, доступны ли все действия, можно ли прокрутить модальное окно и не заслоняет ли системная клавиатура поле.
Для форм с внешними интеграциями раздели тесты по границам. Browser test может проверить входные поля и ожидаемое сообщение; mock-server — ответ endpoint; sandbox поставщика — обмен сообщениями в тестовой среде. Реальная доставка письма или подтверждение оплаты требует результата самого provider, а не только зеленого browser test. Составь запись проверки: среда, commit, браузер, сценарий, ожидаемое/фактическое поведение и ссылки на безопасные логи. Так можно повторить проверку после следующего изменения.
Сравнение скриншотов полезно для регрессии макета, но может давать шум из-за шрифтов и динамических данных. Проверки доступных ролей, текста, URL и сетевого эффекта обычно объясняют, что сломалось. Ни созданный screenshot, ни зелёный браузерный тест не доказывают production-оплату или доставку внешнего письма.
Источники: Playwright — локаторы, Playwright — assertions, Playwright — лучшие практики.
Приоритизируй сценарии по риску
Если времени мало, сначала проверь route, от которого зависит главная задача: регистрация, создание заказа, загрузка файла или отмена подписки. Для каждого пути пройди три набора данных — обычный, граничный и ошибочный. Затем проверь второстепенные страницы на доступность и responsive defects. Это лучше, чем пройти все ссылки один раз только на happy path.
Сделай условия теста детерминированными: закрепи timezone, случайный seed, фиктивный API response и базовые тестовые пользователи. Укажи viewport и браузер. Если интерфейс тестирует третья сторона, например платежный iframe, проверь официально поддерживаемые варианты test-mode; не пытайся обходить проверку или взаимодействовать с реальными пользователями.
После релиза сохраняй несколько production smoke checks, которые только читают публичную страницу, и отдельный безопасный тест транзакционного процесса в sandbox. Не отправляй настоящую форму каждый запуск в неизвестный inbox. Если нужно проверить реальную доставку, назначь контролируемый адрес и четко отметь операторский тест.