Проверка пользовательского сценария

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Тестировщику Разработчику Аналитику

Теория данных (раздел 3)

Проверка в БД — SQL для тестировщика, Основы БД, транзакции, PostgreSQL. Карта — о разделе.

Практикум №3. Вы прошли основы и документацию. Здесь — ручная проверка сценария "как пользователь" — форма регистрации, чек-лист, затем автоматизация на Selenium и сквозной E2E. Сначала руками — потом код; так работает большинство команд.

Play ITЗагрузка интерактивного демо…

---

Проверка пользовательского сценария

Сценарий (user flow) — путь человека к цели — зарегистрироваться, положить товар в корзину, оплатить. Тестировщик воспроизводит этот путь и сравнивает результат с ожиданием.

В рамках этого материала мы создадим простую веб-форму регистрации, протестируем её функциональность вручную, напишем автоматизированный скрипт на базе Selenium и реализуем полный сквозной (End-to-End) сценарий, включающий регистрацию и добавление товара в корзину.

---

Создание формы регистрации

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

Создайте файл index.html со следующим содержимым:

Код ITЗагрузка примера кода…

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

---

Функциональное тестирование интерфейса

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

---

Требования к форме

Форма регистрации должна удовлетворять следующим условиям:

1. Поле "Имя" является обязательным. Система не принимает пустое значение.
2. Поле "Email" должно соответствовать формату электронной почты (наличие символа @ и доменной зоны).
3. Поле "Пароль" должно содержать не менее шести символов.
4. При успешном заполнении всех полей система выводит сообщение об успехе и очищает форму.
5. При наличии ошибок система подсвечивает конкретное поле и выводит текстовое описание проблемы.

---

Составление чек-листа действий

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

№	Действие	Ожидаемый результат	Статус
1	Оставить все поля пустыми и нажать кнопку	Появляются сообщения об ошибках для всех трех полей	Выполнено
2	Заполнить только поле "Имя", остальные оставить пустыми	Сообщения об ошибках появляются для Email и Пароля	Выполнено
3	Заполнить имя и пароль, ввести Email без символа @	Сообщение об ошибке появляется только для Email	Выполнено
4	Заполнить имя и email, ввести пароль из 4 символов	Сообщение об ошибке появляется для Пароля	Выполнено
5	Заполнить все поля корректными данными	Появляется зеленое сообщение об успехе, форма очищается	Выполнено
6	Ввести длинное имя (более 50 символов)	Данные принимаются, ограничений нет (или есть ограничение, если задано)	Выполнено
7	Нажать кнопку без ввода данных	Система блокирует отправку и показывает ошибки	Выполнено

---

Ручное тестирование

Процесс ручного тестирования начинается с открытия страницы в браузере. Тестировщик последовательно выполняет шаги из чек-листа.

Сценарий 1: Ввод невалидных данных Запустите страницу. Оставьте все поля пустыми. Нажмите кнопку "Зарегистрироваться". Ожидаемый результат — появление красных сообщений под каждым полем. Это подтверждает работу клиентской валидации. Если сообщение не появилось, это критическая ошибка.

Сценарий 2: Ввод неправильного формата Email Введите имя "Иван", пароль "123456". В поле Email введите текст "ivanexample.com". Нажмите кнопку. Система должна выделить ошибку именно в поле Email, игнорируя другие поля. Это демонстрирует точность работы алгоритма проверки формата.

Сценарий 3: Ввод валидных данных Введите имя "Анна", Email "anna@test.ru", Пароль "secret1". Нажмите кнопку. Через мгновение должно появиться зеленое сообщение "Успешная регистрация!". Через две секунды система должна имитировать переход в корзину и очистить поля формы. Это подтверждает положительный сценарий использования.

Если на каком-либо этапе поведение системы отличается от ожидаемого, тестировщик фиксирует дефект, описывает шаги воспроизведения и прикладывает скриншоты.

---

Автоматизация UI с помощью Selenium

Автоматизация тестирования позволяет повторять рутинные операции без участия человека, что экономит время и снижает вероятность человеческой ошибки. Для автоматизации взаимодействия с браузером используется библиотека Selenium WebDriver.

---

Установка окружения

Для работы с Selenium требуется установить Python и саму библиотеку. Также необходим драйвер для конкретного браузера. В данном примере используется Google Chrome.

Установите необходимые пакеты через терминал:

pip install selenium webdriver-manager

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

---

Написание скрипта автоматизации

Скрипт открывает браузер, переходит на страницу регистрации, заполняет поля и проверяет наличие сообщений об ошибках.

Код ITЗагрузка примера кода…

В этом скрипте используются следующие ключевые компоненты:

• WebDriverWait обеспечивает ожидание появления элементов на странице, что критично для динамических сайтов.
• find_element ищут элементы по идентификатору, классу или другим атрибутам.
• send_keys имитирует ввод текста пользователем.
• click эмулирует нажатие кнопки мышью.
• Блок try...finally гарантирует закрытие браузера даже при возникновении ошибки.

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

---

End-to-End (сквозное) тестирование

End-to-End тестирование проверяет полную цепочку взаимодействия пользователя с системой. Цель состоит в том, чтобы убедиться, что все модули системы работают согласованно при реальном использовании. В нашем случае это процесс от регистрации до добавления товара в корзину.

---

Полный сценарий

Сценарий включает следующие этапы:

