Чек-лист тестирования сайта задаёт проверяемые действия посетителя и ожидаемые результаты. Для сайта услуг начните с переходов, формы заявки и мобильного экрана. Найденные ошибки оформляйте отдельно, а исправления передавайте исполнителям. Ниже приведён заполненный учебный прогон: проверки выполняет человек, Канбано служит доской исправлений. Один список не подтверждает отсутствие всех ошибок на сайте.
Как подготовить ручную проверку
Для ручной проверки заранее выберите границы, требования и тестовое окружение. В примере проверяется сайт услуг без корзины, регистрации и оплаты. Для магазина понадобятся дополнительные сценарии заказа и платежа. До запуска договоритесь, какое поведение считается правильным: открывшаяся страница или показанная надпись ещё не подтверждают выполнение всего пути посетителя.
Что такое чек-лист тестирования сайта
Чек-лист тестирования сайта — короткий список проверок выбранного поведения страниц. Пункт отвечает на вопрос, что проверить. Тест-кейс подробно раскрывает сложный сценарий: предусловия, данные и шаги. Баг-репорт описывает найденное расхождение, которое нужно исправить. Список и сообщение об ошибке выполняют разные задачи.
Короткая запись «проверить форму» допускает разные толкования. Запись «отправить форму с пустым телефоном и получить понятную ошибку у поля» задаёт наблюдаемый результат. Для общего способа полезно сформулировать проверочный пункт, а подробные действия вынести в тест-кейс, если одной строки недостаточно. В учебной таблице ожидаемые результаты добавлены к каждой проверке, чтобы другой человек мог повторить тот же прогон.
Какие действия посетителя взять для прогона
Для прогона возьмите путь посетителя от выбора услуги до получения заявки тестовым адресатом. Посетитель открывает услугу, видит согласованную цену, заполняет форму и отправляет данные. Проверяющий подтверждает, что заявка действительно поступила, а не только увидел сообщение на странице.
Двенадцать строк ниже — стартовый пример для выбранного сайта услуг. Удаляйте неприменимые пункты с причиной, добавляйте собственные критичные сценарии. Если есть личный кабинет или оплата, без их проверки нельзя переносить вывод примера на весь сайт. Ручной прогон также не заменяет нагрузочное испытание, проверку всех правовых требований или исследование защищённости. Для каждого из этих объёмов нужны отдельные условия и специалисты.
Как зафиксировать контекст проверки
Контекст проверки зафиксируйте в паспорте: стенд, сборка, дата и время с часовым поясом, проверяющий, точные версии ОС и браузера, размер видимой области, сеть и состояние кэша. Не пишите «последний браузер»: через месяц запись перестанет объяснять исходные условия.
Вымышленный пример использует сборки qa-17 и qa-18 учебного стенда мастерской. E1: Windows 11, Chrome 156.0.8078.80, 1440×900 CSS-пикселей, Wi-Fi. E2: iPhone 13, iOS 27.1, Safari 27.1 (20625.1.29), учебная видимая область 390×844 CSS-пикселя, портретная ориентация. Условный прогон E1 начинается 31.10.2026 в 14:10 UTC+5. При настоящей проверке записывайте фактические версии и область экрана с учётом панелей браузера.
Подготовьте синтетические данные: имя Тест, qa@example.test, телефон +70000000000 и тестовый ящик проекта. Недоступный ящик блокирует проверку доставки; успешным результатом его отсутствие не является. Для повторной попытки сохраняйте собственное время запуска и номер сборки рядом с доказательством, чтобы не принять старую запись за новый результат.
Какие действия выполнить на сайте
На сайте повторите выбранные действия и сравните наблюдаемый результат с согласованным требованием. Учебные пути /uslugi, /zayavka и /missing-qa ниже не ведут на чужой рабочий сайт. Действия выполняются на подготовленном стенде с синтетическими контактами. Рабочие заявки клиентов не нужны для проверки формы.
Как проверить переходы по страницам
Переходы по страницам проверьте через меню и ссылки: откройте ожидаемый адрес, сверяйте название услуги, цену и контакты с утверждённым содержимым. Заголовок вкладки должен соответствовать странице. Ссылка с правильным текстом может вести на другую услугу, поэтому оценивайте и её назначение.
Откройте телефон и email, затем заведомо отсутствующий путь. Ожидается ответ 404 с понятной возможностью вернуться, а не пустой экран. Если утверждённого адреса или цены нет, сначала уточните требование. Проверяющий не должен подменять решение владельца сайта собственной догадкой. Глубокий SEO-аудит к этому короткому маршруту не относится.
Что проверить в форме заявки
В форме заявки проверьте валидную отправку, пустое обязательное поле, неверный email и повторное нажатие кнопки. Для валидного ввода нужны одна заявка у адресата и ожидаемая реакция страницы. Надписи «отправлено» недостаточно, если письмо или запись не поступили в тестовый контур.
Для пустого телефона оставьте остальные поля корректными; ожидайте понятную ошибку и фокус на телефоне. Для email используйте user@, сохраняя валидность остальных полей. Уточнить границы проверки поможет источник MDN: разберите валидацию формы. Клиентская проверка ввода не заменяет серверную.
В qa-17 тестовый ящик недоступен, поэтому доставка и дубли заявок не проверены. Оба пункта заблокированы одной проблемой среды ENV-003. Отсутствие пояснения у пустого телефона — самостоятельный дефект WEB-021: его можно наблюдать без доступа к ящику. Блокировка среды не отменяет обнаруженную ошибку обратной связи.
Как проверить мобильный экран
Мобильный экран проверьте на доступность меню, чтение текста и возможность отправить форму без перекрытия кнопки. В E2 учебный баннер закрывает кнопку отправки. Пользователь с корректными данными не может завершить действие — найден дефект WEB-022.
Повторите критичный путь в E1 с Chrome и в E2 с Safari. Два размера окна одного Chrome не равны двум браузерным средам. Эмуляция телефона также не становится настоящим iPhone: в отчёте называйте фактический способ проверки. Запишите версию, область экрана, ориентацию и результат каждого запуска. Две среды выбраны для примера; собственный набор определяйте по аудитории сайта и условиям проекта, а не по числу строк в чужом списке.
Что проверить без мыши
Без мыши проверьте переходы клавишами Tab и Shift+Tab, активацию элементов и видимость фокуса. Посетитель должен выйти из поля и меню, а не попасть в клавиатурную ловушку. Подписи полей и сообщения об ошибке должны объяснять действие; одного красного цвета недостаточно.
По руководству W3C можно проверить доступность клавиатуры и заметить отдельные барьеры. Easy Checks — предварительная проверка, а не заключение о соответствии сайта WCAG. Успешный проход короткой формы не подтверждает доступность всех страниц и способов взаимодействия. Сохраните конкретный проблемный элемент и действие, которое посетитель не смог выполнить, вместо общей записи «неудобно».
Как ограничить техническую проверку
Техническую проверку ограничьте согласованным минимумом HTTPS и повторяемым измерением видимой загрузки. Посмотрите, нет ли предупреждения браузера и смешанного содержимого. Отсутствие предупреждения не подтверждает полную безопасность и не заменяет проверку специалистом.
LCP показывает момент появления крупнейшего видимого элемента страницы. Для W11 выполните три отдельных запуска Lighthouse в E1: Navigation, Desktop, Performance, одинаковый профиль замедления сети и процессора, очистка хранилища перед каждым запуском. Сохраните настройки, версию инструмента и отчёты. Руководство объясняет, как измерить видимую загрузку.
Учебное условие — не более 2,0 секунды в каждом запуске. Порог согласован для данного примера и не является универсальной нормой для всех посетителей. Вымышленные результаты qa-18: 1,5; 1,8; 1,7 секунды. Максимум 1,8 не превышает 2,0; вывод относится к этим настройкам и этим трём запускам.
Как записать результат каждого пункта
Результат каждого пункта запишите одним из четырёх исходов: пройдено, ошибка, заблокировано, не запускалось. Неприменимый пункт исключается отдельно с причиной. Ошибка означает наблюдаемое расхождение; блокировка — отсутствие условия для проверки; непрогон — действие ещё не выполнено. Для успешной строки не требуется отдельное вложение без необходимости доказательства.
| ID / окружение | Проверка | Ожидаемый результат | Факт qa-17 / исход |
|---|---|---|---|
| W01 / E1 | Открыть услугу через меню | Открылась согласованная страница услуги | Нужная страница открылась / пройдено |
| W02 / E1 | Сверить цену с утверждённым прайсом | На странице 4 500 ₽ | Цена совпала / пройдено |
| W03 / E1 | Отправить форму без телефона | Понятная ошибка у поля; фокус на телефоне | Отправки нет, ошибки и фокуса нет / ошибка WEB-021 |
| W04 / E1 | При валидных остальных полях ввести email user@ и отправить | Неверный email отклонён с понятной ошибкой | Ошибка показана / пройдено |
| W05 / E1 | Отправить валидную тестовую заявку | Одна заявка получена тестовым адресатом | Ящик недоступен; результат не проверен / заблокировано ENV-003 |
| W06 / E1 | Дважды нажать отправку валидной заявки | У адресата одна заявка | Ящик недоступен; дубли не проверить / заблокировано ENV-003 |
| W07 / E1+E2 | Открыть ту же форму с баннером | Кнопка отправки доступна в обоих браузерах | В E1 доступна; в E2 баннер закрывает кнопку / ошибка WEB-022 |
| W08 / E1 | Пройти форму клавиатурой | Фокус виден; из каждого поля можно выйти | Ловушки нет, фокус виден / пройдено |
| W09 / E1 | Открыть заведомо отсутствующую страницу | Понятная страница 404 с возвратом | Ожидаемый ответ 404 и переход доступны / пройдено |
| W10 / E1 | Открыть HTTPS-страницу формы | Нет предупреждения или смешанного содержимого | Предупреждений нет / пройдено |
| W11 / E1 | Измерить LCP в Lighthouse тремя запусками | Каждое значение не более 2,0 с по условию проекта | Не запускалось — на замер не хватило времени |
| W12 / E1 | После патча пройти путь от услуги до заявки | Критичный путь сохранил работоспособность | Не запускалось — назначено на повторный прогон |
Итог qa-17: 6+2+2+2=12. Две ошибки требуют двух баг-репортов. Общая проблема ящика создаёт одну задачу ENV-003, а не два новых бага. Сохраняйте причину блокировки и связь ошибки с её репортом. Отметка «не запускалось» не превращается в успешную по окончании выделенного времени.
Как передать исправления через Канбано
Исправления через Канбано передайте обычными карточками с описанием находок и подтверждением повторной проверки. Онлайн-доска сейчас бесплатна; она организует работу исполнителей. Сам прогон, сбор окружения и оценку результата выполняют люди. Специальный модуль тестирования или автоматическое закрытие ошибок в этом маршруте не предполагается.
Как написать баг-репорт
Баг-репорт — сообщение о конкретном расхождении с условиями воспроизведения и доказательством. Для WEB-021 ниже использованы вымышленные данные. Снимок сделан на локальном учебном стенде после нажатия «Отправить».
| Поле | Заполненный баг-репорт WEB-021 |
|---|---|
| Заголовок / связь | Пустой телефон не получает сообщения об ошибке; проверка W03 |
| Контекст | Учебный стенд, /zayavka, qa-17, E1, 31.10.2026 14:10 UTC+5, Ирина |
| Предусловия / данные | Новая форма; телефон пустой; email qa@example.test; имя Тест |
| Шаги | Открыть форму; заполнить имя и email; оставить телефон пустым; нажать «Отправить» |
| Ожидалось | Отправка отклонена; у телефона понятная ошибка; фокус на поле |
| Получено / доказательство | Форма остановилась без сообщения, фокус остался на кнопке. Доказательство — снимок WEB-021 ниже. |
| Влияние / приоритет | Посетитель не понимает отказ. Вторая очередь после WEB-022, до релиза; решение Ирины |
| Ответственность / приёмка | Олег исправляет; Ирина повторяет W03 на qa-18 в E1 и сохраняет результат |
WEB-022 идёт первой: мобильный посетитель не может отправить корректную заявку. WEB-021 — второй, но также до релиза. Влияние описывает последствие, приоритет — согласованный порядок. ENV-003 Дана выполняет параллельно. Одна ошибка сохраняет одну карточку; уровни влияния и приоритета записываются текстом.
Как распределить находки по исполнителям
Распределите находки по исполнителям через одну справочную карточку прогона и три рабочие карточки. В колонке «Прогон» хранится паспорт с двенадцатью пунктами. Для WEB-021, WEB-022 и ENV-003 задайте колонки «Найдена», «Исправляется», «Повторная проверка», «Закрыта». Всего четыре карточки, три рабочих, два дефекта.
Ирина проверяет, Олег исправляет ошибки, Дана восстанавливает ящик. Закрытие подтверждает Ирина; Олег не принимает собственную правку. Исполнитель, срок и метки задаются в карточке, контекст и доказательства сохраняются в описании и вложениях. Сначала настройте переходы карточек по фактическим передачам работы.
Чек-лист Канбано бинарный: галочку ставьте после успешной проверки. Ошибку, блокировку и непрогон храните текстом в журнале, не изображайте их встроенными состояниями пункта. Если процесс доски ещё не определён, отдельно разберите рабочую доску. Смена колонки не запускает тест и не меняет исход проверки сама.
Как подтвердить устранение дефекта
Устранение дефекта подтвердите повтором исходных шагов на исправленной сборке в том же окружении. Для WEB-021 повторите W03, для WEB-022 — W07. Если ошибка осталась, верните прежнюю карточку с новым доказательством и номером сборки. Новый дубль вместо возврата разрывает историю исправления.
После патча qa-18 заново выполните все двенадцать строк, включая шесть прежних успешных. W05 и W06 проверяются после восстановления ящика, W11 запускается впервые. W12 — один сквозной регрессионный сценарий: проверка, что ранее работавший путь от услуги до заявки сохранился. Двенадцать строк не превращаются в пятнадцать из-за нескольких действий внутри W12.
Разбирайте находки после прогона, пересматривайте порядок при блокировке критичного пути. Для итерационной работы можно отдельно проверить готовность спринта; условие исправления конкретной ошибки остаётся в её репорте.
Что означает окончание прогона
Окончание прогона означает, что выбранные проверки выполнены и их исходы записаны для конкретной сборки. В условной qa-18 получены все ожидаемые результаты таблицы: не только устранены два дефекта, но и подтверждены доставка, отсутствие дублей, загрузка и повторные успешные действия.
| Сборка | Пройдено | Ошибка | Заблокировано | Не запускалось | Всего | Решение по этому прогону |
|---|---|---|---|---|---|---|
| qa-17 | 6 | 2 | 2 | 2 | 12 | Прогон не завершён; релиз не принят |
| qa-18 | 12 | 0 | 0 | 0 | 12 | Выбранные проверки пройдены; решение о релизе отдельно |
Успех относится к выбранным требованиям и окружениям, а не к отсутствию всех багов и полной безопасности. Невыполненный критичный пункт нельзя закрыть галочкой. Владелец сайта принимает решение о релизе по условиям и остаточным рискам; команде нужно заранее установить критерий завершения.
Рабочий прогон оставляет воспроизводимые результаты, а каждая ошибка — исполнителя и подтверждённый ретест. Чтобы организовать проверку сайта, создайте доску Канбано, добавьте паспорт своего прогона и передавайте найденные ошибки исполнителям.