forumСоздать тему

Нормально ли принимать работу без интеграционного тестирования API, или это нужно было прописывать в договоре?

AAleyna E***УчастникУчастник сообщества
Дата регистрации
авг. 2024 г.
Сообщение
80
#1

У нас бутик-отель и экскурсии по Парижу с гидом. Чтобы обновить сайт и модуль прямого бронирования, заключили договор с местным веб-агентством с бюджетом 14.000 EUR и сроком сдачи 3 месяца. Разработку закончили и выкатили проект на согласование, сказав, что платежный шлюз и движок бронирования подключены.

Но когда мы спросили, протестированы ли сквозным образом платежный API, синхронизация календаря и автоотправка подтверждений на почту, агентство выдало потрясающий ответ: «Мы нужные эндпоинты подключили, система возвращает 200 код. Остальные сценарии можете сами потестить на проде или своими тестовыми картами». То есть ни симуляций, ни кейсов с неудачной оплатой, ни нагрузочного тестирования никто не делал.

Раньше с такими техпроцессами дела не имели, теперь не знаем, за что хвататься. Это вообще в порядке вещей, когда веб-агентство сдает проект без интеграционных тестов API? Как грамотно — юридически и технически — потребовать эти тесты до выплаты финального транша в 4.000 EUR?

KKemal G***Участник
Должность
Продавец-консультант
Отрасль
ИТ-услуги
Тип организации
среднее предприятие
Дата регистрации
апр. 2023 г.
Сообщение
7

Doki · Поддержка реагирования на инциденты · 2024

Самый полезный#2

Если коротко: это абсолютно ненормально, и ни один софт с оплатой и бронированием нельзя принимать без интеграционных тестов. То, что эндпоинт API отдает успешный статус, говорит лишь о том, что серверы видят друг друга. Это никак не гарантирует корректное списание денег безошибочную запись брони в БД или правильное поведение системы при обрыве транзакции.

Интеграционное тестирование — это проверка сценариев, возникающих при обмене данными между двумя системами. В модулях оплаты и бронирования проверяют не только успешный путь. Обязательно симулируют граничные случаи: нехватку средств, невалидную карту, таймауты защиту от повторных списаний и корректную обработку вебхуков. Заявление агентства «проверьте сами на проде» — это попытка повесить на вас риск того, что у клиента спишутся деньги, а бронь просто не создастся.

Последний транш в 4.000 EUR однозначно заморозьте и переведите общение в официальное русло: 1) Направьте письменное уведомление, что без отчетов о тестировании этап приемочного тестирования (UAT) не может считаться завершенным. 2) В качестве критериев приемки потребуйте матрицу сценариев минимум в песочнице (sandbox): успешная оплата, отказ в платеже, возврат, таймаут и триггеры вебхуков. 3) Пропишите обязательным приложением к акту приемки логи и отчеты об автоматических или ручных прогонах тестов.

Даже если в вашем договоре нет подробного техзадания, по нормам обязательственного права и деловым обычаям подрядчик обязан передать софт пригодным для использования и без дефектов. Система с недоделанной интеграцией — это оказание услуг ненадлежащего качества.

MMehmet I***УчастникУчастник сообщества
Дата регистрации
май 2024 г.
Сообщение
3
#3

Сколько лет в разработке кручусь — агентство просто пытается спихнуть на вас самую муторную часть, тестирование сценариев. 200 код от эндпоинта вообще ничего не значит. Банк или шлюз платеж одобрят, а у вас в этот момент система упадет по таймауту — и что дальше? Непротестированные платежи на прод не выкатывают.

SSelinУчастник
Должность
Фронтенд-разработчик
Тип организации
компания из 20 человек
Дата регистрации
февр. 2024 г.
Сообщение
164
#4

В платежках самое больное место — обработка вебхуков. Умеют ли они в фоне парсить асинхронный ответ, если юзер закрыл вкладку или отвалился интернет? Как ведет себя API при возврате или частичной отмене? Они обязаны прогнать эти кейсы в песочнице с моковыми запросами и положить вам на стол логи.

VVeli Y***УчастникУчастник сообщества
Дата регистрации
февр. 2024 г.
Сообщение
8
#5

Финалку пока на стоп. Пишите им на почту: «Согласно нашим критериям приемки, акт не будет подписан без документального подтверждения 5 базовых сценариев в тестовой среде провайдера (успех, нехватка лимита, отмена 3D Secure, таймаут и автовозврат)». Спеси сразу поубавится.

VVolkan U***УчастникУчастник сообщества
Дата регистрации
февр. 2024 г.
Сообщение
56
#6

Мы пару лет назад так же влетели на проекте с турами с бюджетом 18.000 EUR. Поверили агентству на слово и зарелизились: за первую неделю по 22 операциям деньги ушли, а в сетку броней не упали. Пришлось вернуть клиентам 3.100 EUR и положить сайт на 10 дней. Зажали три дня на тесты — влетели на две недели геморроя.

