Чек-лист тестирования сайта — опора для последовательной проверки, а не обещание найти все дефекты. Его ценность в том, что команда понимает область, ожидаемые результаты и оставшийся риск. Один список не подходит одинаково новостному сайту, банковскому кабинету и внутренней панели администратора.
Перед прогоном адаптируйте пункты под продукт и релиз. Изменение формы заказа требует другой глубины, чем исправление текста в подвале. Проверки ниже дают основу: из неё выбирают применимое и добавляют риски конкретной задачи.
Подготовить контекст проверки
Зафиксируйте сборку, окружение, изменённые области, роли, тестовые данные и поддерживаемые браузеры. Уточните критическую цепочку: ради какого результата пользователь приходит на сайт и какой отказ особенно дорог.
У каждого пункта должны быть результат и свидетельство. Используйте статусы «пройдено», «дефект», «заблокировано», «не проверено» и «не применимо» с объяснением. Пропущенный тест нельзя считать успешным. Для тестовых оплат, писем и удаления подготовьте безопасное окружение и данные.
Проверить загрузку и навигацию
- →Открыть главную и ключевые страницы по прямому URL: загружается правильный материал, работают необходимые ресурсы.
- →Обновить вложенную страницу: сервер и клиент сохраняют правильный маршрут без неожиданной ошибки.
- →Пройти назад и вперёд: интерфейс восстанавливает согласованное состояние, действие не повторяется случайно.
- →Открыть несуществующий адрес: есть понятная страница ошибки и способ продолжить работу; HTTP-ответ соответствует назначению ресурса.
- →Проверить меню, внутренние ссылки и переходы во внешние сервисы: нет тупиков, неверных доменов и циклических перенаправлений.
Учитывайте чистую и существующую сессию. Только что открытый сайт и давно живущая вкладка могут получать разные версии ресурсов и состояния.
Проверить главный бизнес-сценарий
Пройдите цепочку целиком от входной точки до результата, а затем убедитесь, что результат действительно сохранён. Сообщение «успешно» само по себе не подтверждает изменение данных.
Для магазина это поиск товара, корзина, оформление и просмотр заказа. Для базы знаний — поиск статьи, чтение, переход к связанному материалу и корректный URL для передачи другому пользователю. Проверяйте реалистичные роли и данные: администратор может обходить ограничения, с которыми столкнётся обычный человек.
Проверить формы и данные
- →Пустые, обычные и граничные значения обрабатываются по контракту; ошибки помогают исправить ввод.
- →Кнопка и Enter приводят к согласованному submit, повторный клик не создаёт дубли операции.
- →После серверного отказа остаются допустимые значения и понятный способ повторить действие.
- →Длинный текст, кириллица, разные локали и формат даты не искажают данные.
- →Загрузка и скачивание файлов соответствуют требованиям к типу, размеру, имени и доступу.
Сравнивайте введённые данные, запрос, ответ и повторно прочитанное состояние. Эта цепочка помогает найти потерю точности или незаметную нормализацию.
Проверить вход, роли и сессию
Убедитесь, что вход, выход, истечение сессии и повторная аутентификация работают согласно политике продукта. Проверьте защищённый URL без входа и операцию под ролью без необходимого права.
На подготовленных аккаунтах проверьте доступ к чужому тестовому объекту через UI и API. Скрытая кнопка не заменяет серверную проверку доступа. После смены пользователя приложение не должно показывать данные предыдущего аккаунта из собственного состояния или неправильно используемого кэша.
Проверить ошибки, сеть и восстановление
Замедлите сеть, прервите запрос, воспроизведите предусмотренную серверную ошибку и пустой ответ. Ожидаются понятное состояние, завершение загрузки и определённый способ продолжить работу.
Особенно важен неопределённый исход: сервер мог сохранить заказ, а клиент не получить ответ. Повтор не должен молча создавать второй заказ. Проверяйте согласованность с сервером и предусмотренную защиту от дублей. Console и Network используйте для диагностики, но оценку результата делайте по поведению продукта и данным.
Проверить отображение и доступность
Выберите браузеры и размеры по матрице поддержки. Пройдите критическое действие в узком окне, с длинным контентом и при увеличении масштаба. Закреплённые панели и клавиатура не должны закрывать необходимые действия.
Пройдите цепочку клавиатурой, проверьте видимый фокус, подписи полей, понятность ошибок и доступные названия кнопок. При необходимости используйте screen reader. Автоматическая проверка полезна как дополнительный сигнал, но не подтверждает доступность всех процессов.
Проверить публичность и релизные настройки
Для публичного сайта проверьте title, description, canonical, robots-правила, sitemap и ожидаемые redirect. Для закрытого сервиса важнее корректные ограничения доступа. Не переносите требования поисковой индексации на личные кабинеты.
Проверьте production-конфигурацию: домены API, ссылки, ресурсы, отсутствие тестовых заглушек и диагностических секретов. После выкладки выполните короткий smoke на разрешённых данных. Нагрузочные и разрушительные проверки заранее ограничиваются предусмотренным окружением и согласованной областью.
Практический пример: релиз оформления заказа
Пусть изменили адресную форму и расчёт доставки. В приоритете — пройти оформление, проверить границы адреса, смену способа доставки и повтор после таймаута.
- 1.Создайте тестовый заказ с обычным адресом. Ожидается одна запись с правильными адресом, стоимостью и выбранной доставкой.
- 2.Введите длинный адрес на телефоне и исправьте ошибку. Ожидается доступность сообщений и кнопки при открытой клавиатуре.
- 3.Смените адрес до завершения расчёта. Ожидается применение последнего выбора, а не запоздавшего ответа.
- 4.Повторите подтверждение после имитированного сбоя ответа. Ожидается согласованный статус без дубликата.
- 5.Проверьте просмотр заказа другой тестовой ролью. Ожидается соблюдение правил доступа.
Остальные пункты выбирают по затронутым зависимостям и истории дефектов, а не по желанию формально заполнить весь список.
Как закончить прогон
В отчёте свяжите дефекты с пунктами, укажите покрытые окружения, блокировки и непроверенные области. Разделяйте «известных дефектов не обнаружено» и «риска нет»: второе тестирование не доказывает.
Типичные ошибки — одинаковая глубина для всех релизов, отсутствие ожидаемых результатов и зелёный статус у заблокированных проверок. Хороший чек-лист помогает принять решение о выпуске на основе фактов и обозначенных ограничений.
Что ещё почитать
- →MDN: Introduction to cross-browser testing
- →W3C WAI: Easy Checks
- →OWASP: Web Security Testing Guide
- →MDN: HTTP caching
Лист проверки web-релиза с доказательствами
Выберите конкретную задачу, например отправку вымышленной контактной формы. До проверки согласуйте правила полей, успешный результат и поддерживаемые браузеры. Строки ниже задают наблюдения: это компактный лист релиза, а не полный аудит безопасности или доступности. Фактические результаты храните отдельно от ожиданий.
Область Действие Наблюдаемое ожидание Что приложить
Функция Отправить одну валидную форму Одна принятая отправка и понятное подтверждение ID запроса + UI
Валидация Не заполнить обязательный email Конкретная ошибка; нет успеха; запрос обработан по контракту UI + лог запроса
Клавиатура Пройти задачу Tab/Shift+Tab/Enter Видимый фокус; доступные элементы; нет ловушки Видео
Подписи Проверить accessible names полей Имя передаёт назначение; ошибка связана с полем Дерево доступности
Адаптивность Проверить согласованные узкий/широкий viewport Элементы не обрезаны; контент доступен Размер + скриншот
SEO Получить HTML публичной страницы Правильные язык, title, canonical и индексация Заголовки + HTML
Сеть Прервать связь до/после отправки Нет ложного успеха; восстановление без дубля Сетевой лог
Данные Прочитать принятую запись Значения и права соответствуют ожиданию Обезличенные данныеВымышленный пример наблюдения: если кнопка показывает «Отправлено», а запрос вернул серверную ошибку, сохраните статус, время и состояние UI; не утверждайте, что сообщение записано. И наоборот: таймаут не доказывает, что сервер отклонил запись. До повтора выясните результат операции.
Инструменты QA Hub помогают с отдельными доказательствами: URL parser разбирает параметры, JSON formatter облегчает чтение ответа, JSON diff сравнивает ожидаемый и фактический payload, HTTP codes даёт справочник. Они не определяют соответствие требованиям продукта. Завершите проверку списком ошибок, непроверенного объёма, ответственных и решением по риску релиза.