forumApri un argomento

È normale accettare la consegna senza test di integrazione API, avremmo dovuto metterlo come clausola nel contratto?

AAleyna E***PartecipanteMembro della community
Iscrizione
ago 2024
Messaggio
80
#1

Siamo un'attività di Parigi che gestisce un boutique hotel e tour guidati della città. Per rinnovare il nostro sito web e l'infrastruttura di prenotazione diretta, abbiamo firmato un contratto con una software house locale per un budget di 14.000 EUR e tempi di consegna di 3 mesi. Lo sviluppo è terminato e il progetto ci è stato presentato per l'approvazione, dicendoci che il gateway di pagamento e il motore di prenotazione sono stati collegati al sistema.

Tuttavia, quando abbiamo chiesto se l'API di pagamento, la sincronizzazione del calendario e le email di conferma automatica fossero state testate end-to-end, l'agenzia ci ha dato una risposta assurda: "Noi abbiamo collegato gli endpoint necessari, il sistema restituisce codice 200. Gli altri scenari potete provarli voi direttamente in produzione o con le vostre carte di test." In pratica, non è stata fatta alcuna simulazione, nessun test di transazioni fallite o test di carico.

Non avendo mai gestito un processo tecnico del genere, non sappiamo come muoverci. È normale che una software house consegni un progetto in questo modo, senza eseguire test di integrazione API? Come dovremmo richiedere legalmente e tecnicamente questi test prima di pagare l'ultimo SAL di 4.000 EUR rimasto?

KKemal G***Partecipante
Ruolo
Addetto al negozio
Settore
Servizi IT
Tipo di organizzazione
media impresa
Iscrizione
apr 2023
Messaggio
7

Doki · Supporto risposta agli incidenti · 2024

Più utile#2

Risposta breve: Non è assolutamente normale e nessun software di pagamento o prenotazione può essere accettato senza test di integrazione. Una risposta positiva dall'endpoint dell'API dimostra solo che i server comunicano tra loro; non prova affatto che i soldi vengano prelevati correttamente, che la prenotazione venga registrata nel database senza errori o come reagirà il sistema se la transazione si interrompe a metà.

Il test di integrazione è il processo di convalida dei vari scenari che possono presentarsi durante lo scambio di dati tra due sistemi differenti. Sul fronte pagamenti e prenotazioni non si testano solo le transazioni andate a buon fine. Vengono simulati casi limite come saldo insufficiente, carta non valida, timeout, blocco dei doppi addebiti e corretta elaborazione delle notifiche webhook. Il fatto che l'agenzia dica 'provatelo voi in produzione' significa scaricare direttamente sulle vostre spalle il rischio che, a fronte di un disservizio, ai clienti vengano scalati i soldi senza che la prenotazione venga generata.

Bloccate assolutamente il pagamento dei restanti 4.000 EUR e formalizzate la procedura in questi passaggi: 1) Inviate una comunicazione scritta all'agenzia precisando che, in assenza dei report di test, la fase di User Acceptance Testing (UAT) non può considerarsi conclusa. 2) Richiedete come criterio di accettazione una matrice di scenari eseguiti almeno in ambiente sandbox comprensiva di pagamento riuscito pagamento fallito, processo di rimborso, timeout e trigger dei webhook. 3) Esigete che i log delle esecuzioni dei test (automatici o manuali) e i report dei log di errore siano allegati al verbale formale di consegna.

Anche se nel vostro contratto non fosse presente un capitolato tecnico dettagliato, in base al diritto delle obbligazioni e agli usi commerciali locali la consegna di un software conforme allo scopo e privo di vizi costituisce l'obbligazione principale del fornitore. Un sistema con integrazioni incomplete rientra a tutti gli effetti nell'adempimento inesatto o viziato.

MMehmet I***PartecipanteMembro della community
Iscrizione
mag 2024
Messaggio
3
#3

Lavoro su progetti del genere da anni, l'agenzia sta solo cercando di scaricare su di voi la parte più noiosa del lavoro, ossia i test di scenario. Che l'endpoint risponda 200 non significa un bel niente. La banca o il gateway approvano la transazione, ma se in quel momento il vostro sistema va in timeout che succede? Un'infrastruttura di pagamento non testata non si manda mai in produzione.

SSelinPartecipante
Ruolo
Sviluppatore frontend
Tipo di organizzazione
Azienda di 20 persone
Iscrizione
feb 2024
Messaggio
164
#4

Nei sistemi di pagamento la cosa critica è la gestione dei webhook. Se l'utente chiude il browser o cade la connessione, riescono a gestire la notifica asincrona in background? In caso di rimborso o cancellazione parziale, come si comporta l'API? Sono tenuti a fare questi test in ambiente sandbox con richieste simulate e a presentarvi i relativi log.

VVeli Y***PartecipanteMembro della community
Iscrizione
feb 2024
Messaggio
8
#5

Bloccate subito il saldo finale. Mandate una mail all'agenzia scrivendo: 'In base ai nostri criteri di accettazione, il verbale di collaudo non verrà firmato finché non saranno documentati nell'ambiente di test del gateway i 5 scenari base (addebito riuscito, plafond insufficiente, annullamento 3D Secure, timeout e rimborso automatico)'. Vedrete come cambiano subito atteggiamento.

VVolkan U***PartecipanteMembro della community
Iscrizione
feb 2024
Messaggio
56
#6

