Caratteristiche, funzionamento e importanza della data preparation nel testing software

Nell’attuale epopea della crescita rivoluzionaria dell’Informazione e della Tecnologia, i tester sperimentano comunemente un ampio consumo di dati di test nel ciclo di vita del test del software.

I tester non solo raccolgono/conservano i dati dalle fonti esistenti, ma generano anche enormi volumi di dati di test per garantire il loro contributo in forte espansione alla qualità nella consegna del prodotto per l’uso nel mondo reale. 

Pertanto, noi tester dobbiamo esplorare, apprendere e applicare continuamente gli approcci più efficienti per la raccolta, la generazione, la manutenzione, l’automazione e la gestione completa dei dati per qualsiasi tipo di test funzionale e non funzionale.

Che cosa sono i dati di test e perché sono importanti

Facendo riferimento a uno studio condotto da IBM nel 2016, la ricerca, la gestione, la manutenzione e la generazione di dati di test comprendono il 30%-60% del tempo dei tester. È una prova innegabile che la preparazione dei dati è una fase di test del software che richiede molto tempo.

Tuttavia, è un dato di fatto in molte discipline diverse che la maggior parte dei data scientist dedica il 50%-80% del tempo di sviluppo del proprio modello nell’organizzazione dei dati. E ora, considerando la legislazione e le informazioni di identificazione personale (PII), il coinvolgimento dei tester è straordinariamente decente nel processo di test.

Oggi, la credibilità e l’affidabilità dei dati dei test sono considerati un elemento senza compromessi per gli imprenditori. I proprietari del prodotto vedono le copie fantasma dei dati di test come la sfida più grande, che riduce l’affidabilità di qualsiasi applicazione in questo momento unico di domanda/richiesta di controllo qualità da parte dei clienti.

Considerando l’importanza dei dati di test, la stragrande maggioranza dei proprietari di software non accetta le applicazioni testate con dati falsi o meno nelle misure di sicurezza.

A questo punto, perché non ci ricordiamo di cosa sono i Test Data? Quando iniziamo a scrivere i nostri casi di test per verificare e convalidare le funzionalità fornite e gli scenari sviluppati dell’applicazione sottoposta al test, abbiamo bisogno di informazioni che vengano utilizzate come input per eseguire i test per identificare e localizzare i difetti.

Inoltre sappiamo che queste informazioni devono essere precise e complete per eliminare i bug. Sono quelli che chiamiamo dati di test. Per renderlo accurato, possono essere nomi, paesi, ecc…, non sensibili, laddove i dati relativi a informazioni di contatto, SSN, anamnesi e informazioni sulla carta di credito sono di natura sensibile.

I dati possono essere in qualsiasi forma come:

• dati di test del sistema
• dati di test SQL
• Dati del test delle prestazioni
• XML test data

Se stai scrivendo casi di test, hai bisogno di dati di input per qualsiasi tipo di test. In pratica, il tester può fornire questi dati di input al momento dell’esecuzione dei test case oppure l’applicazione può prelevare i dati di input richiesti dalle posizioni dei dati predefinite.

I dati possono essere qualsiasi tipo di input per l’applicazione, qualsiasi tipo di file caricato dall’applicazione o voci lette dalle tabelle del database.

La preparazione dei dati di input corretti fa parte di una configurazione di prova. Generalmente, i tester la chiamano preparazione del banco di prova . Nel banco di prova, tutti i requisiti software e hardware vengono impostati utilizzando i valori dei dati predefiniti.

Se non si dispone dell’approccio sistematico per la creazione di dati durante la scrittura e l’esecuzione di test case , è probabile che si perdano alcuni test case importanti. I tester possono creare i propri dati in base alle esigenze di test.

Non fare affidamento sui dati creati da altri tester o sui dati di produzione standard. Crea sempre un nuovo set di dati in base alle tue esigenze.

A volte non è possibile creare un set di dati completamente nuovo per ogni build. In questi casi è possibile utilizzare dati di produzione standard. Ma ricorda di aggiungere/inserire i tuoi set di dati in questo database esistente. Un modo migliore per creare dati è utilizzare i dati di test esistenti e aggiungere i nuovi dati del test case ogni volta che si ottiene lo stesso modulo per il test. In questo modo puoi creare un set di dati completo nel periodo.

