Откуда берутся данные для формирования ордера?
Что проверяют
Видите ли вы систему дальше экрана. Ордер это составной объект, поля которого приходят из разных мест, и каждое место это отдельный риск. По ответу понятно, придумаете ли вы проверки, которых нет в постановке задачи, и сможете ли локализовать дефект, а не написать «сумма посчиталась неправильно».
Как отвечать
Разложите ордер по источникам полей:
- от пользователя: инструмент или товар, количество, цена, тип заявки. Всё введённое руками проверяется на границы и на подмену на уровне запроса, а не только в форме;
- из справочников: шаг цены, размер лота, единицы измерения, доступные способы доставки. Это мастер-данные, они меняются независимо от нашего релиза;
- из внешних сервисов: котировка, курс, остаток на складе, лимит и баланс клиента. Здесь важны таймаут, отказ и устаревший ответ;
- считает сам бэкенд: идентификатор, время, комиссия, итоговая сумма, статус;
- из контекста сессии: кто клиент, какой счёт, какие права и тариф.
Дальше скажите, что из этого следует для проверок. Поля, которые считает сервер, не должны приниматься с клиента. Ответ внешнего сервиса подменяется заглушкой, чтобы увидеть поведение при отказе и при пустом ответе. Повторная отправка одной формы не должна порождать два ордера, для этого есть ключ идемпотентности. Полезно попросить схему потока и логи со сквозным идентификатором запроса: по ним видно, на каком шаге поле испортилось.
Где спотыкаются
Проверяют только счастливый путь через интерфейс. Валидация в обход формы, например прямой запрос к API с отрицательным количеством, остаётся непроверенной, а дыра чаще всего именно там.
Забывают про рассинхрон во времени. Цена обновилась между показом и подтверждением, ордер ушёл по старой, и такой сценарий сам собой не воспроизводится, его надо ставить специально.
Не отделяют источник поля от места сбоя. Отчёт «неверная сумма» без понимания, кто её считает и из чего, возвращают на уточнение, и цикл исправления растягивается.