Практика тестирования веб-приложений

Практика тестирования веб-приложений

Введение

В этом уроке мы объединим всё, что изучили в модуле 9, и разберём практический подход к тестированию веб-приложения. На примере типичной формы регистрации + входа посмотрим, как системно охватить все важные сценарии — от happy path до попыток взлома.

Сквозной подход к тестированию фичи

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

1. Изучить требования

Что должна делать регистрация? Какие поля? Какие правила валидации? Что происходит после успешной регистрации?

2. Написать тест-план

До начала тестирования определи, что именно будешь проверять.

3. Выполнить тесты по чеклисту

Проходи по пунктам, фиксируй результаты.

4. Оформить найденные баги

Каждый дефект — отдельный тикет в Jira с шагами, скриншотом, окружением.

Чеклист тестирования веб-формы

Happy path (основной сценарий)

• Заполнить все поля корректными данными → успешная регистрация
• Получить confirmation email (если предусмотрен)
• Войти с созданными данными → успешная авторизация
• После входа — правильный редирект на нужную страницу

Обязательные поля

• Отправить полностью пустую форму → все обязательные поля подсвечены
• Оставить пустым каждое поле по очереди → только это поле выдаёт ошибку
• Проверить сообщения об ошибках: понятны ли они? Рядом с нужным полем?

Валидация полей

Дублирование данных

• Зарегистрироваться с уже существующим email → понятное сообщение об ошибке
• Не должен показываться технический стек-трейс

Безопасность

Адаптивность и кросс-браузерность

• Форма корректно отображается на мобильном (320px)
• Все поля достижимы и кликабельны на тач-экране
• Проверено в Chrome и Firefox (минимум)
• Проверено в Safari (если есть доступ)

Навигация с клавиатуры

• Tab — переход между полями в логичном порядке
• Enter — отправка формы
• Shift+Tab — обратный обход

Производительность

• Страница загружается за разумное время (< 3 секунды на обычном интернете)
• Нет лишних запросов в Network (дублирование, утечки)
• Console без ошибок после каждого действия

Mindset тестировщика: выход за рамки happy path

Думай как пользователь-новичок: что может быть непонятным? Где он может ошибиться?

Думай как атакующий: что если вставить скрипт? Что если изменить запрос в DevTools? Что если обойти валидацию на фронтенде?

Думай как пользователь в плохих условиях: медленный интернет (Slow 3G в DevTools), маленький экран, старый браузер, неожиданный разрыв соединения.

Использование DevTools во время практики

Шаг 1: Открой DevTools (F12) до начала тестирования
Шаг 2: Перейди на вкладку Network, включи запись
Шаг 3: Выполняй действия в приложении
Шаг 4: После каждого действия:
  - Проверь Console на ошибки
  - Проверь Network: код ответа, тело ответа
  - Если нужно — Application: что изменилось в storage

Типичные баги в формах регистрации/входа

Итоги модуля

В модуле 9 мы разобрали:

• Архитектуру веб-приложений: браузер → веб-сервер → бэкенд → БД
• Жизнь HTTP-запроса: DNS → TCP → TLS → запрос → ответ → рендеринг
• URL: структура, query string, URL-кодирование, что тестировать
• Браузер: движки, рендеринг, кэш, кросс-браузерное тестирование
• UI-элементы: поля, кнопки, модалы, таблицы, формы — что проверять
• Хранилище: cookies, sessionStorage, localStorage — различия и тесты
• DevTools: Elements, Console, Network, Application, Lighthouse
• Баг-репорты в Jira: структура, Severity vs Priority, жизненный цикл
• Практика: систематический подход к тестированию веб-формы

Что мы запомним

• Тестирование формы = happy path + обязательные поля + валидация + дублирование + безопасность + адаптивность + кросс-браузер
• Открывай DevTools (F12) до начала тестирования — Console и Network должны быть на виду
• Думай как новичок, как атакующий и как пользователь в плохих условиях
• XSS (<script>) и SQL-инъекция (' OR 1=1) — обязательные проверки безопасности
• Каждый найденный баг → отдельный тикет в Jira с шагами, ожидаемым/фактическим результатом и скриншотом