Как принять сайт по сценариям, а не по красивому скриншоту

Согласуйте критерии до демонстрации

Условная школа проводит офлайн-мастерские. Новый сайт должен помогать выбрать занятие и записаться. Если в задании написано только «форма записи», при приёмке трудно решить, считается ли работа готовой. Лучше заранее указать: посетитель выбирает занятие, оставляет контакт, получает подтверждение, а администратор видит запись с правильной датой и свободным местом.

Критерий должен быть понятен владельцу без чтения кода. Формулировка «реализован API» описывает техническую часть, но не результат. Попросите подрядчика связать каждую важную функцию с наблюдаемым действием. Это не означает составление сотен проверок для простого сайта. Достаточно покрыть основные пути, существенные ошибки и границы доступа, которые влияют на клиента или работу команды.

Сделайте карточку одного сценария

Укажите роль, начальные условия, последовательность и ожидаемый результат. Например: новый посетитель, свободное занятие, корректный контакт, отправка формы. Затем запишите, где смотреть итог: карточка записи, список участников и сообщение клиенту. Такая карточка позволяет повторить проверку после исправления и не спорить о том, что именно делали на прошлой встрече.

Отделите шаг пользователя от автоматического действия. Если после отправки должен появиться номер записи, это один результат. Если администратор должен получить уведомление, это другой. При временном сбое уведомления запись может сохраниться, и это важно заметить. Приёмка становится полезнее, когда показывает конкретное место разрыва, а не ставит всему процессу одну неясную отметку «не работает».

Начните с обычного пути клиента

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

После отправки сверяйте данные с рабочей стороной. В школе это название занятия, дата, контакт и статус. Если есть CRM или платёжная система, смотрите соответствующую запись там. Скриншот «Спасибо» подтверждает только состояние интерфейса. Он не показывает, что данные дошли до администратора, не потеряли важное поле и не попали в неправильную группу.

Добавьте неудобные действия

Проверьте пустое поле, неправильный формат, двойное нажатие, возврат назад и обновление страницы. Затем попробуйте старую ссылку или уже недоступный вариант. Пользователь должен получить понятное объяснение и возможность продолжить без лишней потери введённых сведений. У ошибки нужен выход: исправить поле, выбрать другое время или связаться с сотрудником.

OWASP отдельно рассматривает повторы, пропуск и изменение порядка шагов как важные проверки бизнес-логики. Для владельца это повод попросить показать, что нельзя получить результат в обход обязательного условия. Например, подтвердить занятое место или открыть чужой документ. Такие сценарии не заменяют полноценный аудит безопасности, но помогают выявить очевидные нарушения согласованного процесса.

Проверьте роли и устройства

Если есть кабинет, демонстрация под администратором не покрывает обычного клиента. Создайте тестовые учётные записи разных ролей и проверьте доступ к своим и чужим объектам. Ограничения должны действовать на сервере, а не только скрывать кнопку. При выходе из аккаунта защищённая информация не должна оставаться доступной через сохранённую прямую ссылку вопреки правилам проекта.

На телефоне проверьте меню, поля с экранной клавиатурой, длинные тексты и файлы. Попробуйте пройти основной путь с клавиатуры на компьютере, увеличить текст и увидеть фокус управления. W3C WAI предлагает первичные проверки доступности; они помогают заметить препятствия, но не являются полной сертификацией. Для приёмки важнее реальные действия на согласованных устройствах, чем набор уменьшенных скриншотов.

Фиксируйте ошибки так, чтобы их повторили

В сообщении об ошибке укажите адрес, роль, устройство, исходные данные, шаги, ожидание и наблюдаемый результат. Добавьте снимок или короткое видео без секретов и личной информации. Формулировка «иногда всё зависает» оставляет подрядчику много догадок. «После повторного нажатия создана вторая запись» уже указывает на конкретный сценарий и последствие.

Разделите блокирующие ошибки, существенные неудобства и пожелания. Новая идея не обязательно означает, что прежняя работа выполнена плохо. Но и важную потерю заявки нельзя прятать среди косметических замечаний. Для каждого исправления повторите исходный сценарий и ближайший связанный путь. Отметка «исправлено» от разработчика — повод проверить, а не автоматическое подтверждение со стороны заказчика.

Завершите приёмку передачей проекта

Получите исходники, доступы, инструкции и сведения о резервных копиях. Проверьте, что домен и рабочие аккаунты принадлежат согласованному владельцу, а не доступны только исполнителю. Назначьте ответственных за продление сервисов, контент и сообщения о сбоях. Если часть функций запускается позже, запишите их ограничения и точный следующий шаг.

В OBSION критерии удобно формировать вместе со сметой: что делаем, как покажем и где увидим результат. Это помогает вести проект по этапам и уменьшает спор о субъективном впечатлении в конце. Внешний вид остаётся важной частью приёмки, но бизнес получает больше уверенности, когда вместе с дизайном проверены заявки, доступы и ежедневная работа сотрудников.

Что проверить в своей задаче

1. Критерии связаны с результатом пользователя и бизнеса.
2. Каждый сценарий имеет условия, шаги и место проверки.
3. Проверены успешный путь, повтор, ошибка и возврат.
4. Роли, устройства и базовая доступность проверены отдельно.
5. Исправления перепроверены, доступы и ограничения переданы.