Sfide del Test Data Sourcing

Una delle aree nella generazione dei dati di test che i tester considerano è il requisito di approvvigionamento dei dati per una determinata applicazione. Ad esempio, hai oltre un milione di clienti e ne occorrono mille per i test e questi dati campione dovrebbero essere coerenti e rappresentare statisticamente la distribuzione appropriata del gruppo target. In altre parole, dovremmo trovare la persona giusta da testare, che è uno dei metodi più utili per testare i casi d’uso.

E questi dati campione dovrebbero essere coerenti e rappresentare statisticamente la distribuzione appropriata del gruppo target. In altre parole, dovremmo trovare la persona giusta da testare, che è uno dei metodi più utili per testare i casi d’uso.

Inoltre, ci sono alcuni vincoli ambientali nel processo. Uno di questi è la mappatura delle politiche PII. Poiché la privacy è un ostacolo significativo, i tester devono classificare i dati PII.

Gli strumenti di gestione dei dati di test sono progettati per risolvere il problema menzionato. Questi strumenti suggeriscono politiche basate sugli standard/catalogo che hanno. Tuttavia, non è un esercizio molto sicuro. Offre ancora l’opportunità di controllare ciò che si sta facendo.

Per stare al passo con l’affrontare le sfide attuali e anche future, dovremmo sempre porre domande come Quando/dove dovremmo iniziare la conduzione di TDM? Cosa dovrebbe essere automatizzato? Quanti investimenti dovrebbero stanziare le aziende per i test nelle aree dello sviluppo continuo delle competenze delle risorse umane e dell’uso dei nuovi strumenti TDM? Dovremmo iniziare i test con test funzionali o non funzionali? E domande molto più probabili come loro.

Alcune delle sfide più comuni della Test Data Sourcing sono menzionate di seguito:

• I team potrebbero non disporre di conoscenze e competenze adeguate sugli strumenti di generazione dei dati di test
• La copertura dei dati dei test è spesso incompleta
• Meno chiarezza nei requisiti dei dati che coprono le specifiche del volume durante la fase di raccolta
• I team di test non hanno accesso alle origini dati
• Ritardo nel dare accesso ai dati di produzione ai tester da parte degli sviluppatori
• I dati dell’ambiente di produzione potrebbero non essere completamente utilizzabili per i test in base agli scenari aziendali sviluppati
• Potrebbero essere necessari grandi volumi di dati in un breve periodo di tempo
• Dipendenze/combinazioni di dati per testare alcuni scenari aziendali
• I tester impiegano più tempo del necessario per comunicare con architetti, amministratori di database e BA per la raccolta dei dati
• Per lo più i dati vengono creati o preparati durante l’esecuzione del test
• Molteplici applicazioni e versioni dei dati
• Cicli di rilascio continui in diverse applicazioni
• Legislazione sulla gestione delle informazioni di identificazione personale (PII)

Sul lato della scatola bianca del test dei dati, gli sviluppatori preparano i dati di produzione. È qui che la necessità del QA di lavorare in contatto con gli sviluppatori per promuovere la copertura dei test di UAT. Una delle maggiori sfide è incorporare tutti i possibili scenari (test case al 100%) con ogni singolo possibile caso negativo.

In questa sezione abbiamo parlato delle sfide dei dati di test. Puoi aggiungere più sfide man mano che le hai risolte di conseguenza. Successivamente, esploriamo diversi approcci alla gestione della progettazione e gestione dei dati di test.

Strategie per la Test Data Preparation

Sappiamo dalla pratica quotidiana che gli attori del settore dei test sperimentano continuamente modi e mezzi diversi per migliorare gli sforzi di test e, soprattutto, la sua efficienza in termini di costi. Nel breve corso dell’evoluzione dell’Informazione e della Tecnologia, abbiamo visto che quando gli strumenti sono incorporati negli ambienti di produzione/test, il livello di output è notevolmente aumentato.

Quando si parla di completezza e copertura completa dei test, dipende principalmente dalla qualità dei dati. Poiché il test è la spina dorsale per ottenere la qualità del software, i dati del test sono l’elemento centrale nel processo di test.

