Как принять сайт у разработчика: сценарии проверки и список замечаний
Чтобы принять сайт у разработчика, сопоставьте готовую версию с согласованными задачами, выполните ключевые действия посетителя и сотрудника, а замечания запишите так, чтобы их можно было повторить. Результатом станет список проверенных сценариев, оставшихся работ и переданных доступов. Ниже — процедура для владельца бизнеса с таблицей и заполненным примером.
Сначала определите, какую работу вы принимаете
Откройте согласованное предложение, структуру страниц и последнюю утверждённую версию макетов. Выпишите результат первого этапа: какие страницы, языки, формы и действия должны быть готовы. Формулировку «корпоративный сайт» нужно превратить в наблюдаемые результаты.
Например: посетитель находит нужную услугу, проверяет территорию работы, отправляет запрос; сотрудник получает его на рабочую почту, а редактор может обновить описание услуги. Если предусмотрены каталог, оплата или личный кабинет, для них нужны дополнительные сценарии. Приведённая ниже таблица рассчитана прежде всего на сайт услуг и не покрывает всю проверку интернет-магазина.
Согласованный макет помогает проверять оформление, но сам по себе не описывает обработку ошибок формы, доставку уведомлений или права редактора. Найдите, где зафиксированы эти условия. Если требования не обсуждались, сначала уточните ожидаемое поведение с исполнителем и запишите решение.
Разделите несоответствие и новую просьбу. Обещанная форма отправки не работает — это замечание к результату. Подключить CRM, которой не было в составе работ, — отдельное изменение объёма. Такое разделение позволяет обсуждать каждую задачу по существу.
Эта процедура описывает проверку результата и передачу управления. Формальный порядок приёмки и расчётов берите из условий вашего проекта. Если вы пока выбираете исполнителя, начните с сопоставления предложений: критерии гораздо легче согласовать до разработки.
Подготовьте одну версию сайта и понятные условия проверки
Попросите разработчика прислать точный адрес проверяемой версии, дату её обновления и список известных незавершённых работ. В один документ внесите сценарии, результаты и замечания. Не смешивайте наблюдения о старой демонстрационной версии и уже исправленном сайте.
Для проверки пользовательской части выйдите из панели управления или используйте отдельное окно браузера. Согласуйте тестовое имя и контакт, на который действительно можете получить ответ. Предупредите сотрудника, принимающего обращения, как отличить проверку от настоящего клиента. Например, добавляйте в сообщение пометку TEST и номер попытки.
Выберите устройства по аудитории и условиям проекта. MDN рекомендует ориентироваться на важные для пользователей сочетания браузеров и устройств: проверить все комбинации невозможно. Если у прежнего сайта есть надёжные данные о посетителях, используйте их. Для нового проекта запишите выбранный набор как рабочее допущение.
Практическая отправная точка для сайта услуг — ваш компьютер и настоящий телефон, а затем другие согласованные устройства. Указывайте модель, систему, браузер и их версии рядом с результатом. Изменение ширины окна на компьютере удобно для первого осмотра, но отдельную запись о проверке на телефоне делайте после реального прохождения сценария на нём.
Для каждой строки используйте один из четырёх статусов: «пройдено», «есть замечание», «не проверено», «не входит в объём». У статуса «не проверено» должна быть причина и ответственный за следующий шаг. Пустая ячейка не подтверждает готовность.
Пройдите сайт как посетитель и как сотрудник
Скопируйте таблицу в рабочий документ. Замените общие названия страниц своими URL и заполните последнюю колонку. Каждый обязательный сценарий проходите целиком: от исходной страницы до результата. Если обнаружили ошибку, дайте ей номер и свяжите с отдельным описанием.
| Сценарий | Что сделать | Ожидаемый результат | Статус / замечание |
|---|---|---|---|
| Найти нужную услугу | С главной открыть меню, выбрать услугу и вернуться в раздел. | Открывается нужная страница; название и содержание соответствуют ссылке. | — |
| Понять условия | Прочитать описание, географию, ограничения и следующий шаг. | Условия совпадают с утверждёнными материалами; нет противоречащих обещаний. | — |
| Отправить запрос | На телефоне заполнить форму контролируемыми тестовыми данными. | Понятно подтверждение; нужный сотрудник получает все согласованные поля. | — |
| Исправить ошибку ввода | Оставить обязательное поле пустым, отправить, затем исправить. | Понятно, какое поле требует действия; после исправления форму можно отправить. | — |
| Связаться альтернативно | Нажать телефон, email и другие предусмотренные контакты. | Открывается ожидаемый способ связи с правильным адресатом. | — |
| Открыть страницу напрямую | Скопировать адрес вложенной страницы, открыть заново и обновить. | Доступна та же страница, её содержание и навигация. | — |
| Использовать другую языковую версию | Перейти на предусмотренный язык и пройти путь к обращению. | Доступны согласованные страницы; язык формы и сообщения понятны читателю. | — |
| Обновить материал | Под учётной записью редактора изменить согласованный тестовый текст. | Изменение сохраняется и публикуется; другие блоки не повреждены. | — |
Не ограничивайтесь одинаковым просмотром всех страниц. Повторяющиеся услуги можно проверять по общему шаблону, но уникальные формы, таблицы, файлы и встроенные сервисы требуют собственных сценариев. При ошибке общего меню проверку расширяют на страницы, где оно используется.
Проверяйте текст как владелец бизнеса: правильны ли контакты, территории, названия услуг, условия и состав результата. Исполнитель способен точно перенести предоставленный материал, но только ваша команда может подтвердить, что бизнес действительно работает по указанным условиям.
Если есть файлы для скачивания, откройте их после загрузки: одного работающего адреса недостаточно, когда по нему выдают старую презентацию. Для кнопки звонка сверьте фактический номер, а не только подпись на странице.
Проверяйте заявку до получения ответственным сотрудником
Для формы заранее определите конечную точку проверки. Это может быть рабочий почтовый ящик, запись в CRM или иной согласованный канал. Сообщение «Спасибо» на сайте и получение запроса сотрудником — два отдельных наблюдения.
В первой попытке отправьте корректные данные с уникальной пометкой, например TEST-01. Запишите время и страницу. Попросите получателя найти именно это обращение и сверить имя, контакт, выбранную услугу и сообщение. Если письмо не обнаружено, зафиксируйте момент проверки и попросите исполнителя проследить отправку. Не делайте вывод о причине только по отсутствию письма во входящих.
Во второй попытке оставьте пустым обязательное поле. Проверьте, понимает ли посетитель, что исправить. Затем введите корректные данные и закончите отправку. В рекомендациях W3C по формам ошибка связана с конкретным полем, понятным объяснением и подсказкой об исправлении. Сообщение общего вида «Ошибка» такой информации не даёт.
Сценарий сбоя внешнего сервиса согласуйте с разработчиком для тестовой среды. Попросите показать поведение при неуспешном ответе: посетитель не должен получить ложное подтверждение, а способ повторной попытки должен быть понятен. Отключать рабочую почту или сервис заявок ради проверки на действующем сайте не требуется.
Отдельно согласуйте ожидание для повторного нажатия кнопки во время отправки. Проверьте именно этот случай, а не отправку двух разных сообщений с большим интервалом. В журнале должны быть номер попытки, наблюдаемое поведение кнопки и число реально полученных обращений.
Если в проект входит аналитика, её проверка идёт отдельной строкой и учитывает выбранные условия согласия. Событие в отчёте не заменяет проверку доставки заявки. Технические сценарии согласия и событий разобраны в отдельном материале.
Посмотрите, что происходит при обычных затруднениях
После основного прохода проверьте моменты, которые легко пропустить на презентации: открытое мобильное меню, длинный текст, увеличение масштаба, ошибка ввода и управление без мыши. Проверяется возможность закончить действие, а не только вид первого экрана.
На компьютере пройдите ссылки и элементы формы клавишей Tab, вернитесь Shift+Tab. Должно быть видно, где находится фокус, и оставаться возможным переход к следующему элементу. Затем увеличьте текст или масштаб до 200% и проверьте, не исчезают ли подписи, кнопки и содержание. W3C включает подобные действия в первичную проверку доступности; они не заменяют её полной оценки.
На телефоне откройте меню, выберите внутренний пункт и попробуйте заполнить форму с экранной клавиатурой. Посмотрите, не закрывает ли её меню или закреплённая панель, можно ли добраться до ошибок и кнопки. Поверните экран, если такая ориентация входит в согласованный набор проверок.
Вместо «на мобильном неудобно» запишите конкретное наблюдение: «после выбора контактов меню остаётся поверх формы, кнопка отправки недоступна». Разработчик получит действие, которое можно повторить, и понятный результат исправления.
Если согласована проверка скорости, сохраняйте адрес, дату и условия измерения. Лабораторные замеры полезны до запуска, но не заменяют данные реальных посетителей: на результат влияют устройство, сеть и взаимодействия. Общий балл инструмента сам по себе не подтверждает работоспособность меню, формы или передачи запроса.
Оформите замечание так, чтобы его можно было воспроизвести
Одна запись должна описывать одну проблему. В ней нужны адрес и версия сайта, условия, точные шаги, ожидаемый и фактический результат. Скриншот или короткое видео дополняют описание. Ниже — условный пример; устройство, версия проекта и результат придуманы для демонстрации метода.
| Поле | Пример записи |
|---|---|
| Краткое название | Мобильное меню остаётся поверх формы после перехода к контактам. |
| Где и в какой версии | https://example.com/uslugi/; проверяемая сборка «Приёмка 2» от 14.09.2026. |
| Условия | iPhone 13, iOS 18, Safari 18; вертикальная ориентация; посетитель не авторизован. |
| Шаги | 1. Открыть страницу. 2. Раскрыть меню. 3. Нажать «Контакты». 4. Попытаться заполнить форму. |
| Ожидание | Переход к форме; меню закрывается, поля и кнопка доступны. |
| Факт | Страница прокручивается к форме, но меню остаётся сверху и мешает заполнению. |
| Влияние и доказательство | Основной путь к обращению затруднён; приложено видео, ссылка на строку теста. |
| Исполнитель и повторная проверка | Разработчик проверяет обработку перехода. Владелец повторяет те же шаги после исправления; до этого запись открыта. |
В вашем журнале замените демонстрационный домен, устройство и версии фактическими. Не называйте предполагаемую причину установленной: «сломался JavaScript» не следует из одного перекрытого экрана. Опишите симптом, а техническую причину попросите подтвердить исполнителя.
Сохраняйте первоначальное наблюдение после исправления. Добавьте отдельную запись: какая версия проверена повторно, кем и с каким результатом. Ответ «готово» от разработчика меняет статус на «ожидает проверки», пока сценарий не пройден заново.
Если проблема не повторилась, укажите условия и число попыток. Фраза «не воспроизвелось в двух повторениях на указанном телефоне» полезнее безусловного вывода «ошибки нет». Для редкого сбоя договоритесь, какие данные сохранять при следующем появлении.
Отделите препятствия от доработок и новых пожеланий
Расставляйте приоритет по влиянию на согласованный сценарий. Название категории само по себе ничего не решает: рядом с замечанием запишите, какое действие невозможно или чем результат отличается от требования.
До использования затронутой функции исправляют проблемы, из-за которых основной сценарий не выполняется или посетитель получает неверный результат. Например, запрос не приходит ответственному, кнопка ведёт на чужой номер, меню не даёт добраться до формы. Для непроверенного обязательного сценария сначала организуют проверку.
Замечание, при котором действие доступно, можно вынести в отдельный согласованный список с исполнителем и сроком. Но различие в оформлении не всегда мелкое: нечитаемый текст или скрытая кнопка мешают пользователю. Приоритет определяется последствием.
Новые пожелания записывайте отдельно: например, добавить бронирование времени к уже согласованной форме запроса. Так они не исчезнут, но и не будут смешаны с исправлением существующей функции.
Продолжим условный пример. Команда нашла два препятствия: меню перекрывает форму, а ссылка телефона содержит неверный номер. Ещё одно замечание касается расстояния между карточками; после проверки чтения и переходов его согласовали на следующую правку. Пожелание добавить календарь вынесли в отдельную оценку.
После исправлений владелец повторяет переход через меню, отправку формы и нажатие номера на той же версии. Только получив ожидаемые результаты, он закрывает два препятствия. Остальные записи сохраняются со своими решениями. Процент выполненных пунктов здесь менее полезен, чем ответ на вопрос, работают ли обязательные действия.
Проверьте передачу управления своими действиями
Сайт передан в работу, когда ответственные сотрудники могут выполнять согласованные операции и знают, к кому обращаться при сбое. Попросите короткую совместную сессию, в которой действия выполняете вы под своей учётной записью.
Зайдите в систему управления, измените тестовый материал, проверьте предварительный просмотр и публикацию, затем верните исходный текст. Если у редактора нет нужной функции, уточните, соответствует ли это согласованной роли. Вход в панель и возможность поддерживать содержание — разные результаты.
Составьте перечень сервисов с владельцем аккаунта, ответственным за оплату и способом предоставления доступа. Сам перечень не должен содержать пароли и коды восстановления. Он нужен, чтобы понять зависимости проекта: кто продлевает домен, где размещён сайт и кто получает сообщения об оплате.
Если платформа ограничивает перенос или выгрузку, попросите объяснить доступный вариант передачи. Не предполагайте, что любой сайт можно передать одним архивом или что права редактора равны правам владельца. Для темы, изображений, шрифтов и приложений уточните согласованные условия использования.
По восстановлению попросите показать, что именно сохраняется, кто отвечает за резервные копии и как запрашивается возврат рабочей версии. Демонстрация в отдельной среде и понятная инструкция дают больше информации, чем фраза «бэкапы есть». Объём такой проверки согласуйте с исполнителем.
- Домен и размещение: аккаунт, ответственный, продление и контакт поддержки.
- Управление содержимым: роли сотрудников, инструкция по типовым изменениям.
- Форма и уведомления: получатель, резервный ответственный, порядок проверки после изменений.
- Подключённые сервисы: доступы, подписки и ответственные в пределах проекта.
- Восстановление и поддержка: процедура обращения, передаваемые материалы и перечень незакрытых задач.
После публикации повторите короткий обязательный проход
Проверка демонстрационной версии не заканчивает проверку публичного сайта. Согласуйте с разработчиком, какие сценарии повторяются после размещения на основном адресе, и сохраните их результаты отдельно.
Откройте напрямую главную и ключевую услугу, пройдите мобильное меню, отправьте согласованную тестовую заявку и подтвердите её получение. Проверьте контактные ссылки и вход редактора. Если в основной среде используются другие получатели или сервисы, именно их работа должна попасть в результат.
Если в объём входит поисковая подготовка, попросите отдельное подтверждение доступности важных страниц для индексации. Отсутствие сайта в поиске сразу после публикации не устанавливает техническую неисправность. Для разбора статусов и дат используйте специальную процедуру проверки индексации.
При замене действующего сайта дополнительно нужен план переноса старых URL, аналитики и возврата прежней версии при проблеме. Это самостоятельная задача миграции: её нельзя закрыть только таблицей проверки нового интерфейса. На Salestudia.de есть отдельный русскоязычный материал об этом процессе.
Зафиксируйте итог одной понятной записью
Итог должен связывать версию сайта, выполненные проверки и оставшиеся работы. Сообщение можно составить по этой заготовке, заменив поля фактическими сведениями:
«Проверена версия [адрес и дата]. Сценарии [номера или названия] пройдены на [устройства и браузеры]. Замечания [номера] исправлены и повторно проверены. Остаются задачи [список] с ответственными и согласованными сроками. Не проверены [сценарии и причины].
Переданы и проверены [аккаунты, роли, материалы]. После публикации на основном адресе повторены [сценарии и результат]. Следующее действие: [что делает каждая сторона]».
Если обязательный сценарий остаётся непроверенным или не работает, укажите это прямо. Если всё необходимое выполнено, не продолжайте бесконечно расширять приёмку новыми идеями: сохраните их для следующего этапа развития.
Для обсуждения разработки или доработки сайта подготовьте список страниц, обязательные действия посетителя и сотрудника, а также известные ограничения. По этим вводным можно согласовать состав работ и проверяемый результат.
Официальные и профильные ссылки
Эти материалы дают контекст для данных, правил и рекомендаций на странице.
- MDN — выбор браузеров и устройств для тестирования Источник проверен: 14.09.2026
- W3C — уведомления в формах Источник проверен: 14.09.2026
- W3C — первичная проверка доступности Источник проверен: 14.09.2026
- web.dev — Web Vitals и условия измерений Источник проверен: 14.09.2026
Удобнее написать напрямую?
Коротко укажите компанию, рынок и задачу — так разговор будет предметнее.