01
Начните с наблюдаемого результата
«Оплата работает корректно» не даёт QA критерия проверки. В учебном примере лучше: «после успешного подтверждения заказ paid; доставка инициирована; повтор того же подтверждения не создаёт второй доставки».
| Не хватает конкретики | Можно проверить |
|---|---|
| Проверить валидацию. | quantity = 0 → 400, записи заказа нет. |
| Проверить идемпотентность. | Тот же ключ и тело → исходный order_id, без второй записи. |
| Проверить отказ оплаты. | Заказ pending_payment, доставка не запущена. |
02
Передайте контекст вместе с критериями
Не назначайте критерием проверку, для которой команда ещё не определила ожидаемое поведение. Сначала согласуйте правило и запишите решение.
- Дайте доступ к документу продукта и описаниям участвующих сервисов.
- Укажите тестовое окружение и нужные входные данные.
- Уточните, какие события можно воспроизвести и как проверить их результат.
- Запишите, какие части сценария ещё требуют согласования.
03
Сохраните воспроизводимый запрос
В API-клиенте настройте метод, URL, заголовки и тело, затем сохраните запрос в коллекции. Один запрос используйте для основного сценария, его изменённые варианты — для невалидных данных и повтора.
Запишите фактический статус, тело ответа и идентификатор операции. Пример ожидаемого ответа из документа не заменяет результат выполнения запроса.
04
Проверяйте только нужные данные
Для создания заказа нужны его статус, состав и сумма. В подключённой тестовой БД найдите запись по order_id; сравните её с ответом и спецификацией. Повтор запроса должен вернуть тот же заказ, а не только такой же ответ с другим идентификатором.
SELECT sku, quantity, unit_price_minor
FROM order_items
WHERE order_id = 'ord-001';05
Верните расхождения в план работы
При расхождении создайте карточку на канбан-доске: шаги, входные данные, ожидаемый и фактический результат, окружение, order_id. Добавьте ссылку на описание правила и выберите связанный сервис, если он известен.
SAQA в этом сценарии — описание системы, HTTP-клиент, обозреватель данных и задачи. Отдельный модуль управления тест-кейсами или автоматическое выполнение всего чек-листа здесь не предполагается.
МАТЕРИАЛЫ ДЛЯ РАБОТЫ
Продолжите на своём примере
Спецификация заказа
Заполненный пример: границы, сценарии, API, ошибки и критерии приёмки.
Чек-лист проверки заказа
Десять проверок по учебной спецификации и поля для фактического результата.
Тело запроса создания
Учебные входные данные для ручной настройки HTTP-запроса.
Учебные правила и данные нужно адаптировать к вашей системе. Набор не является готовой реализацией магазина.
Скачать полный набор ↓