Due anni fa abbiamo fatto lo stesso identico errore su un nostro progetto di tour da 18.000 EUR di budget. Ci siamo fidati dell'agenzia e siamo andati live; la prima settimana su 22 transazioni i soldi sono stati scalati ma non si è registrata la prenotazione a calendario. Abbiamo dovuto rimborsare 3.100 EUR ai clienti e tenere il sistema spento per 10 giorni. Tre giorni risparmiati sui test ci sono costati due settimane di lavoro.

EEbru O***Partecipante
Ruolo
Addetto al controllo qualità
Settore
Servizi IT
Tipo di organizzazione
Team di 8 persone
Iscrizione
gen 2022
Messaggio
139
#7

Nel contratto che avete firmato c'è una clausola sui test di accettazione o sulla messa in produzione? Se hanno inserito la classica clausola tipo 'in assenza di contestazioni entro 14 giorni dall'approvazione del cliente il lavoro si intende accettato', vi conviene inviare subito una contestazione formale scritta prima che scadano i termini.

YYiğit Ç***PartecipanteMembro della community
Iscrizione
mar 2025
Messaggio
107
#8

Secondo me l'agenzia non ha nemmeno uno sviluppatore in grado di scrivere test di integrazione. Di solito installano il plugin già pronto, incollano due chiavi API e pensano di aver finito. Per questo buttano la palla in tribuna. Anche se insistete, molto probabilmente non riusciranno a tirare fuori una matrice di test decente.

PPerihan K***PartecipanteMembro della community
Iscrizione
gen 2023
Messaggio
152
#9

Al momento della consegna dovete pretendere questi tre documenti: 1) Tabella dei risultati degli scenari eseguiti in ambiente sandbox, 2) Screenshot dei messaggi di errore mostrati all'utente nelle transazioni fallite, 3) Report di corrispondenza tra le transazioni effettuate con carte di test sul pannello di pagamento e il database del sito. Senza questi, il sistema non può considerarsi consegnato.

ÖÖzgür Y***Partecipante
Ruolo
IT Manager
Settore
Chimica
Tipo di organizzazione
boutique agency
Iscrizione
nov 2023
Messaggio
5

Doki · App mobile · 2025

#10

non fatevi prendere dall'ansia ma non mollate di un millimetro poi i programmatori odiano fare i test perché sistemare i bug che saltano fuori fa slittare le consegne. comunque tenetevi stretti i vostri soldi, finché non arriva il report dei test quei 4.000 EUR non devono uscire dalla cassa.

LLale K***PartecipanteMembro della community
Iscrizione
ott 2025
Messaggio
323
#11

Mi sono rilassato leggendo questa risposta quindi non succede solo a me. insomma se non sono stati definiti i criteri di accettazione, il momento in cui il lavoro è finito è discutibile.

Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

TTülay K***EspertoMembro della community
Iscrizione
lug 2022
Messaggio
276
#12

Riassumo quanto detto finora. Dopo la consegna il sistema continua a vivere; la manutenzione è una voce a parte.

Il calendario dei pagamenti va legato alle fasi del lavoro, non alle date. Confermato dall'esperienza.

MMustafa M***Partecipante
Ruolo
Addetto al controllo qualità
Settore
Commercio all'ingrosso alimentare
Tipo di organizzazione
distributore di zona
Iscrizione
feb 2024
Messaggio
106
#13

Avete ragione, sono passato anch'io per la stessa strada. Dopo la consegna il sistema continua a vivere; la manutenzione è una voce a parte.

Introdurre un processo per le richieste di modifica non rallenta il lavoro, lo accelera. È tutto, scusate se mi sono dilungato.

IIrmak B***PartecipanteMembro della community
Iscrizione
gen 2025
Messaggio
304
#14

Esatto, e non è nemmeno così noto. Dopo la consegna il sistema continua a vivere; la manutenzione è una voce a parte.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

MMeryem S***Partecipante
Ruolo
System administrator
Settore
Elettrotecnica ed elettronica
Tipo di organizzazione
attività con due sedi
Iscrizione
mar 2026
Messaggio
398
#15

Non lo sapevo. Quando prendi una decisione guarda prima quali dati hai a disposizione.

Naturalmente cambia se la vostra situazione è diversa.

OOkan I***Partecipante
Ruolo
Contabilità di base
Settore
Cosmetica
Tipo di organizzazione
ditta individuale
Iscrizione
nov 2023
Messaggio
260
#16

Hai fatto bene ad aprire questo thread.

FFatma G***PartecipanteMembro della community
Iscrizione
mar 2023
Messaggio
24
#17

Può approfondire un po'? cioè dopo la consegna il sistema continua a vivere; la manutenzione è una voce a parte.

Lascio una nota, potrebbe servire.

MMurat T***Partecipante
Ruolo
Amministratore di rete
Settore
Assicurazioni
Tipo di organizzazione
boutique agency
Iscrizione
gen 2025
Messaggio
80
#18

C'è una parte che non ho capito. Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

CCeren K***PartecipanteMembro della community
Iscrizione
gen 2023
Messaggio
377
#19

Sono passato da qui, vi racconto. L'errore commesso da test di integrazione api è generalmente reversibile ma costoso.

Lascio una nota, potrebbe servire.

SSinan B***VeteranMembro della community
Iscrizione
apr 2022
Messaggio
48
#20

Ti seguo.

Rispondi