Strategia di automazione del test per progetti Agile

Questo esempio di strategia di automazione del test presuppone un modello di distribuzione continua con più team agili.

Negli articoli precedenti, un overarching Strategia di test agile documento così come come impostare una funzione QA da zero per un progetto agile e come il test automatizzato sia uno degli elementi chiave nella configurazione iniziale.

In questo esempio di strategia di automazione del test, elenco i punti chiave da considerare per ottenere il massimo dallo sforzo di automazione del test.




Sintesi

Il test automatizzato è un'attività fondamentale di qualsiasi metodologia di sviluppo agile. Man mano che ci spostiamo verso la distribuzione continua, l'automazione dei test diventa sempre più importante grazie alla rapida risposta di feedback che fornisce al team di sviluppo sullo stato di salute dell'applicazione.

Per ottenere questo rapido feedback, i test automatizzati devono essere eseguiti continuamente, dovrebbero essere veloci ei risultati dei test dovrebbero essere coerenti e affidabili.


Per raggiungere questi obiettivi, la maggior parte delle verifiche dovrebbe essere eseguita come parte dello sviluppo di nuove funzionalità. In altre parole, lo sviluppo e il test dovrebbero essere un'attività coerente e la qualità dovrebbe essere 'incorporata' fin dall'inizio assicurando che ciò che viene sviluppato funzioni e che non abbia interrotto le funzionalità esistenti.

Ciò richiede 'l'inversione della piramide dell'automazione del test' spingendo verso il basso i test della GUI che richiedono molto tempo per essere eseguiti, a livelli inferiori, ad es. Livello API che può essere eseguito subito dopo gli unit test come parte della build per fornire il livello iniziale di sicurezza.

Relazionato:



Panoramica della strategia di automazione del test

Prevenzione piuttosto che rilevamento: mentre ogni sforzo dovrebbe essere speso per prevenire l'introduzione di difetti nell'applicazione in primo luogo, le tecniche ei metodi per questo sono al di fuori dello scopo di questo post. Qui, le metodologie sono definite per consentire il rilevamento rapido dei bug quando vengono introdotti nel sistema e il feedback allo sviluppo.


La qualità dovrebbe essere favorita rispetto alla quantità. Nella maggior parte dei casi, è meglio rilasciare con una funzionalità che sia solida come una roccia piuttosto che più funzionalità che sono traballanti. Come criterio di rilascio minimo, qualsiasi caratteristica sviluppata di recente non avrebbe dovuto introdurre alcun difetto di regressione.

Come già accennato, un rapido feedback sullo stato di salute dell'applicazione è di enorme importanza per supportare la fornitura continua, pertanto, viene formulato un processo e un meccanismo attraverso il quale possiamo ottenere rapidamente un feedback.

Un modo per ottenere un feedback rapido è aumentare il numero di unit test, test di integrazione e test API. Questi test di basso livello forniranno una rete di sicurezza per garantire che il codice funzioni come previsto e aiuta a prevenire la fuga di difetti in altri livelli di test.

I test unitari costituiscono le basi per l'automazione dei test a livelli più alti.


Il secondo elemento di miglioramento è l'esecuzione dei test di regressione più frequentemente e in linea con il processo di integrazione continua, vedere più avanti. Il test di automazione non dovrebbe essere visto come un'attività isolata, ma piuttosto come un'attività coerente incorporata nell'SDLC.



Definizione di pacchetti di regressione

I test di regressione automatizzati sono il fulcro della strategia di automazione del test.

Pacchetto di regressione del fumo

I pacchetti di regressione servono come controllo di integrità per consentire il caricamento e l'accesso all'applicazione. Inoltre, dovrebbero essere eseguiti solo alcuni scenari chiave per assicurarsi che l'applicazione sia ancora funzionante.

Lo scopo del pacchetto di prova del fumo è quello di rilevare i problemi più evidenti, come il mancato caricamento dell'applicazione o l'impossibilità di eseguire un flusso utente comune; per questo motivo i test del fumo non dovrebbero durare più di Cinque minuti per fornire un rapido feedback nel caso in cui qualcosa di importante non funzioni.


Il pacchetto di test del fumo viene eseguito su ogni distribuzione e può essere una combinazione di test API e / o GUI.

Pacchetti di regressione funzionale , Che ha lo scopo di verificare la funzionalità dell'applicazione in modo più dettagliato rispetto al test del fumo.

Devono esistere più pacchetti di regressione per scopi diversi. Se ci sono più team che lavorano su diverse sezioni dell'applicazione, idealmente dovrebbero esserci diversi pacchetti di regressione che possono essere concentrati sull'area su cui il team sta lavorando.

Questi pacchetti dovrebbero essere in grado di funzionare in qualsiasi ambiente come e quando richiesto, a condizione che il comportamento delle funzionalità rimanga coerente in tutti gli ambienti. Vengono eseguiti più volte al giorno e non dovrebbero durare più di 15-30 minuti.


Poiché questi test funzionali sono più dettagliati, sarà necessario più tempo per l'esecuzione, pertanto è importante avere la maggior parte dei test funzionali a livello API in cui i test possono essere eseguiti più velocemente in modo da poter essere all'interno del Da 15 a 30 minuti limite di tempo.

Pacchetto di regressione end-to-end, che verifica l'intera applicazione nel suo complesso. Lo scopo di questi test è garantire che le varie parti dell'applicazione che si connettono a vari database e applicazioni di terze parti funzionino correttamente.