Creazione di file flat basati sulle regole di mappatura. È sempre pratico creare un sottoinsieme dei dati necessari dall’ambiente di produzione in cui gli sviluppatori hanno progettato e codificato l’applicazione. In effetti, questo approccio riduce gli sforzi dei tester nella preparazione dei dati e massimizza l’uso delle risorse esistenti per evitare ulteriori spese.

In genere, dobbiamo creare i dati o almeno identificarli in base al tipo di requisiti che ogni progetto ha all’inizio.

Possiamo applicare le seguenti strategie gestendo il processo di TDM:

1. Dati dall’ambiente di produzione
2. Recupero di query SQL che estraggono dati dai database esistenti del Cliente
3. Strumenti di generazione dati automatizzati

I tester devono supportare la loro prova con dati completi considerando gli elementi come mostrato nella figura-3 qui. I restanti nei team di sviluppo agile generano i dati necessari per l’esecuzione dei loro casi di test. Quando parliamo di casi di test, intendiamo casi per vari tipi di test come la scatola bianca, la scatola nera, le prestazioni e la sicurezza.

A questo punto, sappiamo che i dati per i test delle prestazioni dovrebbero essere in grado di determinare la velocità con cui il sistema risponde a un determinato carico di lavoro per essere molto vicini al volume di dati reale o attivo con una copertura significativa.

Per i test white box, gli sviluppatori preparano i dati richiesti per coprire il maggior numero possibile di rami, tutti i percorsi nel codice sorgente del programma e l’Application Program Interface (API) negativa.

Alla fine, possiamo dire che tutti coloro che lavorano nel ciclo di vita dello sviluppo del software (SDLC) come analisti funzionali, sviluppatori, tester e product owner dovrebbero essere ben coinvolti nel processo di preparazione dei dati di test. Può essere uno sforzo congiunto. E ora passiamo al problema dei dati di test danneggiati.

Dati di test danneggiati/corrotti

Prima di eseguire qualsiasi test case sui nostri dati esistenti, dobbiamo assicurarci che i dati non siano danneggiati/obsoleti e che l’applicazione sottoposta al test possa leggere l’origine dati. In genere, quando più di un tester che lavora contemporaneamente su diversi moduli di un UAT nell’ambiente di test, le possibilità che i dati vengano danneggiati è così alta.

Nello stesso ambiente, i tester modificano i dati esistenti in base alle loro necessità/requisiti dei test case. Per lo più, quando i tester hanno finito con i dati, lasciano i dati così come sono. Non appena il tester successivo raccoglie i dati modificati ed esegue un’altra esecuzione del test, esiste la possibilità che quel particolare test fallisca che non sia l’errore o il difetto del codice.

Nella maggior parte dei casi, questo è il modo in cui i dati vengono danneggiati e/o obsoleti, causando un errore. Per evitare e ridurre al minimo le possibilità di discrepanza dei dati, possiamo applicare le soluzioni come di seguito. E, naturalmente, puoi aggiungere più soluzioni alla fine di questo tutorial nella sezione commenti.

1. Avere il backup dei tuoi dati
2. Riporta i dati modificati al loro stato originale
3. Ripartizione dei dati tra i tester
4. Tieni aggiornato l’amministratore del data warehouse per qualsiasi modifica/modifica dei dati

Come mantenere intatti i tuoi dati in qualsiasi ambiente di test?

Il più delle volte, molti tester sono responsabili del test della stessa build. In questo caso, più di un tester avrà accesso a dati comuni e cercherà di manipolare il set di dati comune in base alle proprie esigenze.

Se hai preparato i dati per alcuni moduli specifici, il modo migliore per mantenere intatto il tuo set di dati è conservare copie di backup degli stessi.

Test Data per il Performance Test Case

I test delle prestazioni richiedono un set di dati molto grande. A volte la creazione manuale dei dati non rileverà alcuni bug sottili che potrebbero essere rilevati solo dai dati effettivi creati dall’applicazione in fase di test. Se desideri dati in tempo reale, che è impossibile creare manualmente, chiedi al tuo lead/manager di renderli disponibili dall’ambiente live.

Questi dati saranno utili per garantire il corretto funzionamento dell’applicazione per tutti gli input validi.