EEbru O***Участник
Должность
Специалист по контролю качества
Отрасль
ИТ-услуги
Тип организации
команда из 8 человек
Дата регистрации
янв. 2022 г.
Сообщение
139
#7

В договоре есть пункт про приемочное тестирование или ввод в эксплуатацию? Если там стандартная формулировка типа «считается принятым если заказчик не направил мотивированный отказ в течение 14 дней», срочно отправляйте письменную претензию пока срок не сгорел.

YYiğit Ç***УчастникУчастник сообщества
Дата регистрации
март 2025 г.
Сообщение
107
#8

Похоже, в агентстве просто некому писать интеграционные тесты, нет таких спецов. Обычно ставят готовый плагин, вбивают пару ключей API и думают, что дело в шляпе. Вот и съезжают с темы. Даже если надавите, вряд ли они вменяемую тест-матрицу соберут.

PPerihan K***УчастникУчастник сообщества
Дата регистрации
янв. 2023 г.
Сообщение
152
#9

При приемке требуйте три вещи: 1) отчет по прогону сценариев в sandbox, 2) скриншоты ошибок, которые видит клиент при сбоях, 3) сверку транзакций по тестовым картам между панелью шлюза и БД сайта. Без этого работу принимать нельзя.

ÖÖzgür Y***Участник
Должность
ИТ-ответственный
Отрасль
Химия
Тип организации
бутиковое агентство
Дата регистрации
нояб. 2023 г.
Сообщение
5

Doki · Мобильное приложение · 2025

#10

не переживайте, но слабину не давайте... разрабы тесты терпеть не могут, потому что вылезающие баги срывают дедлайны... стойте на своем: пока нет отчета по тестам, эти 4.000 EUR они не увидят.

LLale K***УчастникУчастник сообщества
Дата регистрации
окт. 2025 г.
Сообщение
323
#11

Прочитал этот ответ и выдохнул: значит проблема не только у меня. кстати если критерии приемки не прописаны момент завершения работы становится предметом спора.

Если не зафиксировать это письменно с самого начала потом возникнут споры.

TTülay K***ЭкспертУчастник сообщества
Дата регистрации
июль 2022 г.
Сообщение
276
#12

Позвольте подвести итог сказанному выше. После сдачи проекта система продолжает жить; обслуживание — отдельная статья расходов.

График платежей должен быть привязан к этапам работ, а не к датам. Проверено опытом.

MMustafa M***Участник
Должность
Специалист по контролю качества
Отрасль
Оптовая торговля продуктами питания
Тип организации
региональный дилер
Дата регистрации
февр. 2024 г.
Сообщение
106
#13

Вы правы, я сам проходил через это. После сдачи проекта система продолжает жить; обслуживание — отдельная статья расходов.

Внедрение процесса управления изменениями не замедляет работу, а ускоряет её. На этом всё, извините, если затянул.

IIrmak B***УчастникУчастник сообщества
Дата регистрации
янв. 2025 г.
Сообщение
304
#14

Именно так, и при этом об этом мало кто знает. После сдачи проекта система продолжает жить; обслуживание — отдельная статья расходов.

Интересно, есть ли те, кто делает иначе.

MMeryem S***Участник
Должность
Системный администратор
Отрасль
Электротехника и электроника
Тип организации
компания с двумя филиалами
Дата регистрации
март 2026 г.
Сообщение
398
#15

Не знал об этом. Прежде чем принимать решение, посмотрите, какие данные у вас есть.

Конечно если ваша ситуация отличается всё меняется.

OOkan I***Участник
Должность
Первичная бухгалтерия
Отрасль
Косметика
Тип организации
индивидуальный предприниматель
Дата регистрации
нояб. 2023 г.
Сообщение
260
#16

Хорошо, что вы создали эту тему.

FFatma G***УчастникУчастник сообщества
Дата регистрации
март 2023 г.
Сообщение
24
#17

Не могли бы вы это пояснить? короче после сдачи проекта система продолжает жить; обслуживание — отдельная статья расходов.

Оставлю как заметку пригодится.

MMurat T***Участник
Должность
Сетевой администратор
Отрасль
Страхование
Тип организации
бутиковое агентство
Дата регистрации
янв. 2025 г.
Сообщение
80
#18

Есть момент который я не понял. Больше всего времени у нас уходило на то, что было непонятно, кто принимает решения.

CCeren K***УчастникУчастник сообщества
Дата регистрации
янв. 2023 г.
Сообщение
377
#19

Я проходил через это, расскажу. ну ошибка, сделанная на стороне интеграционное тестирование api обычно исправима, но дорого.

Оставлю как заметку, пригодится.

SSinan B***ВетеранУчастник сообщества
Дата регистрации
апр. 2022 г.
Сообщение
48
#20

Слежу за темой.

Написать ответ