1. Зафиксируйте, что проверяете
- Версия ТЗ и перечень согласованных изменений; номера проверяемых требований.
- Адрес среды, версия сборки, дата, браузер и устройство. Тестовый стенд и опубликованный сайт отмечайте отдельно.
- Учётные записи с разными ролями, подготовленный набор синтетических данных, разрешённые операции.
- Перечень ожидаемых файлов и инструкций, ответственные за проверку и исправление.
Не проверяйте оплату, рассылку, удаление данных или создание реальных обращений без согласованного тестового режима. Если такого режима нет, запишите ограничение и оставьте соответствующую проверку в статусе «не проверено».
2. Пройдите путь посетителя
- Найдите информацию. Откройте страницу через меню, поиск и прямую ссылку. Проверьте заголовок, актуальность содержания, ссылки и скачивание документов.
- Повторите на узком экране. Меню, текст и кнопки должны оставаться доступны. Проверьте увеличение текста, длинные названия и сообщения об ошибках.
- Используйте клавиатуру. Пройдите Tab и Shift+Tab, убедитесь, что фокус виден, меню открывается и закрывается, поле имеет понятную подпись.
- Проверьте форму. Пустые и неверные поля, отсутствие обязательного согласия, корректное заполнение. Сообщение об успехе должно соответствовать подтверждению сервера.
- Сымитируйте отказ. В согласованной тестовой среде отключите сеть или замокируйте ошибку API. Убедитесь, что нет ложного успеха, потери введённых данных или бесконтрольных повторов.
- Отключите JavaScript. Основной текст и контакты доступны; неподдерживаемая отправка формы не должна превращаться в переход с контактными данными в URL.
Что подтверждает форма
Надпись «Отправлено» сама по себе ничего не доказывает. Ответ API может подтвердить регистрацию запроса. Доставку во внешнюю систему и получение ответственным сотрудником проверяют отдельно, по согласованному тестовому обращению и записи на стороне получателя.
3. Проверьте редактора и публикацию
Попросите сотрудника, который будет вести сайт, выполнить задачу по переданной инструкции. Исполнитель может наблюдать, но не должен выполнять действия вместо редактора.
- Создать запись, добавить изображение с описанием, сохранить черновик и открыть предпросмотр.
- Опубликовать запись и проверить её как посетитель в отдельной сессии. Измерить задержку относительно согласованного условия.
- Исправить текст и снять запись с публикации; проверить связанные списки, поиск и кеш.
- Попытаться открыть административную функцию под ролью редактора. Ожидаемый отказ проверять на серверной стороне, а не только по скрытой кнопке.
- Если предусмотрена история — восстановить предыдущую версию на тестовой записи.
При раздельных публичном и административном контурах отдельно проверьте сбой синхронизации: старое опубликованное содержание остаётся доступным, а ответственный видит причину и состояние обновления, если это предусмотрено требованиями.
4. Проверьте интеграции и устойчивость
Для каждой интеграции выполните четыре согласованных сценария: успешный обмен, неверные данные, недоступность сервиса и повтор запроса. Сверьте результат на обеих сторонах. Скриншот сайта не подтверждает, что данные появились у получателя.
Скорость и нагрузка
Используйте оговорённые страницы, данные, профиль сети, нагрузку и метрики. Сохраните параметры испытания и исходный отчёт. Один замер на быстром компьютере не показывает работу под нагрузкой.
Резервная копия
Восстановите данные в отдельной разрешённой среде и повторите критичный сценарий. Наличие архива без восстановления подтверждает только создание файла.
Безопасность
Согласуйте объект, границы и исполнителя испытаний. Отчёт сканера не доказывает отсутствие всех уязвимостей; замечания и ограничения должны быть явно указаны.
Документы и доступность
Проверьте чтение текста документов, структуру и навигацию вспомогательными технологиями. Для полного заключения привлеките профильного специалиста.
При замене существующего сайта
По реестру переноса проверьте старый и новый адрес, содержание, документы, внутренние ссылки и метаданные. Перенаправление должно вести к соответствующему материалу, когда это предусмотрено картой URL. Общая переадресация на главную не подтверждает перенос страницы.
Повторите проверку после финального переноса изменений и запуска. Сверьте canonical, robots и sitemap с согласованной схемой публикации. Техническая корректность переноса не гарантирует прежних позиций в поиске.
5. Проверьте комплект передачи
- Исходники и версия, соответствующая проверенному результату; перечень сторонних компонентов и условий их использования.
- Инструкция сборки и развёртывания, параметры среды без секретных значений, порядок обновления и отката.
- Руководства редактора и администратора, перечень выполненных учебных задач.
- Реестр доменов, хостинга и внешних сервисов с владельцами и сроками действия. Доступы передаются через согласованный защищённый канал, а не в открытом протоколе.
- Резервирование, восстановление, журнал известных ограничений и отчёты испытаний.
- Разграничение исправления дефектов, эксплуатации и новых доработок; контакты ответственных и согласованные правила обращения.
Наличие архива исходников ещё не подтверждает возможность собрать сайт. Если воспроизводимая сборка входит в условия проекта, выполните её по инструкции на согласованной чистой среде.
6. Составьте воспроизводимый протокол
Одна строка — одна проверка. Запишите номер требования, среду, шаги, ожидаемый и фактический результат, доказательство и статус. Для дефекта назначьте ответственного, критичность по согласованным правилам и дату повторной проверки.
Учебный пример дефекта
Ф-01 / П-03. Среда: тестовая, сборка X. Роль: редактор. Шаги: создать запись → сохранить черновик → открыть адрес без авторизации. Ожидается: черновик недоступен посетителю. Фактически: текст виден. Доказательство: адрес тестовой записи, время и снимок экрана без секретных данных. Статус: не пройдено.
После исправления повторите тот же сценарий и проверьте, что обычная публикация продолжает работать. Старое доказательство не подтверждает новую сборку.
Когда результат готов к обсуждению приёмки
Все согласованные проверки имеют статус и доказательства; непроверенные пункты перечислены; дефекты обработаны по согласованным критериям; комплект передачи сверён. Это техническая основа решения, а не автоматическое разрешение подписывать акт.
Частые ошибки
Принимать демонстрацию вместо самостоятельного сценария; проверять только успешный путь; считать ответ API доказательством доставки письма; смешивать тестовую и публичную версии; закрывать непроверенное как успешное; передавать пароли в отчёте.