План тестирования сайта: что проверяет подрядчик, а что — команда заказчика

Почему просмотра страниц недостаточно

«Мы открыли сайт, всё выглядит нормально» — слабое основание для запуска. Страница способна выглядеть готовой, хотя заявка не доходит до отдела продаж, выбранный вид услуги пропадает из отправленных данных или редактор не может исправить описание услуги без разработчика.

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

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

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

Состав плана: адреса, действия, результат

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

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

Исходное состояние тоже важно. Форма пустая или уже заполнена? Выбрана ли услуга? Сохранились ли данные после ошибки? Разные ответы меняют ход сценария и объясняют, почему одна и та же проблема воспроизводится только у части участников.

Ниже — образец состава плана для объявленной конфигурации сайта. Перед работой команда дополняет его адресами своего сайта и условиями конкретной услуги.

Кому поручить каждую группу испытаний

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

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

Один сценарий может проходить несколько участников, но итоговую строку отчёта лучше закрепить за одним человеком, который соберёт подтверждение со стороны посетителя, менеджера и технического исполнителя, а затем укажет оставшуюся проблему или готовность к приёмке. Так исчезает разрыв между командами. Разработчик не считает задачу завершённой по одной отправке. Менеджер понимает, какую запись искать, а координатор видит статус цепочки целиком. Я выбираю такой порядок вместо отдельных таблиц отделов, потому что их потом приходится вручную сводить в картину запуска.

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

На каких экранах и способах управления смотреть сайт

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

В критерии WCAG 2.2 № 1.4.10 о перекомпоновке содержания указан ориентир 320 CSS-пикселей для вертикально прокручиваемой страницы; существуют исключения для содержания, которому требуется двумерное расположение. Это ширина области в CSS, а не физическое число точек дисплея. Сам по себе удачный просмотр на такой ширине не означает полного соответствия всем требованиям доступности.

Клавиатура показывает другие проблемы. Можно ли перейти к полям и кнопке без мыши? Видна ли рамка или другая подсветка элемента, с которым сейчас работает клавиатура? Можно ли выйти из меню? В первичной оценке W3C отдельно рассматриваются клавиатурный доступ, видимость фокуса и подписи полей. В инструкции используются Tab для движения вперёд и Shift+Tab для возврата; конкретное поведение зависит также от настройки клавиатурной навигации браузера.

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

Что показывает автоматический отчёт

Lighthouse выполняет автоматические аудиты страницы, включая производительность, доступность и SEO. Инструмент можно запускать из Chrome DevTools; состав возможностей описан в документации Chrome. Такой отчёт полезен, когда требуется находить повторяемые технические замечания и сравнивать состояние страницы после изменений.

Однако высокий балл не подтверждает всю работу сайта. В методике оценки доступности Lighthouse прямо указано, что ручные аудиты не входят в итоговый балл. Тем более число не отвечает, понял ли клиент коммерческое предложение и попала ли его заявка нужному менеджеру.

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

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

Какие неудачные действия включить в план

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

Это разные вопросы к сайту. Поймёт ли человек ошибку? Сохранится ли уже введённый текст? Появится ли лишняя заявка? Можно ли продолжить действие после восстановления связи? Для каждого результата исполнитель выбирает безопасный способ испытания на подготовленной среде или специально выделенных тестовых данных.

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

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

Как описать найденную ошибку

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

Причину угадывать не требуется.

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

Приоритет ошибки я определяю по влиянию на действие клиента и работу компании. Недоступная отправка заявки, потерянный вид услуги и небольшое смещение декоративного элемента требуют разного решения. Категории приоритета и ответственного за выпуск полезно назвать до начала приёмки: тогда обсуждение начинается с ошибок, которые мешают клиенту обратиться.

На основании чего разрешать выпуск

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

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

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

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

Что можно выяснить за первые пятнадцать минут

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

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

1. Назвать услугу и сведения, которые нужны для обращения.
2. Заполнить форму подготовленными тестовыми данными и увидеть подтверждение.
3. Открыть запись в CRM под правами ответственного сотрудника.
4. Сопоставить услугу и контакт с отправленными значениями.
5. Записать расхождения и назначить человека, который примет исправление.

Подробные испытания после этого можно поручить подрядчику, сохранив у своей команды оценку содержания и работу с обращениями. В ШТАБ ИТ план приёмки можно подготовить вместе с разработкой или сопровождением сайта: по конкретным функциям, людям и результатам, которые необходимы вашему бизнесу.