I dati aziendali di test sono un’entità commerciale inventata, scritta per intero. Sono un nome di azienda, una forma giuridica, un numero di registrazione, un numero fiscale e un numero di partita IVA, una sede legale, un numero di telefono di contatto e una manciata di campi minori, messi insieme perché il software possa essere esercitato su un record che assomiglia a un’ordinaria società commerciale senza descriverne una che esiste davvero.
Questo articolo spiega a cosa serve realmente un record di questo tipo, perché prendere in prestito i dati di un’azienda reale è un cattivo affare sia sul piano giuridico sia su quello ingegneristico, quali parti di un prodotto ne hanno bisogno e cosa un generatore su questo sito garantisce e non garantisce riguardo al proprio output.
Che cosa sono realmente i dati aziendali di test
Tolto il vocabolario, un record aziendale di test non è altro che un insieme coerente di risposte alle domande che pone un modulo commerciale. Qualcuno sta facendo richiesta per conto di un’organizzazione. L’organizzazione ha un nome e una forma giuridica dichiarata, è registrata da qualche parte, le sono stati assegnati gli identificatori che quel luogo rilascia e ha una sede di attività.
La coerenza è ciò che separa un record utilizzabile da un mucchio di stringhe. Il numero di registrazione appartiene al registro del paese indicato nell’indirizzo, il numero di partita IVA porta il prefisso di quello stesso paese, la forma giuridica è una che la giurisdizione riconosce davvero e il numero di telefono porta il prefisso internazionale corretto. Un record messo insieme campo per campo di solito fallisce esattamente in questo punto, perché ogni campo è stato giudicato da solo.
La provenienza è ciò che separa un record di test da uno reale. Nulla in esso è stato copiato da un’azienda e nulla appartiene a un’azienda. Ha la forma di un’impresa perché un sistema possa elaborarlo, e nessun referente al di fuori del test.
Dove serve davvero a un team questo tipo di record aziendali?
La domanda è più ampia di quanto sembri a prima vista e si concentra attorno a un unico requisito: dare al software input plausibili mentre l’output finisce da qualche parte innocua.
| Situazione | Cosa è impossibile senza record generati |
|---|---|
| Test dei moduli di onboarding | Le regole sui campi obbligatori e sulle lunghezze non possono essere esercitate dall’inizio alla fine |
| Prova di fatturazione | I campi fiscali e di registrazione non possono essere provati su un documento che nessuno riceve |
| Integrazione in sandbox | L’ambiente di test di un partner ha bisogno di una controparte che non sia un cliente reale |
| Ambienti demo e commerciali | Il prodotto sembra incompleto quando ogni record si legge come testo segnaposto |
| Popolamento massivo | I test di volume richiedono molte migliaia di righe che restano comunque plausibili |
| Fixture di regressione | Le asserzioni derivano se lo stesso test produce ogni volta un’azienda diversa |
L’elenco mostra anche perché la forma del record conti più di quanto un sviluppatore si aspetti. Un’integrazione in sandbox viene giudicata dal fatto che la validazione del partner accetti il payload. Una demo viene giudicata dal fatto che un potenziale cliente riesca a leggere la schermata senza notare nulla di strano. Nessuno dei due obiettivi viene servito iniettando gli identificatori di un’azienda reale.
Perché usare i dati di un’azienda reale è la scelta sbagliata?
Perché il numero di registrazione, il numero fiscale e gli amministratori di un’azienda reale sono fatti personali e commerciali che appartengono a qualcun altro, e gli ambienti inferiori sono quelli in cui tendono a esserci i controlli più deboli.
Ne derivano due guasti. Il primo è giuridico e reputazionale. Presentarsi come un’altra impresa è una falsa rappresentazione e, secondo le norme sulla protezione dei dati, i dati di registrazione di un imprenditore individuale più un nome di contatto possono costituire anch’essi dati personali. Spostare quei fatti in un ambiente di sviluppo è un nuovo uso a cui nessuno ha acconsentito. Il secondo è operativo: la copia sopravvive poi nei backup, nei log delle query, negli screenshot incollati nei ticket e sui portatili di tutti coloro che hanno ripristinato il database. L’organizzazione finisce così con più copie dei dati di una sola azienda di quante ne abbia mai avute, in luoghi che nessuno verifica.
C’è un terzo costo, più silenzioso. Un test costruito su una sola azienda reale vede sempre e solo la forma di quell’azienda. I portafogli reali contengono nomi brevi, nomi molto lunghi, e commerciali, caratteri accentati, denominazioni commerciali diverse dal nome registrato ed entità del tutto prive di partita IVA. Un insieme generato può coprire deliberatamente questa varietà, cosa che un record preso in prestito non può fare.
Cosa contiene un record aziendale completo?
Su questo sito, il generatore di dati aziendali di test costruisce l’intera entità in un solo passaggio invece che un campo alla volta. Un record porta quattro gruppi di campi.
- Identità — il nome registrato, la forma giuridica e la descrizione del settore o dell’attività.
- Registrazione e fisco — il numero di registrazione della società, l’identificativo fiscale e il numero di partita IVA dove il paese ne rilascia uno, ciascuno nella forma propria di quel paese.
- Sede legale — via, distretto, città, suddivisione amministrativa, codice postale e paese, secondo le convenzioni reali di indirizzo di quel paese.
- Contatto — un numero di telefono che porta il prefisso internazionale corretto, più dettagli amministrativi associati come la fascia dimensionale o gli indicatori di costituzione che il paese pubblica.
Due proprietà meritano di essere comprese prima di fare affidamento sull’output. La prima è la coerenza interna, come descritto sopra. La seconda è la riproducibilità: l’output è guidato da una chiave d’identità e la stessa chiave con lo stesso paese produce esattamente la stessa azienda ogni volta. La riproducibilità è ciò che rende un record generato utilizzabile all’interno di un test automatico e non solo in una verifica manuale. La questione della coerenza dei campi è in realtà una questione di ordine di generazione, e l’articolo sulle forme giuridiche spiega perché il paese deve essere deciso prima di tutto ciò che ne dipende.
I dati aziendali generati devono sembrare reali?
Devono sembrare ordinari, che è un requisito più debole — e la differenza conta.
Un record palesemente falso è facile da scartare per un lettore, ma anche facile da respingere per una regola di validazione per il motivo sbagliato. Un record che sembra esotico verifica la cosa sbagliata: se ogni nome aziendale generato è una sola sillaba, o se ogni riga dell’indirizzo è la stessa frase segnaposto, il layout non viene mai messo sotto stress e la validazione non scatta mai. I record generati si guadagnano il loro posto quando arrivano nella stessa forma delle richieste reali che il sistema riceverà prima o poi, comprese quelle scomode — nomi legali lunghi, caratteri accentati, denominazioni commerciali diverse dal nome registrato ed entità che legittimamente non hanno partita IVA.
Ordinario non è la stessa cosa di valido nel mondo reale. Un numero di registrazione sintetico della forma giusta non è comunque registrato da nessuna parte. Supererà un controllo di formato e fallirà nel momento in cui un processo consulta il registro che sta dietro. Questa è una caratteristica, non un difetto: i confini dei dati aziendali sintetici sono esattamente ciò che impedisce a un record di test di essere scambiato per uno reale.
Per gli sviluppatori: progettare il record
Modellate il record come campi con dipendenze, non come una tabella piatta di colonne indipendenti. Il paese vincola la forma dell’indirizzo, il registro, il formato dell’identificativo e il prefisso telefonico. La forma giuridica vincola il suffisso del nome e l’insieme degli identificatori che possono esistere. Uno schema che nasconde queste relazioni ammetterà righe incoerenti, per quanto le fixture siano curate.
Tre abitudini prevengono la maggior parte dei danni. Date al record una chiave stabile, così che possa essere rigenerato su richiesta invece di essere copiato tra ambienti. Trattate un identificativo mancante come assente invece di riempire il campo con una stringa plausibile, perché un campo vuoto e un campo sbagliato falliscono in punti molto diversi. E non lasciate mai che un record di test passi in produzione: tenete le entità generate in un database o schema proprio, contrassegnatele a livello di riga se un ambiente condiviso lo impone e tenete i file di fixture stessi etichettati come sintetici.
La nota che accompagna le fixture fa parte del progetto. Dite chiaramente nel file, e in ogni esportazione che lo strumento produce, che queste aziende sono fabbricate per i test, che nessuna attività reale è descritta e che i record non devono essere usati per aprire conti, ottenere licenze, emettere fatture reali o sostituire una controparte effettiva.
Passi successivi
Scegliete un modulo del vostro prodotto che chiede i dati aziendali e compilatelo con un record generato invece che con il testo segnaposto che probabilmente c’è oggi, poi inviatelo due volte con la stessa chiave d’identità e confermate che i due tentativi producano valori identici. Se differiscono, state guardando un generatore che non può sostenere asserzioni automatiche, e l’articolo sul numero di registrazione aziendale spiega cosa chiedere invece. Per i team che popolano un database di staging in grandi volumi, la guida al popolamento copre lo stesso problema su scala.