Chiedi a qualsiasi team di tecnici da dove proviene la massa di dati nell'ambiente di approvazione. In molte aziende la risposta onesta è: da una copia di produzione. Qualcuno, ad un certo punto, ha replicato la base reale per un ambiente di test, perché era il modo più rapido per farla assomigliare alla realtà. E quella copia è rimasta lì, usata e copiata di nuovo, semestre dopo semestre.
Questa abitudine risolve un problema e ne crea uno più grande. Risolve il realismo, perché i dati di produzione sono, per definizione, realistici. Ma crea un’enorme esposizione alla privacy, perché i dati personali dei clienti reali ora circolano in ambienti meno protetti, accessibili a più persone, in più copie, con meno controllo. È uno dei rischi più comuni e sottovalutati che incontro.
I dati sintetici risolvono questa equazione in modo pulito: generi massa che si comporta come la produzione, senza che contenga un solo cliente reale.
Perché copiare la produzione è un problema
Vale la pena nominare i rischi perché solitamente vengono trattati come un costo invisibile fino al giorno in cui diventano un incidente.
Il rischio per la privacy è il più evidente. Ai sensi della LGPD, i dati personali in un ambiente di approvazione sono dati personali soggetti agli stessi obblighi. Ogni sviluppatore con accesso, ogni backup di quell'ambiente, ogni integrazione di test che tocca quella base, tutto questo è superficie di esposizione. Una fuga di notizie durante l'approvazione fa male quanto una fuga di notizie durante la produzione, con l'ulteriore vantaggio che nessuno ha prestato attenzione.
Il rischio per la sicurezza ne deriva. Gli ambienti di test spesso hanno controlli più flessibili, credenziali condivise e meno monitoraggio. Mettere dati reali in questo contesto significa mantenere qualcosa di prezioso nella stanza con la porta aperta.
Esiste anche un rischio operativo. La copia di produzione porta ciò che ha la produzione e la produzione raramente ha il caso limite che devi testare. Ti ritroverai con una base ampia, sensibile e tuttavia incompleta per gli scenari che contano di più.
Cosa offre la massa sintetica
Generare dati di test invece di copiarli cambia il gioco in diverse dimensioni.
Il primo è la sicurezza attraverso la costruzione. Se i dati non provengono mai da una persona reale, non ci sono dati personali da perdere. L’ambiente di approvazione smette di essere un deposito di rischi e diventa quello che dovrebbe essere, uno spazio per esercitare il software. Questo è l'aspetto della privacy che approfondirò in dati sintetici e privacy.
Il secondo è il controllo sugli scenari. Con la massa sintetica generi appositamente ciò che devi testare: il cliente con un nome enorme che rompe il layout, il valore negativo, la data non valida, l'ordine con mille articoli, l'utente senza storico. Questi casi limite sono i luoghi in cui vivono i bug e la produzione raramente li distribuisce su un piatto da portata.
Il terzo è il volume su richiesta. Hai bisogno di dieci milioni di record per un test di carico? Generare. Hai bisogno di una base snella per eseguire rapidamente la suite in cantiere? Genera più piccolo. Smetti di dipendere dalla dimensione della produzione e inizi a definire la dimensione richiesta dal test.
Il quarto è la stabilità. I dati di produzione cambiano continuamente, il che rende i test fragili e difficili da riprodurre. La massa sintetica generata da regole conosciute è deterministica quando lo si desidera, il che fornisce test che falliscono per la giusta ragione, non perché un dado è cambiato sotto di essi.
Il realismo è il requisito che non può mancare
La massa sintetica è utile solo se esercita gli stessi percorsi di codice che eserciterebbero i dati reali. I dati sintetici ingenui, chiamati da tutti "Test Test" con lo stesso CPF non valido, non testano quasi nulla. Passa attraverso le convalide che i dati reali fallirebbero e nasconde i bug che appaiono solo con varietà.
Realismo, qui, significa rispettare la struttura e le regole del dominio. CPF che supera la convalida delle cifre. codice postale esistente. Date coerenti tra loro, con registrazione prima del primo acquisto. Distribuzioni reali, con il giusto mix di clienti attivi e inattivi, ordini grandi e piccoli, casi comuni e rari. Rapporti che si mantengono, con l'ordine che punta al cliente che esiste e al prodotto che esiste.
Più il tuo sistema dipende da queste regole, più il pubblico dovrà rispettarle affinché il test sia valido. Per il QA, il livello di fedeltà richiesto spesso riguarda più la struttura e le regole che la riproduzione della distribuzione statistica fine. È necessario che i dati siano validi e vari, non che replichino il comportamento aggregato del database con precisione scientifica.
##Come adottare senza diventare un progetto eterno
La tentazione è quella di trattare la generazione di dati sintetici come una grande piattaforma. Per il QA, consiglio il percorso opposto: iniziare in piccolo e dimostrare rapidamente il valore.
Scegli un sistema con problemi evidenti, preferibilmente uno che attualmente si basa sulla copia di produzione e genera la maggior parte di un flusso principale. Sentire il vantaggio in un caso reale è più convincente di qualsiasi pianificazione a lungo termine.
Modella le regole del dominio insieme a chi conosce il business. La qualità di massa deriva dall'acquisizione efficace dei vincoli dei dati, quindi il valore risiede in questa conversazione tra QA, sviluppo e business.
Generatori di versioni come codice. La ricetta che dà vita all'impasto è parte del progetto, va rivista, testata ed evoluta come ogni altro componente. Ciò collega la strategia dei dati alla strategia di test, un argomento che tratto in test automatizzati.
Includi casi limite di proposito. Il vero vantaggio della massa sintetica rispetto alla copia di produzione è la capacità di generare uno scenario difficile. Non sprecarlo semplicemente replicando il caso felice.
Integrazione nella pipeline. La massa generata su richiesta nel flusso di integrazione continua è ciò che rende i test riproducibili ed economici da eseguire. I dati di test che risiedono in un database statico condiviso invecchiano e creano problemi.
Il guadagno che vede il leader
Per chi decide, il discorso è semplice. Sostituire la copia di produzione con la massa sintetica rimuove una delle maggiori esposizioni alla privacy dell'azienda, riduce la superficie di sicurezza degli ambienti di test e, allo stesso tempo, accelera il QA, perché il team inizia a generare lo scenario di cui ha bisogno invece di cercarlo in un database che potrebbe anche non averlo.
È uno di quei rari casi in cui sicurezza e velocità vanno di pari passo. In generale, un maggiore controllo comporta una maggiore lentezza. Ecco, smettendo di portare dati reali ovunque, diventi più sicuro e più agile allo stesso tempo.
Questo è l'uso di dati sintetici con il rendimento più rapido e il rischio più basso da adottare. La lealtà richiesta è gestibile, il guadagno in termini di privacy è immediato e l'impatto sulla vita quotidiana della squadra si vede già nelle prime settimane.
Se la tua azienda copia ancora la produzione per i test, questo è il punto di partenza. Scegli un flusso, genera la massa, manda in pensione la copia. L'ambiente di approvazione che disattivi oggi è un incidente che non avrai più domani.
Leggi anche
- Dati sintetici e privacy: formarsi e testare senza esporre i dati personali
- Cosa sono i dati sintetici e perché sono importanti per i leader
- Dati sintetici: i rischi e i limiti che nessuno mette nella slide di vendita
- Big Data nei prodotti digitali: buone pratiche nella pratica
- Dati sintetici per addestrare l'IA: vantaggi reali e rischio di collasso del modello
- Crittografia dati