Как проверить пользовательские сценарии сайта перед запуском

Разработчик нажимает кнопку в знакомом браузере и видит ожидаемый экран. Реальный пользователь приходит по ссылке из Telegram, открывает сайт с телефона, ошибается в поле, возвращается после перерыва или повторяет действие из-за медленной сети. Дефект часто появляется между экранами: состояние потерялось, запрос выполнился дважды, сообщение об ошибке ничего не объясняет.

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

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

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

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

Для форм проверьте пустые обязательные поля, неверный формат и граничные значения. Браузерная constraint validation улучшает обратную связь, но её легко обойти. Сервер обязан самостоятельно проверять входные данные. Сообщение об ошибке должно объяснять следующий шаг, а интерфейс не должен оставаться в бесконечном ожидании или показывать технический stack trace.

Обычный профиль браузера уже хранит cookies, local storage и авторизацию, поэтому может скрывать проблему нового пользователя. Откройте отдельный профиль, закройте остальные окна Incognito или создайте новый BrowserContext. Затем повторите путь в состоянии вернувшегося пользователя.

Incognito не является точной копией обычного нового пользователя: у него свои правила для сторонних cookies, а несколько открытых приватных окон разделяют одну сессию. Для воспроизводимого автотеста Playwright создаёт свежий изолированный BrowserContext для каждого теста.

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

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

Форму нужно пройти клавиатурой: Tab движется в логичном порядке, фокус виден, каждое поле имеет понятную подпись. Затем откройте критический путь на реальном сенсорном устройстве из целевой матрицы. Проверьте размер элементов, экранную клавиатуру и видимость кнопки отправки.

Device Mode и мобильная эмуляция полезны для быстрых проверок ширины, touch и user agent, но остаются приближением. Реальное устройство нужно хотя бы для главного мобильного пути. Медленную сеть и полный offline проверяйте отдельно: пользователь не должен увидеть ложный успех, потерять введённые данные без предупреждения или случайно повторить опасную операцию.

Начните с покрытого сценария, который быстро сигнализирует о регрессии. В Playwright взаимодействуйте с видимым пользователю интерфейсом. Предпочитайте locators по роли, accessible name и label вместо длинных CSS- или XPath-цепочек. Для ожиданий используйте web-first assertions, которые повторяют проверку до успеха или таймаута.

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

Lighthouse проводит автоматизированные аудиты страницы по performance, accessibility, SEO и другим категориям. Это полезный дополнительный слой. Хороший отчёт не доказывает, что регистрация, заказ, оплата или восстановление после ошибки завершаются правильным бизнес-результатом.

Не превращайте один Performance score в абсолютную оценку продукта: результат зависит от условий запуска. Используйте Lighthouse вместе с ручными сценариями и E2E-тестами, а не вместо них.

Успешная сборка не проверяет публичный маршрут, переменные среды, базу, внешние сервисы и reverse proxy в фактической версии. После развёртывания повторите короткий безопасный путь на публичном URL и подтвердите главный результат.

Smoke не должен создавать реальную оплату, рассылку или чужие данные. Используйте read-only шаги либо маркированные тестовые сущности с заранее определённой очисткой. Если проверка не прошла, сохраните среду, шаг воспроизведения и доказательство, затем остановите выпуск или откатите его по принятой процедуре.

1. Критические пути привязаны к реальным целям продукта.
2. Для каждого пути определён проверяемый итог.
3. Новый и вернувшийся пользователь проверены раздельно.
4. Ошибки ввода проходят клиентскую и серверную проверку.
5. Повтор опасного действия не создаёт неожиданные дубли.
6. Медленная сеть и offline дают понятное восстановление.
7. Формы доступны с клавиатуры и реального телефона.
8. Автотест проверяет пользовательский результат, а не детали DOM.
9. Lighthouse используется как дополнительный аудит.
10. После развёртывания запланирован безопасный smoke.

• «У меня работает». Повторите путь в новой независимой сессии и с ролью без нужного права.
• «Тест зелёный, но пользователь не может продолжить». Проверьте, что assertion подтверждает видимый и серверный результат, а не только наличие элемента.
• «На телефоне кнопки нет». Проверьте реальное устройство: экранная клавиатура может закрывать кнопку, а эмуляция этого не покажет.
• «После retry появилось два результата». Сверьте кратность в серверном состоянии и правила идемпотентности именно для этой операции.
• «Lighthouse зелёный, а заказ не создаётся». Это разные классы проверки: отчёт страницы не заменяет продуктовый путь.

Сайт готов к запуску в пределах проверенного набора, когда критические пути имеют ожидаемые результаты, негативные состояния понятны пользователю, доказательства воспроизводимы, а post-deploy smoke безопасен. Этот вывод не означает отсутствие всех дефектов: он описывает проверенное покрытие и оставшиеся риски.

Сверяйте весь выпуск по разделу «Гайды и рабочие сценарии» «Человек 2.0». В Среде внедрения ИИ такие проверки собираются в повторяемую практику: сценарии, автотесты, browser QA, логи, откат и доказательство результата.

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

Можно ли ограничиться Incognito? Нет. Это полезная отдельная сессия, но у неё собственные настройки. Для стабильного теста используйте отдельный профиль или новый BrowserContext и явно готовьте состояние.

Lighthouse заменяет ручную проверку? Нет. Он проверяет набор характеристик страницы, но не подтверждает бизнес-результат последовательности действий.

Как тестировать оплату? Только в тестовом режиме платёжного провайдера или в другой специально разрешённой среде. Не создавайте реальные списания ради smoke-проверки.

• Playwright: Best Practices: https://playwright.dev/docs/best-practices
• Playwright: Writing Tests: https://playwright.dev/docs/writing-tests
• Playwright: Locators: https://playwright.dev/docs/locators
• Playwright: Assertions: https://playwright.dev/docs/test-assertions
• Playwright: Emulation: https://playwright.dev/docs/emulation
• MDN: Client-side form validation: https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation
• MDN: Constraint validation: https://developer.mozilla.org/en-US/docs/Web/HTML/Guides/Constraint_validation
• web.dev: Test forms across platforms: https://web.dev/learn/forms/cross-platform-testing/
• Chrome DevTools Device Mode: https://developer.chrome.com/docs/devtools/device-mode/
• Chrome DevTools Network: https://developer.chrome.com/docs/devtools/network/reference/#offline
• Lighthouse overview: https://developer.chrome.com/docs/lighthouse/overview
• Google Cloud Deploy: verify a deployment: https://docs.cloud.google.com/deploy/docs/verify-deployment
• Google SRE: Canarying Releases: https://sre.google/workbook/canarying-releases/