Che cos’è, come funziona e importanza del early testing per il software

Che cos’è l’Early Testing ?

Il test del software dovrebbe iniziare all’inizio del ciclo di vita dello sviluppo del software. Questo aiuta a catturare ed eliminare i difetti nelle prime fasi di SDLC, ad esempio la raccolta dei requisiti e le fasi di progettazione. Un inizio anticipato del test aiuta a ridurre il numero di difetti e, in definitiva, i costi di rilavorazione.

Di seguito vengono spiegati i vari aspetti dell’Early Testing (in italiano test precoci o test in anticpo) che aiuterebbero i responsabili della qualità e i lead durante lo sviluppo o l’elaborazione del documento della strategia di test in SDLC.

L’adozione del test anticipato comporterà immensamente la consegna di successo di un prodotto di qualità.

Introduzione al testing

Per una determinata versione di software o sistema o prodotto in SDLC, esistono varie metodologie o strategie ben definite per la maggior parte dei seguenti principi di test.

• Che cos’è il test?
• Perché testare?
• Cosa testare?
• Come testare?

Tuttavia, alcune delle domande più persistenti che molti lettori, tester, lead e responsabili del controllo qualità vorrebbero porre o su cui vorrebbero ottenere maggiore chiarezza includono:

• Quando iniziare il test in una versione software o Quando dovrebbe iniziare il test in un progetto?
• Quando iniziare il test e quando interrompere il test?
• Perché i test dovrebbero iniziare presto in SDLC?
• Che cos’è un test iniziale nello sviluppo del software?

Perché testare in anticipo in SDLC?

Discutiamo di alcuni eventi e attività che fanno parte del test.

Di solito, il team di gestione del programma assegna un Program Manager (PM) a una determinata versione software oa un progetto. Il PM in collaborazione con tutte le parti interessate, inclusi i team di marketing, sviluppo, controllo qualità e supporto, presenta un programma di rilascio

In questo tutorial, ho scelto il programma di rilascio trimestrale utilizzando il modello Waterfall per spiegare in dettaglio i concetti di test iniziali .

Software Release Testing Schedule

La maggior parte delle organizzazioni segue ancora i tradizionali modelli Time Based Release (TBR) in cui le versioni del software o del prodotto sono pianificate per la consegna trimestrale, semestrale o annuale.

Prevalentemente, il modello Waterfall viene utilizzato per l’esecuzione di tali versioni del software. In alcuni casi, per un ciclo di rilascio più breve, viene adottato il modello Agile/Scrum.

Impatto di difetti critici o PRIORITà elevata

Principalmente, durante il processo di Test, è previsto che

• Difetti critici o di gravità elevata devono essere identificati e registrati dai tester.
• Gli sviluppatori dovranno correggere questi difetti.
• Successivamente, i tester dovranno verificare le correzioni.

In secondo luogo, è ampiamente riconosciuto da molte organizzazioni di ingegneria del prodotto e del software che correggere e verificare un’elevata gravità o bug critici in un numero molto elevato è

• Richiede tempo
• Hogging delle risorse (umano + macchina)
• Incline a collaterali, la correzione di bug critici riguarda principalmente gran parte del codice, comprese le aree di intersezione.

Infine, se viene rilevato un numero elevato di bug critici durante la fine di un determinato rilascio, si verifica uno o più dei seguenti sviluppi negativi.

• Elevata probabilità di estensione del ciclo di test.
• Elevata probabilità di mancato rispetto della scadenza del rilascio.
• Una caratteristica particolare che ha un gran numero di difetti potrebbe dover essere estratta da quella particolare versione.
• Impegni del cliente mancati.

E gli altri difetti?

Ci sono difetti di media e bassa priorità che verranno identificati e registrati dai Tester. Anche questi devono essere gestiti in modo appropriato dal team di sviluppo e QA. Quindi, nel complesso, è un esercizio voluminoso.

È risaputo che nessuna quantità di test può portare alla luce tutti i difetti di un Prodotto Software o del Sistema. Ciò significa che, in pratica, non c’è fine ai test né il prodotto è privo di difetti.

Tuttavia, dal punto di vista della ‘ Serviceability ‘ in un modello competitivo e Time To Market (TTM), è necessario rompere la mentalità tipica per portare alla luce i massimi difetti all’inizio di un ciclo di rilascio, in particolare l’identificazione di difetti critici e di alta gravità.

Qualsiasi o tutto quanto sopra avrà un impatto negativo sull’attività dell’Organizzazione. In questo contesto, l’adozione di ” Early Testing ” come attività di test separata sarà vantaggiosa per la gestione complessiva dell’SDLC per un determinato progetto o rilascio.

La portata dello sforzo di test precoce

Poiché stiamo introducendo Testing Early come una nuova attività da tenere traccia esclusivamente durante il corso dell’esecuzione del test, si consiglia di esercitarsi nell’ambito dello sforzo di test come spiegato di seguito:

