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