I test End-to-End non hanno lo scopo di testare tutte le funzionalità in quanto quelle sono già testate nei pacchetti di regressione funzionale, tuttavia, questi test sono 'leggeri' che controllano semplicemente le transizioni da uno stato all'altro e una manciata degli scenari o dei viaggi degli utenti più importanti.

Questi test vengono eseguiti principalmente tramite la GUI, in quanto controllano come gli utenti utilizzerebbero il sistema. Il tempo necessario per eseguirli può variare da un'applicazione all'altra, ma di solito vengono eseguiti una volta al giorno o alla notte.



Strategia di automazione del test per più team Agile

test_automation_strategy_agile

Test unitari automatizzati

L'automazione del test inizia a livello di unità. Gli unit test dovrebbero essere scritti dagli sviluppatori per qualsiasi nuova funzionalità sviluppata. Questi test unitari costituiscono la base di una pratica di automazione più ampia che si estende fino ai test della GUI di sistema.

È responsabilità degli sviluppatori garantire che per ogni nuova funzionalità sviluppata, venga scritta una serie di test unitari coerenti e solidi per dimostrare che il codice funziona come previsto e soddisfa i requisiti.

I test unitari forniscono il massimo ROI al team in quanto sono molto veloci da eseguire, facili da mantenere e modificare (poiché non ci sono dipendenze) e quando ci sono errori nel codice, vengono rapidamente inviati allo sviluppatore.

Gli unit test vengono eseguiti sulla macchina dello sviluppatore e nell'ambiente CI.

Integrazione automatizzata / API o test di servizio

Mentre gli unit test si basano sul test delle funzioni all'interno di una classe, i test di integrazione costituiscono il livello successivo dagli unit test per testare le classi che compongono collettivamente il componente per fornire una parte di funzionalità. Questi test vengono eseguiti solo quando gli Unit Test sono stati eseguiti e superati.

I test di servizio vengono naturalmente eseguiti a livello API senza l'intervento dell'interfaccia web della GUI; quindi i test sarebbero in grado di verificare la funzionalità in una forma pura e poiché i test parlano direttamente ai componenti, sono veloci da eseguire e faranno parte della build.

Se necessario, prende in giro come wiremock verrà utilizzato per escludere la dipendenza di altri 3rdsistemi di parti e quando i sistemi a valle non sono disponibili per fornire i dati richiesti per i test.

I test di integrazione e / o di servizio possono essere eseguiti anche sulla macchina dello sviluppatore e far parte della build, ma se iniziano a richiedere molto tempo, è meglio eseguirli nell'ambiente CI.

Strumenti come SoapUI possono essere utilizzati per i test di servizio.

Test dell'applicazione

Una tipica applicazione di e-commerce può essere suddivisa in diverse applicazioni o 'app' che forniscono funzionalità diverse. Il concetto di 'App Testing' è dove un gruppo di test che testano la funzionalità di un'app vengono organizzati insieme ed eseguiti rispetto all'app desiderata. Questo pacchetto sarà utile nei casi in cui un team desidera rilasciare una singola App e vorrebbe sapere se funziona correttamente.

I test dell'applicazione in genere richiedono un'interfaccia per interagire con i diversi componenti, pertanto si prevede che questi test vengano eseguiti tramite un browser sulla GUI.

Lo scopo di App Testing è garantire che le funzionalità dell'applicazione siano funzionalmente corrette. Poiché i test sono organizzati in modo da fornire fiducia nello stato di salute di una particolare app, questi test vengono normalmente definiti test verticali, poiché eseguono 'giù' una particolare app. I test sono molto approfonditi e la copertura è ampia.

Selenium WebDriver potrebbe essere utilizzato per eseguire questi test automatici contro il browser. Questo strumento è il più popolare per i test di automazione del browser e fornisce una ricca API per consentire verifiche complesse.

Test di scenario end-to-end

I test automatici della GUI che vengono eseguiti sul sistema, fungono da flussi utente tipici, percorsi o scenari end-to-end. A causa di problemi con questo tipo di test (discussi di seguito), questi verranno ridotti al minimo. Gli scenari end-to-end sono inclusi nel pacchetto di regressione notturno.



Invertire la piramide dell'automazione del test

Come parte della strategia di automazione dei test, dobbiamo assicurarci di ridurre al minimo il numero di test automatizzati eseguiti a livello della GUI.

Sebbene l'esecuzione di test automatizzati tramite la GUI fornisca test validi e significativi in ​​termini di simulazione dell'interazione di un utente con l'applicazione, è soggetto a molti problemi come elencato di seguito:

Fragile

Poiché i test si basano sui localizzatori HTML per identificare gli elementi web con cui interagire, non appena viene modificato un ID i test falliscono, quindi sopportano molti costi di manutenibilità.

Test limitati

La GUI potrebbe limitare la capacità del tester di verificare completamente una funzionalità poiché la GUI potrebbe non contenere tutti i dettagli della risposta web per consentire la verifica.

Lento

Poiché i test vengono eseguiti tramite la GUI, i tempi di caricamento della pagina possono aumentare notevolmente il tempo di test complessivo e come tale il feedback agli sviluppatori è relativamente lento.

Minimo ROI

A causa dei problemi sopra menzionati, i test automatizzati della GUI forniscono il ROI minimo.

I test di automazione del browser saranno ridotti al minimo e verranno utilizzati per simulare il comportamento di un utente incorporando flussi utente comuni e scenari end-to-end in cui viene esercitato il sistema nel suo insieme.