Quali sono i dati di test ideali?

Si può dire che i dati siano l’ideale se per la dimensione minima dei dati si impostano tutti gli errori dell’applicazione da identificare. Prova a preparare i dati che incorporino tutte le funzionalità dell’applicazione, ma senza superare i limiti di tempo e di costo per la preparazione dei dati e l’esecuzione dei test.

Come preparare i dati che garantiranno la massima copertura del test?

Progetta i tuoi dati considerando le seguenti categorie:

1. Nessun dato: esegui i casi di test su dati vuoti o predefiniti. Verificare se vengono generati messaggi di errore corretti.
2. Set di dati valido: crearlo per verificare se l’applicazione funziona secondo i requisiti e se i dati di input validi sono stati salvati correttamente nel database o nei file.
3. Set di dati non valido: preparare il set di dati non valido per verificare il comportamento dell’applicazione per valori negativi, input di stringhe alfanumeriche.
4. Formato dati illegale: crea un set di dati in formato dati illegale. Il sistema non dovrebbe accettare dati in un formato non valido o illegale. Verificare inoltre che vengano generati messaggi di errore corretti.
5. Set di dati sulle condizioni al contorno: set di dati contenente dati fuori dall’intervallo. Identifica i casi limite dell’applicazione e prepara il set di dati che coprirà le condizioni al contorno inferiori e superiori.
6. Il set di dati per le prove di prestazioni, carico e stress: questo set di dati dovrebbe essere di grande volume.

In questo modo, la creazione di set di dati separati per ciascuna condizione di test garantirà la copertura completa del test.

Dati per il Black Box Testing

I tester software eseguono test di integrazione, test di sistema e test di accettazione, noti anche come test della scatola nera. In questo metodo di test, i tester non hanno alcun lavoro nella struttura interna, nel design e nel codice dell’applicazione sottoposta al test.

Lo scopo principale dei tester è identificare e localizzare gli errori. In questo modo, applichiamo test funzionali o non funzionali utilizzando diverse tecniche di test della scatola nera.

A questo punto, i tester hanno bisogno dei dati del test come input per eseguire e implementare le tecniche del test della scatola nera. E i tester dovrebbero preparare i dati che esamineranno tutte le funzionalità dell’applicazione senza superare il costo e il tempo indicati.

Possiamo progettare i dati per i nostri casi di test considerando categorie di set di dati come nessun dato, dati validi, dati non validi, formato dati illegale, dati di condizioni al contorno, partizione di equivalenza, tabella di dati decisionali, dati di transizione di stato e dati di casi d’uso. Prima di entrare nelle categorie dei set di dati, i tester avviano la raccolta dei dati e l’analisi delle risorse esistenti dell’applicazione sottoposta a tester (AUT).

Secondo i punti menzionati in precedenza su come mantenere il tuo data warehouse sempre aggiornato, dovresti documentare i requisiti dei dati a livello di test case e contrassegnarli come utilizzabili o non riutilizzabili quando crei i tuoi test case. Ti aiuta a chiarire e documentare fin dall’inizio i dati richiesti per il test a cui potresti fare riferimento per un ulteriore utilizzo in seguito.

Proprietà di un buon dato di test

In qualità di tester, devi testare il modulo “Risultati degli esami” del sito web di un’università. Considera che l’intera applicazione è stata integrata ed è nello stato “Pronto per il test”. Il “Modulo esame” è collegato ai moduli “Iscrizione”, “Corsi” e “Finanza”.

Si supponga di disporre di informazioni adeguate sull’applicazione e di aver creato un elenco completo di scenari di test. Ora devi progettare, documentare ed eseguire questi casi di test. Nella sezione “Azioni/Passi” o “Ingressi del test” dei casi di test, dovrai menzionare i dati accettabili come input per il test.

I dati menzionati nei casi di test devono essere selezionati correttamente. L’accuratezza della colonna “Risultati effettivi” del documento del test case dipende principalmente dai dati del test. Quindi, il passaggio per preparare i dati del test di input è significativamente importante.

Proprietà di buoni dati di test

I dati del test devono essere selezionati con precisione e devono possedere le seguenti quattro qualità:

Realistico

