Проведите приёмку сайта и оформите открытые дефекты

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

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

Шаг 1. Зафиксируйте условия

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

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

Шаг 2. Выберите пять сценариев

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

Для каждого сценария заполните карточку. Если ожидаемый результат нельзя проверить, вернитесь к формулировке критериев приёмки.

Шаг 3. Выполните и запишите наблюдения

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

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

Если результат отличается от согласованного требования, поставьте fail и создайте запись дефекта. Если проверить не удалось, запишите ограничение и владельца следующего действия. Для «Не применимо» объясните, почему требование не относится к выбранному объёму.

Шаг 4. Разберите учебный пример

Для отдельной проверки формы используйте практику доставки заявки. Её протокол добавляется к общей приёмке: он связывает отправку, обработку и доступ ответственного к полученному обращению.

Ниже вымышленная ситуация для тренировки, а не результаты CoreWeb или заказчика. В учебном ТЗ указано: при ошибке отправки форма объясняет проблему и сохраняет введённый текст. В разрешённом тестовом окружении ответ сервера подменён ошибкой; форма показывает сообщение, но очищает описание задачи.

Запись результата: «Fail. Сообщение показано, описание очищено; ожидалось сохранение. Повтор: открыть форму, заполнить описание, отправить при заданной ошибке. Доказательство: учебная запись экрана». Причину в коде заказчик не установил — её не нужно придумывать в протоколе.

Теперь оформите карточку дефекта:

• ID: учебный D-01; связан со сценарием формы и требованием о сохранении текста.
• Влияние: посетителю приходится вводить описание заново при повторе.
• Условия: конкретная учебная версия, браузер и способ воспроизведения ошибки.
• Решение: передать ответственному за исправление; дату повторной проверки согласовать после готовности версии.
• Условие закрытия: исходные шаги повторены, текст сохранён, штатная отправка также проверена в разрешённом окружении.

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

Шаг 5. Подготовьте решение

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

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

Локальная или тестовая проверка относится к конкретному окружению. Проверки после переключения домена перечислите отдельно; при редизайне включите в них проверку переноса страниц. Не меняйте production ради прохождения упражнения.

Проверьте результат урока

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

Попросите другого участника повторить одну карточку без устных подсказок. Если ему не хватает версии, исходных данных или ожидаемого результата, дополните протокол. Урок можно отметить выполненным после подготовки этого набора; отметка в академии не означает приёмку вашего сайта.

После оформления результатов подготовьте план запуска и отката: назначьте исполнителей, контрольные проверки и правила сохранения новых данных.

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

Перед заполнением карточек составьте паспорт staging: версия, тестовые данные, получатели заявок и отличия от production. Это поможет точно указать, в каких условиях получен результат.