Ручное тестирование веб-приложений
Проверка в БД — SQL для тестировщика, Основы БД, транзакции, PostgreSQL. Карта — о разделе.
Ручное тестирование веб-приложений (Manual Web Testing) — это процесс проверки работоспособности, логики и интерфейса сайта или веб-сервиса силами QA-инженера без использования автоматизированных скриптов. Тестировщик имитирует действия реального конечного пользователя, взаимодействуя с элементами страницы через браузер, чтобы выявить ошибки (баги) и проверить продукт на соответствие техническому заданию.
При ручном аудите веб-ресурса специалист оценивает систему по нескольким основным направлениям:
- Функциональное тестирование: Проверка работы ссылок, кнопок, форм отправки данных, поиска, корзины, фильтров и авторизации.
- Верстка и UI/UX (Интерфейс): Поиск визуальных дефектов (наползание текста, съехавшие блоки), проверка адаптивности макета под разные экраны и оценка удобства навигации (юзабилити).
- Кроссбраузерное тестирование: Проверка корректности отображения и работы веб-приложения во всех популярных браузерах (Google Chrome, Safari, Mozilla Firefox, Яндекс Браузер, Edge).
- Проверка форм и валидации: Ввод в текстовые поля некорректных данных (слишком длинный текст, спецсимволы, пустые значения) для оценки реакции системы.
- Взаимодействие с API (Интеграция): Анализ обмена данными между фронтендом и бэкендом (сервером), часто с помощью встроенных инструментов разработчика.
Для эффективной работы веб-тестировщику не требуются языки программирования, но необходим следующий базовый инструментарий:
- DevTools (Инструменты разработчика в браузере): Вызываются клавишей F12. Позволяют изучать HTML-код, CSS-стили, просматривать консоль на наличие ошибок (Console) и отслеживать сетевые запросы во вкладке Network.
- Postman: Популярная программа для изолированного ручного тестирования API и проверки ответов сервера.
- Расширения для браузера: Плагины для симуляции различных разрешений экранов, проверки контрастности, управления файлами cookies и кешем.
- Таск-трекеры и Bug Tracking системы: Системы вроде Jira, YouTrack или Kaiten для оформления отчетов о дефектах (баг-репортов).
- Системы управления тестированием (TMS): Платформы для ведения чек-листов и тест-кейсов (например, TestIT, TestRail).
Автотесты не заменяют "пожить в продукте руками". Здесь — порядок проверки веба без кода — что открыть, куда смотреть, какие зоны чаще ломаются. Обзор всех тем веб-QA — в маршруте 132. Используйте как чек-лист на каждый релиз или новую фичу.
Что такое ручное тестирование веба
Веб-приложение — сайт, где много логики в браузере — личный кабинет, корзина, админка. Страница общается с сервером через HTTP-запросы (часто JSON — это и есть API "за кулисами").
Ручное тестирование — вы действуете как пользователь — клики, ввод, сравнение с ожиданием. Автотест (Playwright, Selenium) повторяет те же шаги скриптом. Ручная проверка нужна, когда:
- фича новая и сценарии ещё не стабильны;
- нужна оценка "удобно ли" и визуальных мелочей;
- автотестов мало или их ещё нет.
Словарь для первой сессии
Веб-приложение — это сложная система взаимосвязанных элементов. Изменение кода в одном месте может неожиданно «выстрелить» в другом.
| Термин | Простыми словами |
|---|---|
| Стенд | Копия системы для тестов (test., staging.), не боевой прод |
| Smoke | Быстрая проверка "вообще живо": открылось, вошёл, главный путь прошёл |
| Регресс | Старые важные сценарии после изменений — не сломали ли прошлое |
| Сессия | Период, пока сервер "помнит", что вы вошли (cookie, токен) |
| 2xx / 4xx / 5xx | Код ответа HTTP: успех / ошибка клиента / ошибка сервера |
| Flaky | Тест или баг "то есть, то нет" — часто из-за таймингов и сети |
В тестировании и разработке ПО стенд (тестовый стенд, окружение, или environment) — это специально выделенный сервер (или группа серверов), на котором развернута определенная версия веб-приложения со своей базой данных и настройками. Стенды нужны, чтобы изолировать работу разработчиков, тестировщиков и реальных пользователей друг от друга.
Smoke-тестирование (дымовое тестирование) — это самый короткий и поверхностный цикл тестирования, который проверяет, работает ли главная (критическая) функциональность веб-приложения после сборки нового кода. Основная цель «смоука» — быстро понять, стабильна ли новая сборка (билд) на тестовом стенде или она настолько «сырая» и забагованная, что тратить время на её детальную проверку нет смысла. Термин пошел из инженерии: при сборке нового оборудования или ремонте труб в них сначала пускают дым — если он откуда-то повалил, значит, система негерметична, и разбираться дальше нет смысла. Если Smoke-тест не пройден, сборка официально отклоняется, возвращается разработчикам, а тестирование останавливается.
Регрессионное тестирование (Regress / Регресс) — это полная или частичная проверка уже существующей, ранее протестированной функциональности веб-приложения после внесения изменений в код. Главная цель регресса — убедиться, что исправление старых багов или добавление новых фич не сломало те части сайта, которые раньше работали исправно. Регрессионное тестирование проводится на финальных этапах спринта или перед самым релизом на Prod-стенд. Регресс — это самый монотонный, повторяющийся и объемный вид тестирования. Проходить сотни одинаковых тест-кейсов вручную перед каждым релизом долго и неэффективно (QA-инженер «замыливает» глаз). Поэтому регрессионные тесты — главный кандидат на автоматизацию. На современных проектах ручные тестировщики проверяют только новые фичи, а регресс старых функций отдают автотестам, которые запускаются по ночам или при сборке проекта.
В контексте веб-приложений слово сессия (Session) имеет два значения: временной отрезок работы пользователя с сайтом (с точки зрения тестирования) и технический механизм сохранения состояния между независимыми запросами (с точки зрения веб-технологий). Протокол HTTP, на котором работает интернет, не умеет запоминать пользователя. Каждый клик по ссылке — это отдельный, «незнакомый» для сервера запрос. Сессия решает эту проблему: она связывает действия пользователя в единую цепочку, позволяя сайту «узнавать» вас на разных страницах. Для QA-инженера сессии — это критически важный объект тестирования, напрямую влияющий на безопасность и UX проекта.
Flaky-тест (мигающий или нестабильный тест) — это тест, который при абсолютно неизменном коде приложения и неизменных условиях окружения может без видимых причин то успешно проходить (Pass), то падать с ошибкой (Fail). Это один из главных «кошмаров» автоматизации тестирования веб-приложений. Несмотря на то, что термин относится к автоматическим проверкам, ручные QA-инженеры первыми сталкиваются с их последствиями и помогают разработчикам искать причины «мигания».
С чего начать сессию
Контекст баг-репорта (Context / Environment / Окружение) — это обязательная часть отчета о дефекте, которая описывает точные условия, в которых был обнаружен баг. Без четкого контекста разработчик не сможет воссоздать (воспроизвести) баг на своем компьютере, напишет комментарий «Не воспроизводится» (Wontfix / Works for me) и вернет задачу тестировщику. Половина успеха при починке бага — это знание того, где, на чем и под какими учетными данными он произошел. При оформлении баг-репорта в Jira или любой другой системе контекст выносится в отдельный блок параметров (поля) или пишется в самом начале описания.
Перед проверкой зафиксируйте контекст — без этого баг-репорты будут неполными:
| Что записать | Пример |
|---|---|
| URL и стенд | https://test.shop.example/catalog |
| Браузер и версия | Chrome 120, Firefox 115 |
| Разрешение | 1920×1080, мобильная эмуляция 390×844 |
| Учётная запись | qa_user_01, роль "покупатель" |
| Сборка | 2.1.0 (build 4521) |
Chrome DevTools — три вкладки на каждый день
Chrome DevTools (Инструменты разработчика) — это встроенный в браузер Google Chrome комплекс утилит для отладки, тестирования и анализа веб-приложений. Для ручного тестировщика DevTools является главным рабочим инструментом. Он позволяет заглянуть «под капот» сайта, увидеть его скрытую логику, найти причины багов и проверить верстку без доступа к исходному коду на сервере. Интерфейс DevTools разбит на панели.
Откройте Chrome DevTools (F12):
| Вкладка | Зачем QA |
|---|---|
| Elements | Вёрстка, скрытые элементы, атрибуты кнопок |
| Console | Ошибки JavaScript (красные строки) — часто объясняют "белый экран" |
| Network | Ушёл ли запрос на сервер, какой статус и тело ответа |
Подробнее про API через DevTools: Тестирование и анализ API. Как устроены вкладки с точки зрения разработчика — DevTools в браузере.
Включите Preserve log, выполните действие (логин, "В корзину"), найдите запрос по имени (login, cart). Клик → Headers (статус), Response (JSON с ошибкой). Этот скрин спасает разработчика час отладки.
Порядок проверки (типовой сценарий)
- Smoke — сайт открывается, логин работает, главный сценарий проходит за 5–10 минут.
- Функциональность — по требованиям или тест-кейсам.
- Негативные сценарии — пустые поля, неверный формат, двойная отправка.
- Границы — длинные строки, спецсимволы, кириллица и латиница.
- Сессия и безопасность — выход, истечение токена, кнопка "Назад" в браузере.
- Совместимость — второй браузер, уменьшенное окно, мобильная вёрстка.
- Регресс — старые критичные сценарии после фикса.
Оформляйте находки сразу по шаблону из Документации тестировщика. Хороший баг = воспроизводимые шаги + скрин + вкладка Network при ошибке API.
Чек-лист — формы и ввод
| # | Проверка | На что смотреть | Пример дефекта |
|---|---|---|---|
| 1 | Обязательные поля | Сообщение при пустой отправке, фокус на первом ошибочном поле | Отправка пустой формы создаёт заказ |
| 2 | Маски и форматы | Телефон, email, ИНН — принимается только валидное | abc в поле телефона проходит |
| 3 | Границы длины | min/max символов: обрезка или явная ошибка | 10 000 символов в "комментарий" — 500 на сервере |
| 4 | Пробелы | В начале/конце строки — trim или отказ | Логин " user " не находится |
| 5 | Копипаст | Из Word/PDF — невидимые символы | Поле "ломается" после вставки из PDF |
| 6 | Двойной submit | Два быстрых клика "Оплатить" | Два заказа и два списания |
| 7 | Tab-порядок | Форма проходится с клавиатуры | Фокус прыгает в случайном порядке |
| 8 | Автозаполнение | Браузер подставил старые данные | Сломалась валидация после autofill |
Применяйте техники тест-дизайна: эквивалентные классы и граничные значения для полей "возраст 18–99", "пароль 8–64 символа" и т.д.
Мини-разбор — поле "Скидка 0–100 %"
| Ввод | Ожидание (пример ТЗ) |
|---|---|
| 50 | Принято |
| 0, 100 | Границы — принято |
| −1, 101 | Ошибка валидации |
| пусто | Ошибка "обязательное поле" |
100.5, abc | Ошибка формата |
Чек-лист — навигация и UI
| # | Проверка | Типичный баг |
|---|---|---|
| 1 | Все ссылки в меню | 404, редирект не туда |
| 2 | Хлебные крошки | Неверный уровень, не кликаются |
| 3 | Кнопка "Назад" браузера | Потеря данных, повторная отправка формы |
| 4 | Модальные окна | Не закрываются по Esc / клику вне |
| 5 | Лоадеры | Бесконечный спиннер при медленном API |
| 6 | Пустые состояния | "Нет товаров", "Пустая корзина" — текст и CTA |
| 7 | Ошибки 404/500 | Своя страница, а белый экран |
| 8 | Favicon и title | "undefined", один title на всех страницах |
Повторная отправка формы: после "Назад" браузер может предложить "повторить отправку" — опасно для оплаты. Ожидание по ТЗ: предупреждение или POST-redirect-GET после успеха.
Чек-лист — сеть и API (без Postman)
Даже ручной QA должен заглядывать в Network:
| # | Действие | Ожидание |
|---|---|---|
| 1 | Выполнить действие (логин, добавить в корзину) | Запрос ушёл, статус 2xx |
| 2 | Ошибка на экране | В Network — 4xx/5xx, тело ответа с кодом ошибки |
| 3 | Повторить с отключённым Wi‑Fi | Понятное сообщение пользователю |
| 4 | Медленная сеть (DevTools → Throttling) | Нет двойных списаний, есть индикатор загрузки |
| 5 | Размер ответа | Огромный JSON на списке — риск по производительности |
Коды HTTP — шпаргалка для баг-репорта
| Код | Смысл | Что писать в баге |
|---|---|---|
| 200, 201 | Успех | "POST /orders → 201, тело: id=1001" |
| 400 | Неверный запрос (валидация) | Фрагмент JSON с полем ошибки |
| 401 | Не авторизован | После логина всё ещё 401 — баг сессии |
| 403 | Нет прав | Ожидали 403 для гостя на /admin |
| 404 | Не найдено | URL запроса |
| 500 | Ошибка сервера | Время, Request-Id если есть |
Если API проверяете системно — Postman и curl, утилита curl, curl / fetch — примеры.
Чек-лист — авторизация и сессии
Сессия — способ сервера узнать "это тот же пользователь". Обычно: cookie с идентификатором сессии или JWT в заголовке (токен с подписью и сроком жизни).
| # | Проверка | Зачем |
|---|---|---|
| 1 | Логин / логаут | Сессия реально завершается, защищённые страницы недоступны |
| 2 | "Запомнить меня" | Дольше живёт cookie — по ТЗ |
| 3 | Доступ к /admin без прав | 403 или редирект на логин |
| 4 | Истечение сессии | Редирект на логин, понятное сообщение |
| 5 | Два аккаунта в двух браузерах | Корзины и профили не смешиваются |
| 6 | Смена пароля | Старые сессии инвалидируются (если в требованиях) |
Кроссбраузерность и адаптив
Минимальный набор для большинства проектов:
- Chrome (основной)
- Firefox или Safari (второй движок — другой рендер и движок JS)
- Мобильная эмуляция в DevTools или реальное устройство
| Зона | Что проверить |
|---|---|
| ≤ 768px | Меню-бургер, таблицы не вылезают за экран |
| Клавиатура на телефоне | Поля не перекрываются, кнопка "Далее" видна |
| Zoom 125–150% | Текст читаем, кнопки кликабельны (доступность) |
Полный E2E через браузер — End-to-End и системное; автоматизация — Playwright или Selenium.
Пример одной тест-сессии (15–20 минут)
Фича: добавление товара в корзину на test.shop.example.
- Записать браузер, URL, пользователя
qa_buyer. - Smoke: главная открылась, каталог без ошибок в Console.
- Добавить товар A — счётчик "1", Network:
POST /cart→ 200. - Обновить страницу (F5) — корзина всё ещё "1" (данные с сервера).
- Два быстрых клика "+" — количество 2, один товар в Network (нет дубля).
- Выйти —
/cartредирект на логин. - Firefox: повторить шаги 3–4.
Нашли расхождение счётчика и Network → баг с шагами, скрином, HAR при необходимости.
Типичные баги в отчётах новичков
| Плохо | Лучше |
|---|---|
| "Не работает корзина" | "После добавления товара X счётчик остаётся 0, Network: POST /cart → 500" |
| Без скрина | Скрин + HAR при сетевой ошибке |
| "У всех ломается" | "Chrome 120 Win11, test, пользователь без админ-прав" |
| Один браузер | Указать, проверяли ли Firefox/Safari |
Куда дальше
| Тема | Статья |
|---|---|
| Полный маршрут тем веб-QA | Основы веб-тестирования — маршрут |
| Оформление кейсов и багов | Документация тестировщика |
| Сквозной сценарий + Selenium | Проверка пользовательского сценария |
| Проверка данных в БД | SQL для тестировщика |
| Современная UI-автоматизация | Playwright |
Дополнительный чек-лист для ручного QA
К базовому функциональному прогону полезно добавлять короткий accessibility-smoke:
- форма полностью проходится с клавиатуры;
- виден фокус активного элемента;
- ошибки формы понятны текстом, а не только цветом;
- подписи полей читаемы на мобильном экране.
Эти проверки быстро находят баги, которые не ловятся обычным кликом мышью.
Кейс "по мыши все работает, с клавиатуры нет"
Ситуация: smoke пройден, но пользователь с клавиатурной навигацией не может завершить форму.
Что обычно ломается:
- фокус уходит в невидимый элемент;
- модальное окно не закрывается по
Esc; - сообщение об ошибке видно цветом, но не читается текстом.
Мини-порядок проверки перед релизом:
- пройти критичную форму только клавиатурой (
Tab,Shift+Tab,Enter); - проверить видимость фокуса на всех действиях;
- убедиться, что ошибки понятны без цветовых подсказок.
Навигация по разделу "Тестирование"
- Маршрут: О разделе · Резюме раздела · Карта уровней и практик (Unit / Integration / UI / E2E, TDD, BDD)
- Теория и процесс: Основы · Классификация · Жизненный цикл · Порядок этапов · Артефакты качества
- Уровни проверок: Unit · Integration · E2E, системное и UI · API · Тестовые дублёры · Покрытие кода · White-box · Мутационное тестирование
- Практика QA: Документация · Тест-дизайн · Ручное веб · SQL
- Автоматизация: Стратегия и пирамида · Каталог инструментов · Selenium · Playwright
- Практикум и углубление: Подготовка среды и создание первого теста · Проверка взаимодействия компонентов · Проверка пользовательского сценария · Проверка надежности под нагрузкой · Мобильное · Нагрузка · Безопасность · Самопроверка · Доп. материалы курса · Инструменты с низким кодом для тестирования · Тестирование нейроморфных систем