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