Per realistico, significa che i dati dovrebbero essere accurati nel contesto di scenari di vita reale. Ad esempio, per testare il campo ‘Età’, tutti i valori devono essere positivi e 18 o superiore. È abbastanza ovvio che i candidati all’ammissione all’università hanno generalmente 18 anni (questo potrebbe essere definito diversamente in termini di requisiti aziendali).

Se il test viene eseguito utilizzando i dati di test realistici, renderà l’app più robusta poiché la maggior parte dei possibili bug può essere catturata utilizzando dati realistici. Un altro vantaggio dei dati realistici è la loro riutilizzabilità che ci fa risparmiare tempo e fatica per creare nuovi dati ancora e ancora.

Quando si parla di dati realistici, vorrei presentarvi il concetto di set di dati d’oro. Un set di dati d’oro è quello che copre quasi tutti i possibili scenari che si verificano nel progetto reale. Utilizzando il GDS, possiamo fornire la massima copertura dei test. Uso il GDS per eseguire test di regressione nella mia organizzazione e questo mi aiuta a testare tutti i possibili scenari che possono verificarsi se il codice va nella casella di produzione.

Sul mercato sono disponibili molti strumenti per la generazione di dati di test che analizzano le caratteristiche delle colonne e le definizioni utente nel database e, sulla base di questi, generano dati di test realistici per te. Alcuni dei buoni esempi degli strumenti che generano dati per il test del database sono DTM Data Generator , SQL Data Generator e Mockaroo .

Praticamente valido

Questo è simile a realistico ma non lo stesso. Questa proprietà è più correlata alla logica aziendale dell’AUT, ad esempio il valore 60 è realistico nel campo dell’età ma praticamente non valido per un candidato di Laurea o addirittura Master. In questo caso, un intervallo valido sarebbe 18-25 anni (questo potrebbe essere definito nei requisiti).

Versatile per coprire gli scenari

Possono esserci diverse condizioni successive in un unico scenario, quindi scegli i dati in modo oculato per coprire gli aspetti massimi di un singolo scenario con il set minimo di dati, ad esempio durante la creazione dei dati del test per il modulo dei risultati, non considerare solo il caso degli studenti regolari che stanno completando senza problemi il loro programma. Prestare attenzione agli studenti che stanno ripetendo lo stesso corso e appartengono a semestri diversi o anche programmi diversi.

Dati eccezionali (se applicabile/richiesto)

Ci possono essere alcuni scenari eccezionali che si verificano meno frequentemente ma richiedono grande attenzione quando si verificano, ad esempio problemi relativi agli studenti disabili.

Tecniche di preparazione dei dati di test

Abbiamo brevemente discusso le proprietà importanti dei dati di test e ha anche spiegato come la selezione dei dati di test sia importante durante l’esecuzione del test del database. Ora discutiamo le ‘ tecniche per preparare i dati di test ‘ .

Esistono solo due modi per preparare i dati del test:

InseriRE nuovi dati

Ottieni un DB pulito e inserisci tutti i dati come specificato nei tuoi casi di test. Una volta inseriti tutti i dati richiesti e desiderati, inizia a eseguire i test case e riempi le colonne “Passato/Non riuscito” confrontando “Risultato effettivo” con “Risultato previsto”. Sembra semplice, vero? Ma aspetta, non è così semplice.

Poche preoccupazioni essenziali e critiche sono le seguenti:

• Un’istanza vuota del database potrebbe non essere disponibile
• I dati di test inseriti potrebbero non essere sufficienti per testare alcuni casi come il test delle prestazioni e del carico.
• L’inserimento dei dati di test richiesti in un DB vuoto non è un compito facile a causa delle dipendenze delle tabelle del database. A causa di questa inevitabile restrizione, l’inserimento dei dati può diventare un compito difficile per il tester.
• L’inserimento di dati di test limitati (solo in base alle esigenze del test case) potrebbe nascondere alcuni problemi che potrebbero essere riscontrati solo con l’  ampio set di dati.
• Per l’inserimento dei dati potrebbero essere necessarie complesse query e/o procedure e per questo sarebbe necessaria una sufficiente assistenza o aiuto da parte degli sviluppatori del DB.

I cinque problemi sopra menzionati sono gli svantaggi più critici e più evidenti di questa tecnica per la preparazione dei dati di test. Ma ci sono anche alcuni vantaggi:

