Перевод успешен в интерфейсе. Что ещё проверить?
У финансового продукта есть опасная фраза: «API ответил успешно, значит деньги дошли». В проверке я разделяю несколько наблюдений: что вернул запрос; какой статус записала система; возник ли один ожидаемый денежный эффект; совпали ли сумма, комиссия и округление; что увидел получатель; какое уведомление ушло клиенту. Особенно интересен таймаут. Первый запрос мог успеть создать эффект, а клиент об этом не узнал. Слепой повтор тогда рискует создать второй. Уверенный HTTP-ответ сам по себе не закрывает этот вопрос. В синтетическом открытом QA-кейсе разбираю, какие состояния нужно различать перед повтором и какие доказательства нужны для решения. Это учебная модель, не история о реальных клиентских платежах: https://github.com/safal207/ContractGraph-QA/blob/main/docs/case-studies/AMBIGUOUS_PAYMENT_RECOVERY.md Как ваша команда подтверждает результат после таймаута: по ответу API, записи у провайдера, учёту или нескольким независимым источникам? Я Алексей Сафонов, QA-инженер финансовых продуктов и наставник по API/SQL. Бесплатное 15-минутное знакомство: https://solvery.io/ru/mentor/5295
· 25.09
Та же ловушка вылезает и вне денег. Писал клиент к закрытому API площадки вакансий, документации нет, параметры восстанавливал запросами. Фильтр по навыку принимает только числовой идентификатор, а на строку отдаёт ноль результатов без всякой ошибки: запрос прошёл, ответ пришёл, данных нет. Рядом вторая ловушка: сверку делал по подстроке, и id 999 находился внутри 1000168999, поэтому проверка «уже видели» срабатывала на пустом месте. Теперь любой внешний ответ проверяю по второму независимому признаку, статуса мне мало. Код открыт: github.com/mvpcodego/habr-career-mcp
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён