I casi di test del modulo di fatturazione sono i controlli che decidono se la vostra schermata di fatturazione sopravvive al contatto con un cliente aziendale reale. La schermata sembra semplice — un nome, un indirizzo, un paio di numeri — ed è dove si nascondono i difetti più costosi, perché i guasti sono silenziosi: una fattura che viene generata, inviata ed è sbagliata.
Questo articolo stabilisce cosa raccoglie realmente un modulo di fatturazione aziendale, quali rami del modulo sono più spesso sotto-testati, come costruire una matrice di casi che li copra e cosa osservare oltre al modulo stesso.
Cosa raccoglie realmente un modulo di fatturazione aziendale?
Più di un checkout per consumatori, e in una forma diversa. Un modulo di fatturazione per consumatori vuole un nome e un indirizzo. Un modulo di fatturazione aziendale vuole sapere quale organizzazione viene fatturata, in quale veste e con quale trattamento fiscale.
I campi variano da paese a paese, ma si raggruppano in categorie familiari:
- Chi viene fatturato — la ragione sociale dell’impresa e spesso una denominazione commerciale diversa da essa.
- Identificatori — il numero di registrazione aziendale, un identificativo fiscale e un numero di partita IVA dove il paese ne rilascia uno.
- Indirizzo di fatturazione — l’indirizzo che la fattura deve mostrare, che non è sempre l’indirizzo di consegna o la sede legale.
- Contatto — una persona a cui inviare la fattura e spesso un indirizzo separato per la consegna della fattura.
- Condizioni di pagamento — valuta, un riferimento dell’ordine di acquisto e tutto ciò che richiede l’ufficio contabilità del cliente.
Il punto strutturale importante è che la stessa schermata serve due popolazioni molto diverse. Un cliente aziendale ha bisogno dei campi degli identificatori; una persona fisica no e di solito non può compilarli. Un modulo che presenta un unico insieme fisso di campi a entrambi o raccoglierà sciocchezze dalle persone fisiche o bloccherà le imprese.
Quali sono i quattro rami attraverso cui testare ogni modulo di fatturazione?
Ogni modulo di fatturazione aziendale ha almeno quattro percorsi significativamente diversi, e la maggior parte dei difetti vive ai confini tra essi.
| Ramo | Cosa cambia | Cosa si rompe di solito |
|---|---|---|
| Impresa con partita IVA | I campi degli identificatori sono obbligatori e validati | I controlli di formato transfrontalieri respingono un numero legittimo |
| Impresa senza partita IVA | Il campo deve essere realmente facoltativo | Un attributo di campo obbligatorio rende impossibile l’invio |
| Transfrontaliero | Trattamento fiscale e regole sugli identificatori seguono il paese dell’acquirente | Assunzioni nazionali vengono applicate a un indirizzo estero |
| Acquirente persona fisica | I campi aziendali dovrebbero sparire del tutto | Campi semi-obbligatori restano e bloccano il completamento |
Testate ogni ramo due volte: una con input validi e una con input deliberatamente sbagliati in un solo modo esatto. La seconda passata è dove viene esercitata la gestione degli errori, e la gestione degli errori sui moduli di fatturazione è dove i clienti si arrendono.
Un minimo pratico è di otto casi — quattro rami, ciascuno in forma valida e non valida — più le coppie ai due lati di ogni confine: passaggio da persona fisica a impresa a metà modulo, cambio di paese dopo aver inserito gli identificatori e ritorno a una bozza salvata. Questi casi di transizione colgono lo stato che i casi singoli non toccano mai.
Perché lo stesso campo si comporta diversamente in paesi diversi?
Perché il requisito deriva dalle norme fiscali e di fatturazione nazionali, e quelle norme differiscono su quali campi una fattura debba portare e cosa debba contenere ciascun campo.
Alcune giurisdizioni si aspettano l’identificativo fiscale dell’acquirente su una fattura aziendale; altre non lo richiedono nelle stesse circostanze. Alcune richiedono un numero di registrazione, alcune un numero fiscale e alcune entrambi. Il carattere obbligatorio di un campo può anche dipendere dalla natura della fornitura e non solo dall’acquirente, il che significa che un modulo che codifica in modo fisso i requisiti di un solo paese sarà allo stesso tempo troppo rigoroso all’estero e troppo permissivo in patria.
La risposta ingegneristica non è codificare le regole ma instradare per paese. Determinate prima il paese e il tipo di acquirente, poi derivate quali campi sono obbligatori, quali facoltativi e quali vanno nascosti. Mantenete quella derivazione in un unico posto, perché spargere condizioni per paese in un template produce esattamente la deriva che fa comportare un modulo diversamente su due schermate che dovrebbero concordare.
Cosa va storto oltre al modulo?
Una quota sorprendente di difetti di fatturazione non tocca affatto la validazione. Vive in ciò che accade dopo l’invio del modulo.
La numerazione delle fatture è l’esempio classico. Il numero deve essere unico e deve essere stabile. Se viene generato al momento dell’invio da un contatore che viene letto e poi scritto, due invii simultanei possono produrre lo stesso numero, e il duplicato viene scoperto settimane dopo da un team contabile. Se viene rigenerato quando un documento viene ristampato, avete ora due numeri per una sola transazione.
I tentativi ripetuti sono il secondo classico. Un cliente invia, la richiesta va in timeout, il cliente invia di nuovo, ed esistono due fatture per un solo ordine. La soluzione è l’idempotenza: un invio dovrebbe portare una chiave, e un secondo invio con la stessa chiave dovrebbe restituire il primo risultato invece di creare una seconda fattura. Testarlo correttamente significa inviare deliberatamente due volte lo stesso invio e controllare che il conteggio delle fatture sia uno.
Il terzo è la collocazione degli errori. Un fallimento di validazione su un modulo di fatturazione lungo deve dire quale campo è sbagliato e perché, e non deve cancellare ciò che il cliente ha già digitato. Testate con un modulo compilato fino all’ultimo campo e un errore inserito presto in esso, poi confermate che il messaggio di errore punti all’input giusto e che nulla vada perso.
Per gli sviluppatori: la matrice dei casi e le fixture
Costruite la matrice come dati invece che come un mucchio di test scritti a mano, così che aggiungere un paese o un ramo sia una riga e non una riscrittura. Ogni riga dovrebbe portare il tipo di acquirente, il paese, quali campi degli identificatori sono popolati, il requisito atteso per ciascun campo e l’esito atteso. Poi lasciate che un unico corpo di test percorra la matrice, il che mantiene le asserzioni coerenti tra i rami.
Usate record di test inequivocabilmente sintetici. Un test di fatturazione che usa un nome aziendale reale dall’aspetto plausibile invita alla confusione nel momento in cui uno screenshot viene incollato in un ticket, e usare gli identificatori di un’impresa reale in un ambiente di test è un vero rischio legale, non solo disordine. Le entità generate dal generatore di dati aziendali portano nomi e identificatori neutri e palesemente fabbricati che non risolvono a nulla, ed è esattamente ciò di cui ha bisogno una fixture di fatturazione.
Separate anche le responsabilità nelle fixture. Un record per un’impresa nazionale con partita IVA, uno per un’impresa estera senza, uno per una ditta individuale, uno per una persona fisica: quattro record coprono gli assi della matrice e possono essere riutilizzati su ogni modulo del prodotto. Teneteli nel controllo di versione con una nota che dichiari che sono fabbricati, che nessuna attività reale è descritta e che non devono essere usati per aprire conti o emettere documenti reali.
Altre due abitudini accorciano il ciclo di feedback. Validate nell’ordine in cui il cliente compila il modulo invece che nell’ordine in cui i campi sono dichiarati, così il primo errore che l’utente incontra è il primo che può correggere. E registrate una chiave di correlazione per ogni tentativo di invio — la stessa usata per l’idempotenza — così che un rapporto su fatture duplicate possa essere ricondotto alla coppia di richieste che l’ha causato.
I campi testati isolatamente falliscono comunque in combinazione, ed è per questo che la discussione sui formati del numero di partita IVA e quella sulla validazione ID fiscale finiscono entrambe nello stesso punto: controllate la forma localmente, confermate la registrazione ufficialmente e non lasciate mai che la prima sostituisca la seconda.
Passi successivi
Prendete la vostra schermata di fatturazione e scrivete i quattro rami su un foglio di carta, poi percorrete ciascuno con un record aziendale sintetico e annotate ogni campo che vi blocca. I rami che non possono essere completati con dati generati sono quelli che nemmeno i vostri clienti aziendali reali riescono a completare. Quando la matrice funziona, estendetela con un caso transfrontaliero usando un paese di cui non avete mai visto il formato e controllate che il modulo chieda le cose giuste invece di quelle familiari.