1. Пользователь проходит процедуру регистрации.
2. После успешной регистрации система перенаправляет его на главную страницу магазина.
3. Пользователь выбирает товар и добавляет его в корзину.
4. Система отображает подтверждение добавления товара.
5. Корзина обновляется с учетом нового товара.
6. Данные временной сессии очищаются для подготовки к следующему прогону.

---

Реализация сценария в коде

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

Код ITЗагрузка примера кода…

Про ожидания в UI-автотестах

В учебном HTML "переход" может быть имитирован задержкой в JS — в боевых тестах вместо time.sleep() используйте явные ожидания (WebDriverWait, auto-waiting в Playwright). Подробнее: E2E и системное, документация по Selenium.

---

Очистка данных

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

• Очистки полей ввода.
• Удаления созданных тестовых записей из базы данных (если она доступна).
• Закрытия всех открытых вкладок и завершения процесса браузера.

В реальном проекте очистка данных часто выполняется через API или транзакции базы данных, которые откатывают изменения после теста. В нашем примере мы используем метод .reset() формы и явное закрытие драйвера.

---

Как превратить чек-лист в управляемый набор проверок

Обычный список шагов быстро устаревает. Чтобы чек-лист оставался полезным, добавляйте к каждому пункту:

• предусловия (какая роль, какие данные, в каком браузере);
• ожидаемый результат в измеримой форме;
• ссылку на требование или user story;
• пометку приоритета (critical, major, minor).

Так чек-лист становится основой для:

• ручного регресса;
• передачи задач между тестировщиками;
• последующей автоматизации на Selenium/Playwright.

Подход к проектированию таких проверок подробно раскрыт в техниках тест-дизайна.

---

Негативные сценарии, которые часто пропускают

Для формы регистрации полезно расширить покрытие:

• email с пробелами в начале и конце;
• уже существующий email в системе;
• пароль с юникодом и спецсимволами;
• двойной клик по кнопке "Зарегистрироваться";
• обновление страницы в момент отправки;
• медленная сеть и повторная отправка запроса.

Эти сценарии показывают устойчивость UI и связанного API в реальных пользовательских условиях.

---

Переход от ручной проверки к автотестам

Рабочая последовательность для команды:

1. Ручной прогон фиксирует критичные пути и уязвимые зоны.
2. Из чек-листа выбираются стабильные сценарии с высокой частотой запуска.
3. Эти сценарии переводятся в UI-автотесты.
4. Нестабильные или редко используемые пути оставляют в исследовательском ручном тестировании.

Такой баланс снижает стоимость поддержки автотестов и сохраняет качество релизов. Для выбора инструментов и стратегии смотрите автоматизацию тестирования, каталог инструментов, Selenium и Playwright.

---

Release-кейс — что проверять за час до выкладки

Перед релизом полезен короткий UI smoke по критическому пути:

1. логин пользователя;
2. ключевое целевое действие (например, оформление заказа);
3. проверка статуса операции и уведомления пользователю;
4. проверка базовой навигации и выхода из аккаунта.

Если smoke выявляет блокер, релиз останавливают до фикса. Такой подход экономит часы на разборе инцидентов в продакшене и хорошо сочетается с жизненным циклом тестирования.

---

Шаблон артефакта — pre-release UI smoke

UI Smoke (pre-release):
[ ] Логин под ролью "покупатель"
[ ] Открытие главной и карточки товара
[ ] Добавление в корзину и оформление заказа
[ ] Проверка статуса операции и уведомления
[ ] Выход из аккаунта

Результат:
- Build: __________
- Пройдено: __/__
- Blockers: ______
- Решение: release / hold

Шаблон помогает быстро синхронизировать QA, разработку и релиз-менеджера.

---

Готовые поля для Jira и YouTrack

Issue Type: Test Execution
Summary: [UI SMOKE] Pre-release прогон build X
Build/Env: ...
Suite: UI Smoke Critical Path
Passed/Failed/Blocked: __ / __ / __
Blockers:
- BUG-123 ...
Decision: release / hold
Approvals: QA lead, Release manager
Follow-up Tasks:
[ ] Починить блокеры
[ ] Перепроверить smoke

Пример заполнения:

Issue Type: Test Execution
Summary: [UI SMOKE] Pre-release прогон build 3.8.0-rc2
Build/Env: rc2 / staging-eu
Suite: UI Smoke Critical Path
Passed/Failed/Blocked: 9 / 1 / 0
Blockers:
- BUG-742 [Checkout] Кнопка "Оплатить" неактивна после выбора карты
Decision: hold
Approvals: qa.lead, release.manager
Follow-up Tasks:
[x] Починить блокеры
[ ] Перепроверить smoke

---

Навигация по разделу "Тестирование"

• Маршрут: О разделе · Резюме раздела · Карта уровней и практик (Unit / Integration / UI / E2E, TDD, BDD)
• Теория и процесс: Основы · Классификация · Жизненный цикл · Порядок этапов · Артефакты качества
• Уровни проверок: Unit · Integration · E2E, системное и UI · API · Тестовые дублёры · Покрытие кода · White-box · Мутационное тестирование
• Практика QA: Документация · Тест-дизайн · Ручное веб · SQL
• Автоматизация: Стратегия и пирамида · Каталог инструментов · Selenium · Playwright
• Практикум и углубление: Подготовка среды и создание первого теста · Проверка взаимодействия компонентов · Проверка пользовательского сценария · Проверка надежности под нагрузкой · Мобильное · Нагрузка · Безопасность · Самопроверка · Доп. материалы курса · Инструменты с низким кодом для тестирования · Тестирование нейроморфных систем

---