Чек-лист ручной проверки перед публикацией сайта помогает пройти ключевые пользовательские сценарии, найти блокирующие ошибки и принять обоснованное решение о выпуске. Сначала определите, что посетитель должен сделать на сайте, затем проверьте эти действия в безопасной тестовой среде, зафиксируйте дефекты и повторно проверьте исправления.
Контрольные точки перед открытием сайта для посетителей
- Составьте список важных действий посетителя: найти нужную страницу, отправить форму, оформить заказ или связаться с компанией.
- Проверяйте сайт на тестовой версии, используя отдельные учётные записи и тестовые данные.
- Считайте блокирующими ошибки, из-за которых нельзя выполнить ключевое действие, нарушается безопасность или теряются данные.
- Записывайте для каждого дефекта страницу, шаги воспроизведения, ожидаемый и фактический результат.
- После исправления повторите проверку затронутого сценария и связанных функций.
Как определить критичные сценарии для ручной проверки
Ручная проверка подходит владельцам сайта, редакторам и командам, которым нужно перед публикацией подтвердить работу основных пользовательских сценариев. Она особенно важна после изменений в навигации, формах, оплате или структуре страниц.
Не ограничивайтесь ручными тестами, если нужно подтвердить безопасность, нагрузочную устойчивость или соответствие сложным техническим требованиям. Такие задачи требуют профильной проверки и специализированных инструментов. Ручной осмотр не заменяет технический аудит сайта.
Начните с действий, от которых зависит цель сайта. Для корпоративного проекта это может быть отправка заявки; для интернет-магазина - поиск товара и прохождение оформления заказа. Не тестируйте реальные платежи и не отправляйте тестовые сообщения реальным клиентам.
Подготовка тестовой среды, браузеров и учетных записей
До проверки соберите необходимые доступы и материалы:
- адрес тестовой версии сайта и сведения о том, какая версия готовится к публикации;
- список ключевых страниц и пользовательских сценариев;
- тестовые учётные записи с нужными ролями, если на сайте есть личный кабинет или закрытые разделы;
- безопасные тестовые данные для форм, поиска и оформления заказа;
- доступ к почте или другому тестовому каналу, куда поступают уведомления;
- браузеры и устройства, которыми пользуется целевая аудитория;
- таблицу или систему для регистрации результатов и дефектов.
Сравните два удобных способа вести записи. Таблица подходит для небольшого объёма проверок; система учёта задач - если дефекты нужно назначать исполнителям и отслеживать их статус. Выбирайте подход по размеру команды и числу сценариев, а не по количеству функций инструмента.
| Подход | Когда подходит | Что фиксировать | Ограничение |
|---|---|---|---|
| Таблица | Небольшой сайт или разовая проверка | Сценарий, результат, риск, ответственного | Сложнее отслеживать обсуждение и историю исправлений |
| Система учёта задач | Командная работа и повторные циклы проверки | Шаги воспроизведения, вложения, статус, исполнитель | Требует настройки процесса и доступов |
Перед тестированием убедитесь, что стенд не отправляет реальные уведомления и не подключён к боевым операциям без необходимости. Если проверка затрагивает персональные данные или платежи, используйте только разрешённые тестовые средства и согласованный порядок действий.
Проверка навигации, форм и пользовательских действий
Перед пошаговой проверкой учтите основные риски и ограничения:
- Не вводите настоящие пароли, платёжные данные и сведения клиентов в тестовые формы.
- Не удаляйте записи и не меняйте настройки боевого сайта в ходе проверки.
- Не отправляйте тестовые заявки на адреса реальных клиентов и сотрудников без согласования.
- Проверяйте сценарии с учётными записями, которым разрешены только необходимые действия.
-
Откройте ключевые страницы.
Перейдите на главную, страницы услуг или товаров, контакты и другие разделы, важные для цели сайта. Убедитесь, что страницы загружаются, а адреса ведут на ожидаемый контент. -
Пройдите навигацию.
Проверьте главное меню, внутренние ссылки, кнопки перехода и возврат к предыдущему шагу. Отметьте ссылки, ведущие не туда, на недоступную страницу или в пустой раздел. -
Отправьте тестовые данные через формы.
Проверьте обязательные поля, сообщения об ошибках и подтверждение успешной отправки. Используйте тестовый адрес или согласованный канал, чтобы не создать реальные обращения. -
Выполните ключевое действие.
Пройдите сценарий целиком: например, найдите товар и дойдите до тестового этапа оформления. Не подтверждайте реальную оплату и не создавайте необратимые операции. -
Проверьте варианты ошибок и возврата.
Оставьте обязательное поле пустым, введите данные в неверном формате или вернитесь на предыдущий шаг. Убедитесь, что сайт понятно сообщает о проблеме и сохраняет введённые данные там, где это ожидается. -
Повторите сценарии в выбранных браузерах.
Проверьте основные действия в браузерах и на устройствах, значимых для аудитории. Фиксируйте отличия, которые мешают прочитать страницу или завершить действие.
Если нужно проверить сайт перед запуском в сжатые сроки, сначала пройдите сценарии, напрямую связанные с обращением, покупкой или получением нужной информации. Остальные проверки не отменяйте: зафиксируйте их отдельно и назначьте ответственного.
Контент, ссылки и отображение страниц: что сверить вручную
- Сверьте заголовки, цены, адреса, контакты и условия с утверждённой версией материалов.
- Проверьте, что на страницах нет черновых текстов, заглушек и случайных служебных пометок.
- Откройте внутренние и внешние ссылки, в том числе ссылки в подвале и контактных блоках.
- Убедитесь, что изображения и файлы загружаются, а значимые изображения отображаются корректно.
- Просмотрите страницы на широком и узком экране: текст не должен перекрываться, а кнопки и меню - выходить за границы экрана.
- Проверьте читаемость текста, заметность ошибок и подтверждений, а также доступность основных действий с клавиатуры.
- Убедитесь, что заголовки и подписи описывают содержимое, а ссылки понятно сообщают, куда ведут.
Чек-лист проверок с приоритетами риска и результатами
Используйте таблицу как основу для чек-листа проверки сайта перед публикацией. Риск оценивайте по последствиям для посетителя и работы сайта, а не только по внешнему виду дефекта.
| Проверка | Уровень риска | Ожидаемый результат | Решение при ошибке |
|---|---|---|---|
| Переход по ключевым страницам | Высокий | Посетитель открывает нужные разделы | Блокировать выпуск, если недоступна важная страница |
| Отправка основной формы | Высокий | Данные принимаются, посетитель видит подтверждение | Блокировать выпуск, если обращение не отправляется или теряется |
| Оформление ключевого действия | Высокий | Сценарий проходит без реальной необратимой операции | Блокировать выпуск при нарушении основного сценария |
| Отображение на мобильном экране | Средний или высокий | Контент читается, элементы управления доступны | Оценить влияние на аудиторию и возможность выполнить действие |
| Ссылки на второстепенные материалы | Средний | Ссылка ведёт на подходящую страницу | Исправить до выпуска, если ссылка нужна для важного сценария |
| Опечатки и незначительные визуальные отличия | Низкий, если смысл и действия не нарушены | Информация остаётся понятной и достоверной | Можно запланировать исправление после выпуска с ответственным и сроком |
Типичные ошибки проверки - оценивать только внешний вид главной страницы, пропускать подтверждение отправки формы, тестировать лишь один экран или не перепроверять исправленный дефект. Включите в чек-лист не только результат, но и условия теста: страницу, браузер, роль учётной записи и используемые данные.
Тестирование сайта перед запуском помогает найти ошибки в конкретных сценариях, но не заменяет проверку безопасности и производительности. Стоимость отдельного технического аудита зависит от его объёма и требований; формулировка "аудит сайта цена" не позволяет определить стоимость без описания работ и границ проверки.
Как фиксировать дефекты и принять решение о публикации
Для каждого дефекта укажите страницу, последовательность действий, условия проверки, ожидаемый и фактический результат, а также уровень риска. Добавляйте снимок экрана или запись, если они помогают воспроизвести проблему, но не сохраняйте в материалах проверки реальные персональные данные.
Затем выберите один из вариантов:
- Выпуск остановлен. Выберите этот вариант, если недоступен ключевой сценарий, нарушается целостность данных или есть риск раскрытия информации.
- Выпуск после исправлений и повторной проверки. Подходит, когда дефект устраним до публикации и затрагивает важные функции или страницы.
- Выпуск с отложенным исправлением. Допустим для некритичной проблемы, которая не мешает посетителю и не создаёт риска. Зафиксируйте ответственного и срок исправления.
Перед публикацией повторно пройдите сценарий, в котором обнаружили дефект, и связанные с ним действия. Сохраните итоговый список проверок, статус проблем и решение о выпуске, чтобы команда понимала, какие ограничения приняты.
Что уточнить перед финальным выпуском сайта
Какие дефекты блокируют публикацию?
Те, что мешают выполнить ключевое действие, приводят к потере данных или создают риск для безопасности и конфиденциальности. Их следует устранить и перепроверить до открытия сайта для посетителей.
Можно ли ограничиться проверкой главной страницы?
Нет, проверьте ключевые страницы и пользовательские сценарии, включая формы, навигацию и целевое действие. Ошибка часто проявляется только на конкретном шаге.
Нужно ли проверять сайт в нескольких браузерах?
Проверьте его в браузерах и на устройствах, значимых для аудитории. Минимальный набор определите с учётом того, как посетители обычно заходят на сайт.
Чем ручной чек-лист отличается от технического аудита?
Чек-лист помогает вручную пройти заданные сценарии и сверить результат. Технический аудит может охватывать дополнительные области, например безопасность или производительность, и требует отдельного определения объёма.
Можно ли публиковать сайт с мелкими ошибками?
Можно рассмотреть выпуск, если проблема не мешает важным действиям и не создаёт риска для посетителей. Запишите дефект, назначьте ответственного и установите срок исправления.
Как подтвердить, что исправление сработало?
Повторите шаги, которые приводили к дефекту, в тех же условиях. Если изменение затрагивает связанные функции, проверьте и их.
Автор: Виктор Егоров