• L’intero programma di rilascio del progetto o del software viene approvato e reso disponibile a tutte le parti interessate.
• Il documento della Strategia di Test Globale è sviluppato, riesaminato e approvato da tutte le parti interessate.
• Le caratteristiche ad alta, media e bassa priorità da testare sono ben documentate.
• I Piani di Test e i Test Case per tutte le Funzionalità vengono sviluppati, riesaminati e approvati da tutte le parti interessate.
• Tutti i piani di test e i casi di test vengono caricati in un repository centrale per tenere traccia dell’esecuzione dei test.
• Tutte le risorse umane, le attrezzature dell’infrastruttura e gli strumenti sono disponibili per impostare i banchi di prova e per eseguire i piani di prova.

Cosa testare in anticipo?

Approccio

• Prendiamo un esempio della versione XYZ con 3 funzioni A, B e C con priorità alta, 10 funzioni con priorità media e 15 funzioni secondarie (o priorità bassa).
• Le caratteristiche ad alta priorità sono quelle che generano entrate elevate e/o conformità agli standard e/o recupero della concorrenza e/o miglioramento della concorrenza e tutte queste cose.
• Le funzionalità ad alta priorità di solito implicano una codifica complessa, un gran numero di nuove righe di codice aggiunte.
• Un gran numero di nuove righe di codice può anche significare un’alta probabilità di aree di intersezione.
• Di solito, le funzionalità ad alta priorità e/o le funzionalità che hanno un numero elevato di nuove righe di codice sono i migliori candidati per il test anticipato.
• Non è necessario che sia sviluppato un piano di test separato per l’attività di test precoce.
• I responsabili del controllo qualità o i tester insieme ai responsabili dello sviluppo o alle PMI (esperti in materia) devono discutere e concordare la copertura del codice/test per questa attività di test.
• Identifica i casi di test ad alta priorità appropriati e anche alcuni casi di test a priorità media se ritieni che sia necessario da ciascuna delle funzionalità Piani di test A, B e C.
• Una volta identificate le caratteristiche e i sottoinsiemi appropriati dei casi di test, assicurarsi che siano tracciati utilizzando lo strumento di monitoraggio dei test adottato dall’Organizzazione.

Suggerimento: la collaborazione è fondamentale! Durante l’attività di Early Test, sia il team di sviluppo che quello di controllo qualità devono collaborare strettamente per assicurarsi che gli obiettivi prefissati siano raggiunti con risultati di qualità.

Start e Exit con l’Early Test

È importante che sia il team di sviluppo che quello di controllo qualità facciano un brainstorming e accettino tutti gli approcci dell’intera attività di test precoce, comprese le date di inizio e di uscita, in modo che tutti siano sulla stessa pagina.

Criteri di ingresso per l’inizio

• Percentuale di completamento del test di integrazione
• Numero di bug aperti
• Nessun blocco per avviare il test anticipato

FasI di attività

• Monitoraggio dei progressi
• Il numero di codice cade durante questo test
• Approccio alla correzione dei bug
• Approccio alla verifica dei bug
• Registra i risultati di questo test

Criteri di uscita

• Attività di trasferimento alla fase successiva di test (solitamente test delle funzionalità).
• Risoluzione di bug irrisolti rilevati durante l’Early Test.
• Risoluzione di eventuali bloccanti per la successiva fase di Test.
• Pubblica i primi risultati dei test.

Pro e contro

Ogni nuova iniziativa o attività ha i suoi pregi e difetti.

Esploriamo i pro ei contro di questo approccio di test.

Pro

• Ideale per il modello Waterfall.
• Aiuta a scoprire bug critici all’inizio del ciclo di test.
• Identificazione di bug critici all’inizio di un ciclo di rilascio.
• Aiuta il team di sviluppo a stabilizzare il codice in anticipo.
• Aiuta a ridurre al minimo le garanzie dovute a correzioni di bug.
• Aiuta il team di sviluppo a identificare in dettaglio le vulnerabilità nelle aree di intersezione all’inizio del ciclo di rilascio.
• Il team di gestione può prendere decisioni aziendali appropriate con la dovuta diligenza su bug critici irrisolti in quella particolare versione o progetto.
• Aiuta ad estendere la copertura del test e a pedalare in modo efficace.
• Aiuta a distribuire le risorse di sviluppo e test in modo efficiente ed efficace.

contro

• Non ideale per il modello Agile/Scrum. Tuttavia, tali modelli possono adottare Early Test in Sprint con opportuni tweaking.
• C’è una possibilità di riduzione dei test di integrazione da parte del team di sviluppo.

Conclusioni

I clienti o gli utenti finali acquistano o adottano un prodotto di manutenzione o un sistema o una soluzione. La convalida di un software in esecuzione su tale sistema o prodotti per la sua funzionalità è il requisito principale

Componenti chiave dei Principi di verifica come Perché testare? Che cos’è il test? Cosa testare? Come testare? sono per lo più ben definiti e compresi. Tuttavia, ci sono alcune domande persistenti che continuano a sorgere nella mente di lettori, tester, lead e manager su concetti come il test anticipato.

L’adozione del test anticipato come attività integrante del programma di test generale per un determinato progetto software o una versione avvantaggia immensamente l’organizzazione nel fornire un prodotto o un sistema solido e qualificato.