Как написать сценарии проверки сайта от лица покупателя и редактора

Приёмку начинают с результата пользователя

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

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

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

Что записать в карточке сценария

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

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

Образец записи можно взять за основу. «Роль: покупатель. Условия: выбран доступный товар. Действие: увеличить количество и перейти в корзину. Ожидается: количество и сумма относятся к новому объёму. Фактически: заполняется после выполнения». К такой записи легко приложить снимок расхождения.

• Название задачи и роль.
• Исходные данные и состояние.
• Действия в понятной последовательности.
• Ожидаемый результат.
• Фактический итог и замечание.
• Повтор после исправления.

Покупатель проходит путь до принятого заказа

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

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

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

• Выбран именно продаваемый вариант.
• Количество сохраняется при переходе.
• Стоимость объяснена до подтверждения.
• Доставка относится к выбранному адресу.
• Подтверждение отражает принятые магазином сведения.

Менеджеру нужен тот же заказ

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

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

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

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

Редактор меняет настоящий тип материала

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

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

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

• Редактор находит нужную запись.
• Правит текст и заменяет изображение.
• Сохраняет либо публикует по принятому порядку.
• Открывает страницу и список материалов.
• Возвращает испытательные изменения.

Ошибка — тоже ожидаемый результат

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

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

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

• Отказ объясняет причину на языке пользователя.
• Исправляемое поле можно найти.
• Уже введённые допустимые данные сохраняются.
• Повтор действия не создаёт скрытого дубликата.

Один сценарий повторяют в разных условиях

Телефон меняет условия работы, а не смысл покупки. Те же данные проходят путь на узком экране, чтобы участники увидели потерянные кнопки и переносы.

Критерий 1.4.4 WCAG описывает увеличение текста до 200% без потери содержания и функций с исключениями. Это предметное условие для испытания формы: подписи читаются целиком, а кнопка остаётся достижимой после увеличения. Клавиатурному управлению посвящён критерий 2.1.1. Для приёмки его переводят в действие — пройти нужный путь без мыши и завершить операцию доступным способом. Набор устройств и браузеров участники называют заранее. Для каждого прогона сохраняют тот же ожидаемый итог покупки, чтобы телефон не получил упрощённый критерий готовности, при котором часть сведений или действий считается необязательной только из-за меньшего размера экрана устройства.

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

• Условия прогона записаны рядом с результатом.
• Клавиатура не закрывает продолжение.
• Увеличение не обрезает пояснения.
• Варианты товара можно выбрать на телефоне.

Замечание описывает потерю, а не способ починки

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

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

После правки повторите исходный сценарий. Затем повторите соседнее действие, на которое могла повлиять правка, и сохраните его результат вместе с исходным сценарием: по этим двум записям видно, удалось ли исправить проблему и сохранить связанную работу сайта.

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

Готовность выражается заполненным листом

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

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

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

• Путь покупателя подтверждён.
• Менеджер получает и обрабатывает тот же заказ.
• Редактор публикует нужный материал.
• Ошибки объяснены, повтор после правок выполнен.
• Решение о запуске связано с оставшимися замечаниями.