• L’esecuzione dei TC diventa più efficiente poiché il DB dispone solo dei dati richiesti.
• L’isolamento dei bug non richiede tempo poiché nel DB sono presenti solo i dati specificati nei casi di test.
• Meno tempo necessario per il test e il confronto dei risultati.
• Processo di prova privo di ingombri

ScegliERE un sottoinsieme di dati di TEST dai dati DB effettivi

Questa è una tecnica fattibile e più pratica per la preparazione dei dati di test. Tuttavia, richiede solide competenze tecniche e una conoscenza dettagliata di DB Schema e SQL. In questo metodo, è necessario copiare e utilizzare i dati di produzione sostituendo alcuni valori di campo con valori fittizi. Questo è il miglior sottoinsieme di dati per i test in quanto rappresenta i dati di produzione. Ma questo potrebbe non essere sempre fattibile a causa di problemi di sicurezza e privacy dei dati.

Approcci alla generazione dei dati di test:

• Generazione manuale dei dati del test: in questo approccio, i dati del test vengono inseriti manualmente dai tester secondo i requisiti del test case. È un tempo che richiede il processo e anche soggetto a errori.
• Generazione automatizzata dei dati di test: questa operazione viene eseguita con l’aiuto di strumenti di generazione dei dati. Il vantaggio principale di questo approccio è la sua velocità e precisione. Tuttavia, ha un costo maggiore rispetto alla generazione manuale dei dati di test.
• Iniezione di dati back-end : questa operazione viene eseguita tramite query SQL. Questo approccio può anche aggiornare i dati esistenti nel database. È veloce ed efficiente ma dovrebbe essere implementato con molta attenzione in modo che il database esistente non venga danneggiato.
• Utilizzo di strumenti di terze parti : sul mercato sono disponibili strumenti che prima comprendono gli scenari di test e quindi generano o iniettano dati di conseguenza per fornire un’ampia copertura di test. Questi strumenti sono accurati in quanto sono personalizzati in base alle esigenze aziendali. Ma sono piuttosto costosi.

Infine, esistono 4 approcci per testare la generazione dei dati:

1. Manuale,
2. automazione,
3. iniezione di dati di back-end,
4. e strumenti di terze parti.

Ogni approccio ha i suoi pro e contro. Dovresti selezionare l’approccio che soddisfa le tue esigenze di business e di test.

Conclusioni

La creazione di dati di test software completi in conformità con gli standard del settore, la legislazione e i documenti di base del progetto intrapreso è tra le responsabilità principali dei tester. Più gestiamo in modo efficiente i dati di test, più possiamo distribuire prodotti ragionevolmente privi di bug per utenti del mondo reale.

La gestione dei dati di test (TDM) è il processo basato sull’analisi delle sfide e sull’introduzione dell’applicazione dei migliori strumenti e metodi per affrontare bene i problemi identificati senza compromettere l’affidabilità e la copertura completa dell’output finale (prodotto).

Abbiamo sempre bisogno di porre domande per la ricerca di metodi innovativi e più convenienti per l’analisi e la selezione dei metodi di test, compreso l’uso di strumenti per la generazione dei dati. È ampiamente dimostrato che dati ben progettati ci consentono di identificare i difetti dell’applicazione sottoposta a test in ogni fase di un SDLC multifase.

Dobbiamo essere creativi e partecipare con tutti i membri all’interno e all’esterno del nostro team agile. Condividi il tuo feedback, esperienza, domande e commenti in modo da poter continuare le nostre discussioni tecniche in corso per massimizzare il nostro impatto positivo sull’UAT gestendo i dati.

La preparazione dei dati di test adeguati è una parte fondamentale della “configurazione dell’ambiente di test del progetto”. Non possiamo semplicemente perdere il test case dicendo che i dati completi non erano disponibili per il test. Il tester dovrebbe creare i propri dati di test aggiuntivi ai dati di produzione standard esistenti. Il tuo set di dati dovrebbe essere l’ideale in termini di costi e tempo.

Sii creativo, usa le tue capacità e i tuoi giudizi per creare set di dati diversi invece di fare affidamento su dati di produzione standard.