Хороший тестовый набор описывает одну задачу и ожидаемые результаты. Он не обязан повторять всю организацию. Его ценность — возможность безопасно и одинаково проверить договорённость в обеих системах.
Минимальный набор полей и связей
Возьмём учебный обмен заказами между кабинетом и системой обработки. Для первого набора нужны организация, заказ, позиции, единицы количества и допустимый статус. Персональные контакты, реальные цены по договорам и история переписки не нужны, если проверяемая операция их не использует.
Минимальность не означает случайное удаление столбцов. Если поле участвует в выборе склада или проверке принадлежности заказа, его надо сохранить в условном виде. Связь заказа с организацией и позиций с заказом должна оставаться понятной. Иначе тест проверит искусственный объект, который источник никогда не создаёт.
Составьте карту: какие поля определяют решение, какие только отображаются, какие исключаются. Назначьте владельца, который подтвердит достаточность набора. Это конкретизирует границы интеграции до передачи данных.
Синтетические исключения без персональных данных
Для нашего примера придуманы организации «Учебный Север» и «Учебный Юг», товары T-1 и T-2. Эти названия не относятся к клиентам АИС. Условные значения должны быть узнаваемо учебными, но сочетания полей — соответствовать выбранной модели процесса.
Нужны не только удобные строки. Добавьте неизвестный код товара, пустое обязательное поле, заказ чужой организации и позицию с недопустимым количеством. Каждый случай должен проверять одну причину, иначе ошибка может скрыть другую. Для исследования комбинаций создают отдельные случаи с объяснением, зачем соединены нарушения.
Замена имени в копии рабочего документа не гарантирует удаления закрытых сведений: они могут остаться в комментариях, вложениях или других полях. Если набор собирается из рабочих данных, его состав и разрешение на передачу проверяет владелец. Для обсуждаемого примера проще использовать полностью придуманные записи с сохранёнными нужными связями.
Версия набора и ожидаемые результаты
Зафиксируем набор orders-fixture-1. Версия нужна, чтобы два участника не сравнивали результаты на разных данных. Если после исправления код товара стал известным, прежний тест неизвестного кода перестаёт проверять задуманное условие.
| Случай | Вход | Ожидаемый результат |
|---|---|---|
| Заказ своей организации | Север, T-1, допустимое количество | Запись принята в согласованное состояние |
| Неизвестный товар | Север, T-unknown | Явная причина; товар не подбирается по догадке |
| Чужая организация | Пользователь Севера, заказ Юга | Действие не разрешено; чужие сведения не раскрыты |
| Пустое обязательное поле | Нет идентификатора заказа | Запись не создана, указано отсутствующее поле |
| Недопустимое количество | Значение за выбранной границей | Ошибка количества без скрытого округления |
Для каждого случая сохраняют исходный запрос, ожидаемый смысл ответа и допустимое состояние получателя. Если проверяется изменение, нужны данные до операции и после неё. Одного снимка интерфейса недостаточно, чтобы понять, какая запись была обработана.
Набор и ожидания передают вместе. При изменении правила создают новую версию, объясняют отличие и сохраняют старую для разбора прежнего результата. Это поддерживает приёмку рабочего сценария, а не заменяет её.
Граница допуска к рабочим данным
Успешное прохождение учебного набора говорит только о проверенных условиях. Оно не даёт автоматического разрешения подключиться к рабочему источнику или отправить реальные заказы. Переход к рабочим данным требует отдельной границы действий, прав и ответственности.
В паспорте набора укажите назначение, версию, источники, перечень полей, учебные связи, ожидаемые ответы и ограничения. Отдельная строка описывает, что не проверено: например, большой объём, редкие варианты заказа или реальное взаимодействие с внешней организацией. Это предотвращает превращение маленькой демонстрации в обещание готовности всей интеграции.
Перед передачей подрядчику полезно повторить одну операцию по паспорту силами принимающей команды. Если она не может восстановить исходные условия, комплект ещё не готов. Следующий разговор тогда будет посвящён конкретным отсутствующим полям или ожиданиям, а не поиску доступа к полной базе.
