Tester su una FinTech multicanale: una checklist nata da un anno di difetti condivisi

Un endpoint che si rompe può bloccare la stessa funzione su portale web, Telegram Mini App e bot. Dopo un anno a testare una piattaforma FinTech accessibile da tre canali, l’autore ha trasformato questa lezione in una checklist operativa¹.

Ha iniziato dalle API. I tre canali parlavano con lo stesso backend, quindi l’API era il punto più rapido per trovare il guasto quando qualcosa non tornava in alcun canale¹. Strumenti quotidiani, semplici e diretti: Swagger o OpenAPI per leggere le promesse degli endpoint, Postman per chiamarli con le stesse richieste inviate da portale, Mini App e bot, DBeaver con SQL su PostgreSQL per vedere cosa è finito davvero nel database, Docker per avviare parti del sistema in locale, DevTools del browser per ispezionare traffico e payload del front end, Playwright per check automatici dei flussi web¹. Molti difetti avevano una radice comune: endpoint che non rispettavano le attese. Individuarli a livello API ha evitato di inseguire lo stesso bug in tre interfacce¹.

La Telegram Mini App è una pagina web che vive dentro Telegram, e questo cambia il test plan. La stessa vista può comportarsi in modo diverso su iOS, Android, desktop e web: serve copertura multipiattaforma. L’utente arriva con dati d’identità forniti da Telegram, che il backend deve validare: vale la pena vedere cosa accade se la si apre fuori da Telegram o con parametri mancanti o scaduti. Lo spazio è limitato e condiviso con l’interfaccia Telegram, tastiera inclusa, e il tema chiaro o scuro altera la resa. Il debugging resta più agevole su Telegram Desktop o Web, quindi conviene riprodurre lì per primi i problemi¹.

Il bot è un canale a tutti gli effetti. In un prodotto finanziario spesso manda il primo messaggio che il cliente legge sui propri soldi. Se quel testo è sbagliato, la correttezza del portale non basta¹. Gli errori più frequenti: importi, valute e stati che non corrispondono a portale e database, messaggi inviati prima che l’operazione sia conclusa, duplicati per lo stesso evento, formattazioni che si spezzano su caratteri speciali. Ogni messaggio va trattato come un report da riconciliare¹.

Il terzo fronte, il più costoso, sono i numeri incoerenti. Totali di report che non sommano correttamente, o che divergono dalla stessa cifra mostrata altrove¹. La regola di lavoro è diventata una: per ogni numero importante, trovare tutti i posti dove compare e verificare l’accordo tra loro, fino al database. Per un pagamento, controllare portale, Mini App, bot, export e tabelle nel database. Quando i conti non tornano, l’SQL di solito indica quale fonte sbaglia e perché, tra arrotondamenti, periodi o record mancanti¹. Da questa abitudine è nato LogiParity, un tool open source che confronta gli stessi record tra API, export, tabelle UI e database. Esempio: prendere un pagamento e verificare che valori e stato coincidano in tutti i canali e negli export¹.

Le suite smoke e di regressione hanno coperto tutti e tre i canali e hanno ridotto il tempo di regressione di circa il 40% secondo la stima dell’autore. Check automatici su API e report in GitLab CI/CD hanno alleggerito il manuale. Il metodo: descrivere ogni flusso di business una sola volta, poi verificare ogni step in ciascun canale. I buchi emergono subito, perché qualunque step privo di check in un canale risalta¹.

Checklist di partenza: mappare gli endpoint usati da ogni canale e testarli direttamente, aprire la Mini App su almeno due client Telegram in tema chiaro e scuro, validare il trattamento dei dati di lancio Telegram, trattare ogni messaggio del bot come un report, confrontare ogni numero importante in tutti i luoghi in cui appare, scrivere gli scenari di regressione per flusso e applicarli a ogni canale¹. La maggior parte dei bug in un prodotto multicanale nasce dove i canali dovrebbero concordare¹.