← Все материалы

Аналитику и QA

Как передать спецификацию в разработку и QA

От «проверить оплату» к конкретным входам, ожидаемым результатам и проверкам повторного вызова.

Учебный примерФайлы к материалу ↓

01

Начните с наблюдаемого результата

«Оплата работает корректно» не даёт QA критерия проверки. В учебном примере лучше: «после успешного подтверждения заказ paid; доставка инициирована; повтор того же подтверждения не создаёт второй доставки».

Не хватает конкретикиМожно проверить
Проверить валидацию.quantity = 0 → 400, записи заказа нет.
Проверить идемпотентность.Тот же ключ и тело → исходный order_id, без второй записи.
Проверить отказ оплаты.Заказ pending_payment, доставка не запущена.

02

Передайте контекст вместе с критериями

Не назначайте критерием проверку, для которой команда ещё не определила ожидаемое поведение. Сначала согласуйте правило и запишите решение.

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

03

Сохраните воспроизводимый запрос

В API-клиенте настройте метод, URL, заголовки и тело, затем сохраните запрос в коллекции. Один запрос используйте для основного сценария, его изменённые варианты — для невалидных данных и повтора.

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

04

Проверяйте только нужные данные

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

SQL / Найти строки заказа
SELECT sku, quantity, unit_price_minor
FROM order_items
WHERE order_id = 'ord-001';

05

Верните расхождения в план работы

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

SAQA в этом сценарии — описание системы, HTTP-клиент, обозреватель данных и задачи. Отдельный модуль управления тест-кейсами или автоматическое выполнение всего чек-листа здесь не предполагается.

МАТЕРИАЛЫ ДЛЯ РАБОТЫ

Продолжите на своём примере

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

Скачать полный набор ↓

Инструменты из этого материала