Автоматизация проверки форм на сайте

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

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

Первое, с чего мы начали, — отказались от абстрактной проверки «работает / не работает».

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

Поэтому в качестве основы мы выбрали Playwright.

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

Зачем это было нужно: если форма проходит такую проверку — с высокой вероятностью она работает и для реальных клиентов.

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

Чтобы этого избежать, мы вынесли все элементы форм в отдельный слой — класс Locators. Он хранит локаторы кнопок, полей и сообщений.

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

На этом этапе мы перешли к сценариям тестирования. Мы сознательно отказались от одного «универсального» сценария и реализовали два отдельных варианта.

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

Именно здесь чаще всего возникают проблемы: неправильно размеченные поля, сломанные проверки, ошибки отправки. На практике оказалось, что большинство критичных багов мы ловим именно в этом сценарии.

Оба сценария были заложены как обязательные — без возможности «пропустить».

Когда логика проверки была готова, мы сосредоточились на том, как пользователь будет работать с результатом.

Для запуска тестов мы использовали файл Pytest — он позволил структурировать проверки и запускать их одной командой из консоли, без лишних настроек. Для отчётности подключили Pytest-html.

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

• какая форма проверялась;
• на какой странице;
• по какому сценарию;
• успешно ли отправилась заявка;
• есть ли ошибка и где именно она возникла.

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