Test Agile - Guida rapida

Agileè una metodologia di sviluppo iterativa, in cui le attività di sviluppo e di test sono simultanee. Il test non è una fase separata; La codifica e il test vengono eseguiti in modo interattivo e incrementale, con conseguente prodotto finale di qualità, che soddisfa i requisiti del cliente. Inoltre, l'integrazione continua si traduce in una rapida rimozione dei difetti e quindi in un risparmio di tempo, impegno e costi.

Manifesto Agile

L'Agile Manifesto è stato pubblicato da un team di sviluppatori di software nel 2001, sottolineando l'importanza del team di sviluppo, adattandosi alle mutevoli esigenze e al coinvolgimento dei clienti.

The Agile Manifesto is −

Stiamo scoprendo modi migliori per sviluppare software facendolo e aiutando gli altri a farlo. Attraverso questo lavoro, siamo arrivati a valorizzare -

Individui e interazioni su processi e strumenti.
Software funzionante su documentazione completa.
Collaborazione con il cliente nella negoziazione del contratto.
Rispondere al cambiamento piuttosto che seguire un piano.

Cioè, mentre c'è valore negli elementi a destra, diamo più valore agli elementi a sinistra.

Cos'è l'Agile Testing?

Agile Testing è una pratica di test del software che segue i principi dello sviluppo agile del software.

L'Agile Testing coinvolge tutti i membri del team di progetto, con competenze speciali fornite dai tester. Il test non è una fase separata e si intreccia con tutte le fasi di sviluppo come requisiti, progettazione e codifica e generazione di test case. I test si svolgono simultaneamente durante il ciclo di vita dello sviluppo.

Inoltre, con i tester che partecipano all'intero ciclo di vita dello sviluppo in collaborazione con i membri del team interfunzionale, il contributo dei tester verso la costruzione del software secondo i requisiti del cliente, con un design e un codice migliori diventerebbe possibile.

L'Agile Testing copre tutti i livelli di test e tutti i tipi di test.

Test Agile vs. Test a cascata

In una metodologia di sviluppo a cascata, le attività del ciclo di vita dello sviluppo avvengono in fasi sequenziali. Pertanto, il test è una fase separata e viene avviato solo dopo il completamento della fase di sviluppo.

Di seguito sono riportati i punti salienti delle differenze tra Agile Testing e Waterfall Testing:

Test agili	Test a cascata
Il test non è una fase separata e avviene contemporaneamente allo sviluppo.	Il test è una fase separata. Tutti i livelli e i tipi di test possono iniziare solo dopo il completamento dello sviluppo.
I tester e gli sviluppatori lavorano insieme.	I tester lavorano separatamente dagli sviluppatori.
I tester sono coinvolti nella definizione dei requisiti. Questo aiuta a mappare i requisiti ai comportamenti nello scenario del mondo reale e anche a inquadrare i criteri di accettazione. Inoltre, i casi di test di accettazione logici sarebbero pronti insieme ai requisiti.	I tester potrebbero non essere coinvolti nella fase dei requisiti.
Il test di accettazione viene eseguito dopo ogni iterazione e viene richiesto il feedback dei clienti.	Il test di accettazione viene effettuato solo alla fine del progetto.
Ogni iterazione completa il proprio test, consentendo così di implementare il test di regressione ogni volta che vengono rilasciate nuove funzioni o logica.	Il test di regressione può essere implementato solo dopo il completamento dello sviluppo.
Nessun ritardo tra la codifica e il test.	Ritardi di tempo usuali tra la codifica e il test.
Test continuo con livelli di test sovrapposti.	Il test è un'attività a tempo ei livelli di test non possono sovrapporsi.
Il test è una best practice.	I test vengono spesso trascurati.

Principi del test agile

I principi del test Agile sono:

Testing moves the project forward- Il test continuo è l'unico modo per garantire un progresso continuo. L'Agile Testing fornisce feedback su base continuativa e il prodotto finale soddisfa le esigenze aziendali.
Testing is not a phase- Test del team agile insieme al team di sviluppo per garantire che le funzionalità implementate durante una data iterazione siano effettivamente eseguite. Il test non viene conservato per una fase successiva.
Everyone tests- Nei test agili, l'intero team, inclusi analisti, sviluppatori e tester, testa l'applicazione. Dopo ogni iterazione, anche il cliente esegue il test di accettazione dell'utente.
Shortening Feedback Loops- In Agile Testing, il team aziendale conosce lo sviluppo del prodotto per ogni iterazione. Sono coinvolti in ogni iterazione. Il feedback continuo riduce il tempo di risposta del feedback e quindi il costo per risolverlo è inferiore.
Keep the Code Clean- I difetti vengono corretti quando vengono generati nella stessa iterazione. Ciò garantisce un codice pulito in qualsiasi pietra miliare dello sviluppo.
Lightweight Documentation - Invece di una documentazione di test completa, tester Agile -
- Utilizzare elenchi di controllo riutilizzabili per suggerire test.
- Concentrati sull'essenza del test piuttosto che sui dettagli accidentali.
- Usa stili / strumenti di documentazione leggeri.
- Cattura idee di test in carte per test esplorativi.
- Sfrutta i documenti per molteplici scopi.
Leveraging one test artifact for manual and automated tests- Lo stesso artefatto dello script di test può essere utilizzato per i test manuali e come input per i test automatizzati. Ciò elimina il requisito della documentazione di test manuale e quindi di uno script di test di automazione equivalente.
“Done Done,” not just done - In Agile, si dice che una funzionalità venga eseguita non dopo lo sviluppo ma dopo lo sviluppo e il test.
Test-Last vs. Test Driven- I casi di test vengono scritti insieme ai requisiti. Quindi, lo sviluppo può essere guidato dai test. Questo approccio è chiamato Test Driven Development (TDD) e Acceptance Test Driven Development (ATDD). Ciò è in contrasto con il test come ultima fase del test a cascata.

Attività di test agili

Le attività di test Agile a livello di progetto sono:

Pianificazione del rilascio (piano di test)
- Per ogni iterazione,
- Attività di test agili durante un'iterazione
Test di regressione
Attività di rilascio (correlate al test)

Le attività di test Agile durante un'iterazione includono:

Partecipare alla pianificazione dell'iterazione
Stima delle attività dal punto di vista del test
Scrittura di casi di test utilizzando le descrizioni delle funzionalità
Test unitario
Test d'integrazione
Test delle funzionalità
Correzione dei difetti
Test d'integrazione
Test di accettazione
Reporting sullo stato di avanzamento del test
Tracciamento dei difetti

Agile è una metodologia di sviluppo iterativa, in cui l'intero team di progetto partecipa a tutte le attività. I requisiti evolvono con il progredire delle iterazioni, attraverso la collaborazione tra il cliente e i team auto-organizzati. Poiché la codifica e il test vengono eseguiti in modo interattivo e incrementale, durante il corso dello sviluppo, il prodotto finale sarà di qualità e garantirà i requisiti del cliente.

Ogni iterazione si traduce in un incremento del prodotto funzionante integrato e viene fornito per il test di accettazione dell'utente. Il feedback dei clienti così ottenuto sarebbe un input per le iterazioni successive / successive.

Integrazione continua, qualità continua

L'integrazione continua è la chiave per il successo dello sviluppo agile. Integrare frequentemente, almeno quotidianamente in modo da essere pronti per un rilascio come e quando richiesto. Il testing in Agile diventa una componente essenziale di tutte le fasi dello sviluppo, garantendo una qualità continua del prodotto. Il feedback costante di tutte le persone coinvolte nel progetto si aggiunge alla qualità del prodotto.

In Agile, la comunicazione è data la massima importanza e le richieste dei clienti vengono ricevute come e quando necessario. Questo dà la soddisfazione al cliente che tutti gli input siano considerati e che il prodotto di qualità lavorativa sia disponibile durante tutto lo sviluppo.

Metodologie agili

Esistono diverse metodologie Agile che supportano lo sviluppo agile. Le metodologie Agile includono:

Mischia

Scrum è un metodo di sviluppo Agile che enfatizza un approccio incentrato sul team. Sostiene la partecipazione dell'intero team a tutte le attività di sviluppo del progetto.

XP

eXtreme Programming è incentrato sul cliente e si concentra sui requisiti in continua evoluzione. Con rilasci frequenti e feedback dei clienti, il prodotto finale sarà di qualità soddisfacendo i requisiti del cliente che vengono resi più chiari durante il processo.

Cristallo

Crystal si basa su noleggio, consegna ciclica e conclusione.

Il chartering prevede la formazione di un team di sviluppo, l'esecuzione di un'analisi preliminare di fattibilità, l'arrivo a un piano iniziale e alla metodologia di sviluppo.
La consegna ciclica con due o più cicli di consegna si concentra sulla fase di sviluppo e sulla consegna finale del prodotto integrato.
Durante il riepilogo, vengono eseguite la distribuzione nell'ambiente utente, le revisioni e le riflessioni post-distribuzione.

FDD

Feature Driven Development (FDD) implica la progettazione e la creazione di feature. La differenza tra FDD e altre metodologie di sviluppo agile è che le funzionalità vengono sviluppate separatamente in fasi specifiche e brevi.

DSDM

Il metodo di sviluppo software dinamico (DSDM) si basa su RAD (Rapid Application Development) ed è allineato al Framework Agile. DSDM si concentra sulla consegna frequente del prodotto, coinvolgendo attivamente gli utenti e consentendo ai team di prendere decisioni rapide.

Sviluppo software snello

Nello sviluppo di software snello, l'obiettivo è eliminare gli sprechi e dare valore al cliente. Ciò si traduce in un rapido sviluppo e in un prodotto di valore.

Gli scarti includono lavoro parzialmente svolto, lavoro irrilevante, caratteristiche non utilizzate dal cliente, difetti, ecc. Che si aggiungono ai ritardi nella consegna.

Il Lean Principles sono -

Eliminate lo spreco
Amplifica l'apprendimento
Ritardo impegno
Potenzia il team
Consegna veloce
Costruisci integrità
Vedi il tutto

Kanban

Kanban si concentra sulla gestione del lavoro con un'enfasi sulla consegna just-in-time (JIT), senza sovraccaricare i membri del team. Le attività vengono visualizzate per tutti i partecipanti e per i membri del team di estrarre il lavoro da una coda.

Kanban si basa su -

Kanban Board (visuale e persistente durante lo sviluppo)
Limite di work-in-progress (WIP)
Tempi di consegna

Metodologie di test agili

Le pratiche di test sono ben definite per ogni progetto, Agile o meno, per fornire prodotti di qualità. I principi di test tradizionali sono usati abbastanza spesso nei test agili. Uno di questi è Early Testing che si concentra su:

Scrittura di casi di test per esprimere il comportamento del sistema.
Prevenzione, rilevamento e rimozione precoci dei difetti.
Garantire che i giusti tipi di test vengano eseguiti al momento giusto e come parte del giusto livello di test.

In tutte le Metodologie Agile di cui abbiamo discusso, l'Agile Testing è di per sé una Metodologia. In tutti gli approcci, i casi di test vengono scritti prima della codifica.

In questo tutorial, ci concentreremo su Scrum come metodologia di test Agile.

Le altre metodologie di test Agile comunemente utilizzate sono:

Test-Driven Development (TDD) - Test-Driven Development (TDD) si basa sulla codifica guidata da test.
Acceptance Test-Driven Development (ATDD) - L'Acceptance Test-Driven Development (ATDD) si basa sulla comunicazione tra clienti, sviluppatori e tester ed è guidato da criteri di accettazione e casi di test di accettazione predefiniti.
Behavior-Driven Development (BDD) - I test in Behavior-Driven Development (BDD) si basano sul comportamento previsto del software sviluppato.

Ciclo di vita dei test agili

In Scrum, le attività di test includono:

Contribuire alle storie degli utenti in base al comportamento previsto del sistema rappresentato come casi di test
Pianificazione dei rilasci basata sul lavoro di test e sui difetti
Sprint Planning basato su User Story e Difetti
Esecuzione dello sprint con test continui
Test di regressione dopo il completamento dello Sprint
Segnalazione dei risultati dei test
Test di automazione

Il test è iterativo e basato sugli sprint come illustrato nel diagramma riportato di seguito:

Lo sviluppo agile è incentrato sul team e sviluppatori e tester prendono parte a tutte le attività di progetto e sviluppo. Il lavoro di squadra massimizza il successo dei test nei progetti Agile.

Un team di Tester in Agile deve partecipare e contribuire a tutte le attività del progetto e allo stesso tempo deve far leva sull'esperienza nei test.

Un tester Agile dovrebbe avere capacità di test tradizionali. Inoltre, Agile tester necessita di:

Buone capacità interpersonali.
Capacità di agire in modo positivo e orientato alla soluzione con i membri del team e le parti interessate.
Capacità di mostrare un pensiero critico, orientato alla qualità e scettico sul prodotto.
Attitudine ad essere proattivi per acquisire attivamente informazioni dagli stakeholder.
Capacità di lavorare efficacemente con clienti e stakeholder nella definizione di User Story verificabili, i Criteri di Accettazione.
Talento per essere un buon membro del team che lavora con gli sviluppatori nella produzione di codice di qualità.
Usabilità delle abilità di test per avere i casi di test giusti al momento giusto e al livello giusto ed eseguirli bene entro la durata dello sprint.
Capacità di valutare e riportare i risultati dei test, lo stato di avanzamento dei test e la qualità del prodotto.
Disponibilità a rispondere rapidamente ai cambiamenti, inclusa la modifica, l'aggiunta o il miglioramento dei casi di test.
Potenziale di auto-organizzazione del lavoro.
Entusiasmo per la continua crescita delle competenze.
Competenza in Test Automation, Test-driven Development (TDD), Acceptance Test-driven Development (ATDD), Behavior Driven Development (BDD) e Test basati sull'esperienza.

Ruolo del Tester in Agile Team

Tester in Agile Team partecipa a tutte le attività di progetto e sviluppo per contribuire al meglio delle competenze di testing.

Le attività di Agile Tester includono:

Garantire un uso corretto degli strumenti di test.
Configurazione, utilizzo e gestione degli ambienti di test e dei dati di test.
Mentoring altri membri del team in aspetti rilevanti del test.
Garantire che le attività di test appropriate siano programmate durante la pianificazione del rilascio e dello sprint.
Comprensione, implementazione e aggiornamento della strategia di test.
Collaborare con sviluppatori, clienti e stakeholder per chiarire i requisiti, in termini di testabilità, coerenza e completezza.
Eseguire i test giusti al momento giusto e ai livelli di test giusti.
Segnalare i difetti e lavorare con il team per risolverli.
Misurazione e reporting della copertura del test su tutte le dimensioni di copertura applicabili.
Partecipare a retrospettive di sprint, suggerendo e implementando proattivamente miglioramenti.

Nell'Agile Lifecycle, un tester svolge un ruolo significativo in:

Teamwork
Pianificazione dei test
Sprint Zero
Integration
Pratiche di test agili

Lavoro di squadra

Nello sviluppo agile, il lavoro di squadra è fondamentale e quindi richiede quanto segue:

Collaborative Approach- Lavorare con i membri del team interfunzionale su strategia di test, pianificazione dei test, specifiche dei test, esecuzione dei test, valutazione dei test e report dei risultati dei test. Contribuire all'esperienza di test insieme ad altre attività del team.
Self-organizing - Pianificare e organizzare bene all'interno degli sprint per raggiungere gli obiettivi dei test amalgamando anche le competenze di altri membri del team.
Empowerment - Prendere decisioni tecniche appropriate per raggiungere gli obiettivi del team.
Commitment - Impegnarsi a comprendere e valutare il comportamento e le caratteristiche del prodotto come richiesto dai clienti e dalle parti interessate.
Transparent - Aperto, Comunicante e Responsabile.
Credibility- Garantire la credibilità della strategia di test, la sua implementazione e l'esecuzione. Tenere i clienti e le parti interessate informati sulla strategia di test.
Open to Feedback- Partecipare a sprint retrospettive per imparare sia dai successi che dai fallimenti. Cercare il feedback dei clienti e agire rapidamente e in modo appropriato per garantire risultati di qualità.
Resilient - Rispondere ai cambiamenti.

Pianificazione dei test

La pianificazione del test dovrebbe iniziare durante la pianificazione del rilascio e l'aggiornamento durante ogni sprint. La pianificazione dei test dovrebbe coprire le seguenti attività:

Definizione dell'ambito del test, estensione del test, obiettivi di test e sprint.
Decidere l'ambiente di test, gli strumenti di test, i dati di test e le configurazioni.
Assegnazione di test di funzionalità e caratteristiche.
Pianificazione delle attività di test e definizione della frequenza dei test.
Identificazione di metodi, tecniche, strumenti e dati di test.
Accertamento di prerequisiti quali compiti predecessori, competenza e formazione.
Identificazione di dipendenze come funzioni, codice, componenti di sistema, fornitore, tecnologia, strumenti, attività, attività, team, tipi di test, livelli di test e vincoli.
Stabilire le priorità considerando l'importanza e le dipendenze del cliente / utente.
Arrivando alla durata del tempo e allo sforzo richiesto per testare.
Identificazione dei compiti ad ogni pianificazione dello sprint.

Sprint Zero

Sprint Zero prevede attività di preparazione prima del primo sprint. Un tester deve collaborare con il team nelle seguenti attività:

Identificazione dell'ambito
Suddivisione delle user story in sprint
Creazione dell'architettura di sistema
Pianificazione, acquisizione e installazione di strumenti (inclusi strumenti di test)
Creazione della strategia di test iniziale per tutti i livelli di test
Definizione delle metriche di test
Specificare i criteri di accettazione, chiamati anche la definizione di "Fatto"
Definizione dei criteri di uscita
Creazione della lavagna Scrum
Stabilire la direzione per i test durante gli sprint

Integrazione

In Agile, un prodotto funzionante di qualità dovrebbe essere pronto per il rilascio in qualsiasi momento del ciclo di vita dello sviluppo. Ciò implica l'integrazione continua come parte dello sviluppo. Un tester Agile deve supportare l'integrazione continua con test continui.

Per ottenere ciò, un tester deve:

Comprendi la strategia di integrazione.
Identifica tutte le dipendenze tra funzioni e caratteristiche.

Pratiche di test agili

Un tester Agile deve adattare le pratiche Agile per i test in un progetto Agile.

Pairing- Due membri del team lavorano insieme sulla stessa tastiera. Mentre uno di loro verifica, l'altro esamina / analizza i test. I due membri del team possono essere
- Un tester e uno sviluppatore
- Un tester e un analista aziendale
- Due tester
Incremental Test Design - I casi di test sono costruiti dalle storie degli utenti, iniziando con test semplici e passando a test più complessi.
Mind Mapping- Una mappa mentale è un diagramma per organizzare visivamente le informazioni. Le mappe mentali possono essere utilizzate come uno strumento efficace nei test Agile, utilizzando le informazioni che possono essere organizzate sulle sessioni di test necessarie, le strategie di test ei dati di test.

Lo stato del test può essere comunicato -

Durante le riunioni giornaliere in piedi
Utilizzo di strumenti di gestione dei test standard
Tramite messaggeri

Lo stato del test determinato dallo stato di superamento del test è cruciale per decidere se l'attività è "Completata". Fatto significa che tutti i test per l'attività vengono superati.

Progresso del test

È possibile monitorare l'avanzamento del test utilizzando:

Scrum Boards (Agile Task Board)
Grafici Burndown
Risultati dei test automatizzati

Test Progress ha anche un impatto diretto sul progresso dello sviluppo. Questo perché una User Story può essere spostata inDonestato solo dopo aver raggiunto i criteri di accettazione. Questo, a sua volta, viene deciso dallo stato del test in quanto i criteri di accettazione vengono giudicati da uno stato del test.

Se ci sono ritardi o blocchi nell'avanzamento del test, l'intero team discute e lavora in collaborazione per risolvere lo stesso.

Nei progetti Agile, i cambiamenti avvengono abbastanza spesso. Quando si verificano molti cambiamenti, possiamo aspettarci che lo stato del test, lo stato di avanzamento del test e la qualità del prodotto evolvano costantemente. I tester Agile devono fornire tali informazioni al team in modo che le decisioni appropriate possano essere prese al momento giusto per rimanere sulla buona strada per il completamento con successo di ogni iterazione.

Quando si verificano modifiche, possono influire sulle funzionalità esistenti di iterazioni precedenti. In questi casi, i test manuali e automatici devono essere aggiornati per affrontare efficacemente il rischio di regressione. È necessario anche il test di regressione.

Qualità del prodotto

Le metriche sulla qualità del prodotto includono:

Test superato / non superato
Difetti rilevati / risolti
Copertura del test
Tassi di test superato / non superato
Tassi di rilevamento dei difetti
Densità dei difetti

L'automazione della raccolta e del reporting delle metriche sulla qualità del prodotto aiuta a:

Mantenere la trasparenza.
Raccogliere tutte le metriche pertinenti e richieste al momento giusto.
Segnalazione immediata senza ritardi nelle comunicazioni.
Consentire ai tester di concentrarsi sui test.
Filtraggio dell'uso improprio delle metriche.

Per garantire la qualità complessiva del prodotto, il team Agile deve ottenere il feedback dei clienti sul fatto che il prodotto soddisfi le aspettative dei clienti. Questo deve essere eseguito alla fine di ogni iterazione e il feedback sarà un input per le iterazioni successive.

Fattori chiave del successo

Nei progetti Agile, è possibile fornire prodotti di qualità se i test Agile hanno esito positivo.

I seguenti punti devono essere considerati per il successo dei test Agile:

Il test agile si basa su approcci di test first e test continui. Pertanto, gli strumenti di test tradizionali, basati sull'approccio test-last, potrebbero non essere adatti. Quindi, mentre si scelgono gli strumenti di test nei progetti Agile, è necessario verificare l'allineamento ai test Agile.
Riduci il tempo totale di test automatizzando i test nelle prime fasi del ciclo di vita di sviluppo.
I tester agili devono mantenere il loro ritmo per allinearsi al programma di rilascio dello sviluppo. Pertanto, la corretta pianificazione, monitoraggio e ripianificazione delle attività di test deve essere eseguita al volo con la qualità del prodotto come obiettivo.
I test manuali rappresentano l'80% dei test nei progetti. Pertanto, i tester con esperienza devono far parte del team Agile.
La partecipazione di questi tester con esperienza durante tutto il ciclo di vita dello sviluppo fa sì che l'intero team si concentri sul prodotto di qualità che soddisfa le aspettative dei clienti.
- Definire le storie degli utenti che enfatizzano il comportamento del prodotto previsto dagli utenti finali.
- Identificazione dei criteri di accettazione a livello di storia utente / a livello di attività secondo le aspettative del cliente.
- Stima dello sforzo e della durata per le attività di test.
- Pianificazione delle attività di test.
- Allineamento con il team di sviluppo per garantire la produzione di codice che soddisfi i requisiti con un design di test iniziale.
- Testare i primi e continui test per garantire che lo stato di completamento sia raggiunto soddisfacendo i criteri di accettazione al momento previsto.
- Garantire test a tutti i livelli durante lo sprint.
- Test di regressione alla fine di ogni sprint.
- Raccolta e analisi delle metriche di prodotto utili per il successo del progetto.
- Analisi dei difetti per identificare quali devono essere corretti nello Sprint corrente e quali possono essere ritardati agli Sprint successivi.
- Concentrarsi su ciò che è importante dal punto di vista del cliente.

Lisa Crispin ha definito sette fattori chiave per il successo dei test agili:

Whole Team approach- In questo tipo di approccio, gli sviluppatori addestrano i tester e i tester addestrano gli altri membri del team. Questo aiuta tutti a comprendere ogni compito del progetto, quindi la collaborazione e il contributo avranno il massimo beneficio. Anche la collaborazione dei tester con i clienti è un fattore importante per impostare le loro aspettative fin dall'inizio e tradurre i criteri di accettazione in quelli richiesti per superare il test.
Agile Testing Mindset - I tester sono proattivi nel migliorare continuamente la qualità e collaborare costantemente con il resto del team.
Automate Regression Testing- Progettazione per la testabilità e sviluppo di guida con test. Inizia in modo semplice e consenti al team di scegliere gli strumenti. Sii pronto a fornire consigli.
Provide and Obtain Feedback- Poiché questo è un valore Agile fondamentale, l'intero team dovrebbe essere aperto al feedback. Poiché i tester sono fornitori di feedback esperti, è necessario concentrarsi sulle informazioni pertinenti e necessarie. In cambio, una volta ottenuto il feedback, è opportuno prevedere modifiche e test del caso di test.
Build a Foundation of Core Agile Practices - Concentrarsi sul test insieme alla codifica, integrazione continua, ambienti di test collaborativi, lavorare in modo incrementale, accettare i cambiamenti, mantenere la sinergia.
Collaborate with Customers - Esempi concreti, comprensione e controllo della mappatura dei requisiti al comportamento del prodotto, impostazione dei criteri di accettazione, ottenimento di feedback.
Look at the Big Picture - Promuovi lo sviluppo con test ed esempi rivolti al business utilizzando dati di test del mondo reale e pensando agli impatti su altre aree.

In questo capitolo vedremo alcuni attributi significativi dell'Agile Testing.

Benefici dell'Agile Testing

I vantaggi dei test Agile sono:

Soddisfazione del cliente grazie al prodotto rapido, continuo e completamente testato e alla ricerca del feedback dei clienti.
Clienti, sviluppatori e tester interagiscono continuamente tra loro, riducendo così il tempo di ciclo.
I tester agili partecipano alla definizione dei requisiti contribuendo con la loro esperienza di test per concentrarsi su ciò che è realizzabile.
I tester agili partecipano alla stima valutando lo sforzo e il tempo del test.
Progettazione del test iniziale che riflette i criteri di accettazione.
Testare i requisiti consolidati da tutto il team, evitando inconvenienti.
Attenzione costante alla qualità del prodotto da parte di tutto il team.
Definizione di Done Il superamento dei test che riflettono lo stato garantisce che il requisito sia soddisfatto.
Feedback continuo su ritardi o blocchi in modo che la risoluzione possa essere effettuata immediatamente con lo sforzo di tutto il team.
Risposte rapide alle mutevoli esigenze e adattamento tempestivo.
Test di regressione guidato dall'integrazione continua.
Nessun ritardo tra sviluppo e test. test prima, vengono seguiti approcci di test continui.
I test di automazione sono stati implementati all'inizio del ciclo di vita dello sviluppo, riducendo così il tempo e gli sforzi totali per i test.

Best practice nel test agile

Segui le migliori pratiche fornite di seguito:

Inclusione di tester con esperienza in tutti i tipi di test a tutti i livelli.
I tester partecipano alla definizione dei requisiti, collaborando con i clienti sul comportamento atteso del prodotto.
I tester condividono continuamente feedback con sviluppatori e clienti.
Testare approcci di test iniziali e continui per allinearsi al lavoro di sviluppo.
Monitoraggio dello stato dei test e dei progressi dei test prontamente e costantemente concentrandosi sulla fornitura di prodotti di qualità.
Test di automazione nelle prime fasi del ciclo di vita di sviluppo per ridurre il tempo di ciclo.
Per eseguire il test di regressione, sfruttare i test di automazione come metodo efficace.

Sfide nei test agili

Le seguenti sfide esistono nei test Agile:

La mancata comprensione dell'approccio Agile e dei suoi limiti da parte del Business e del Management può portare a aspettative irraggiungibili.
Agile segue l'approccio dell'intero team, ma non tutti conoscono gli elementi essenziali delle pratiche di test. Si consiglia ai tester di istruire gli altri, ma nello scenario reale può essere impraticabile con Sprint time-boxed (iterazioni).
L'approccio Test First richiede agli sviluppatori di basare la codifica sul feedback del tester, ma in scenari reali gli sviluppatori sono più abituati a basare la codifica sui requisiti provenienti dal cliente o dall'azienda.
La responsabilità per il prodotto di qualità è dell'intero team Agile, ma nelle fasi iniziali gli sviluppatori potrebbero non concentrarsi sulla qualità poiché sono più nella modalità di implementazione.
L'integrazione continua richiede un test di regressione che richiede uno sforzo considerevole, anche se deve essere automatizzato.
I tester possono essere adattabili ai cambiamenti con la mentalità Agile, ma accogliere i cambiamenti e i test risultanti può essere impraticabile per raggiungere l'obiettivo di finire durante lo Sprint.
Si consiglia l'automazione anticipata in modo da ridurre lo sforzo e il tempo del test manuale. Ma, nello scenario reale, arrivare ai Test che possono essere automatizzati e automatizzarli richiede tempo e impegno.

Linee guida per il test agile

Utilizzare le seguenti linee guida durante l'esecuzione del test Agile.

Partecipare alla pianificazione del rilascio per identificare le attività di test richieste e elaborare la versione iniziale del piano di test.
Partecipare alla sessione di stima per arrivare allo sforzo e alla durata del test in modo che le attività di test siano adattate alle iterazioni.
Partecipa alla definizione della User Story per arrivare ai casi di test di accettazione.
Partecipa a ogni Sprint Planning Meeting per comprendere l'ambito e aggiornare il piano di test.
Collabora continuamente con il Team di Sviluppo durante lo Sprint per rendere il Test e la Codifica un successo anche all'interno dello Sprint.
Partecipa alle riunioni quotidiane in piedi e comunica eventuali ritardi o blocchi dei test per ottenere una risoluzione immediata.
Monitora e riporta regolarmente lo stato del test, l'avanzamento del test e la qualità del prodotto.
Preparati ad accogliere le modifiche, rispondendo con modifiche a Test Case, Test Data.
Partecipa alle Sprint Retrospectives per comprendere e contribuire alle migliori pratiche e alle lezioni apprese.
Collaborare per ottenere il feedback dei clienti ad ogni Sprint.

Come nel caso del test tradizionale, anche il test agile deve coprire tutti i livelli di test.

Test unitario
Test d'integrazione
Test di sistema
Test di accettazione dell'utente

Test unitario

Fatto insieme alla codifica, dallo sviluppatore
Supportato da Tester che scrive casi di test garantendo il 100% di copertura del progetto
I casi di unit test e i risultati degli unit test devono essere rivisti
I difetti maggiori irrisolti (secondo priorità e gravità) non vengono lasciati
Tutti i test unitari sono automatizzati

Test d'integrazione

Fatto insieme all'integrazione continua man mano che gli Sprint progrediscono
Fatto alla fine dopo che tutti gli Sprint sono stati completati
Tutti i requisiti funzionali vengono testati
Vengono testate tutte le interfacce tra le unità
Tutti i difetti vengono segnalati
I test sono automatizzati ove possibile

Test di sistema

Fatto mentre lo sviluppo avanza
Le storie, le caratteristiche e le funzioni degli utenti vengono testate
Test effettuati in ambiente di produzione
Vengono eseguiti test di qualità (prestazioni, affidabilità, ecc.)
Vengono segnalati difetti
I test sono automatizzati ove possibile

Test di accettazione dell'utente

Fatto alla fine di ogni Sprint e alla fine del progetto
Fatto dal Cliente. Il feedback è preso dal team
Il feedback sarà un input per gli Sprint successivi
Le User Story in uno Sprint sono pre-verificate per essere testabili e sono con criteri di accettazione definiti

Tipi di test

Test dei componenti (test unitari)
Test funzionali (test delle storie degli utenti)
Test non funzionali (prestazioni, carico, stress, ecc.)
Test di accettazione

I test possono essere completamente manuali, completamente automatizzati, combinazione di manuali e automatizzati o manuali supportati da strumenti.

Supportare la programmazione e testare i prodotti critici

I test possono essere per -

Supporting Development (Support Programming) - I test di programmazione di supporto vengono utilizzati dai programmatori.
- Per decidere quale codice scrivere per realizzare un determinato comportamento di un sistema
- Quali test devono essere eseguiti dopo la codifica per garantire che il nuovo codice non ostacoli il resto dei comportamenti del sistema
Verification only (Critique Product) - I test critici sul prodotto vengono utilizzati per scoprire le inadeguatezze del prodotto finito

Test di fronte agli affari e di fronte alla tecnologia

Per decidere quali test eseguire e quando, è necessario determinare se un test è:

Business Facing, o
Tecnologia di fronte

Test di fronte al business

Un test è un test rivolto all'azienda se risponde alle domande incorniciate con parole del dominio aziendale. Questi sono compresi dagli esperti di business e li interesserebbero in modo che il comportamento del sistema possa essere spiegato nello scenario in tempo reale.

Test di fronte alla tecnologia

Un test è un test rivolto alla tecnologia se risponde alle domande incorniciate con parole dal dominio della tecnologia. I programmatori capiscono cosa deve essere implementato sulla base dei chiarimenti sulla tecnologia.

Questi due aspetti dei tipi di test possono essere visualizzati utilizzando gli Agile Testing Quadrants definiti da Brian Marick.

Quadranti Agile Testing

Combinando i due aspetti dei tipi di test, i seguenti quadranti di test Agile sono derivati da Brian Marick:

I quadranti Agile Testing forniscono un'utile tassonomia per aiutare i team a identificare, pianificare ed eseguire i test necessari.

Quadrant Q1- Livello di unità, tecnologia di fronte e supporta gli sviluppatori. Gli unit test appartengono a questo quadrante. Questi test possono essere test automatici.
Quadrant Q2- Livello di sistema, approccio aziendale e comportamento del prodotto conforme. I test funzionali appartengono a questo quadrante. Questi test sono manuali o automatizzati.
Quadrant Q3- Livello di accettazione del sistema o dell'utente, Business Facing e focus su scenari in tempo reale. I test di accettazione utente appartengono a questo quadrante. Questi test sono manuali.
Quadrant Q4- Livello di accettazione del sistema o operativo, tecnologia di fronte e focus su prestazioni, carico, stress, manutenibilità, test di scalabilità. Strumenti speciali possono essere utilizzati per questi test insieme ai test di automazione.

Combinando questi, i quadranti di test Agile che riflettono What-Testing-When può essere visualizzato come segue:

Sostenitori di Scrum Whole Team Approach, nel senso che ogni membro del team deve prendere parte a ogni attività del progetto. Il team Scrum si auto-organizza con responsabilità per i risultati del progetto. Il processo decisionale è lasciato al team che si traduca in azioni appropriate da intraprendere al momento giusto senza ritardi. Questo approccio incoraggia anche un uso corretto del talento del team invece di limitarsi a un'attività. I tester partecipano anche a tutte le attività di progetto e di sviluppo contribuendo con la loro esperienza nei test.

L'intero team lavora insieme su strategia di test, pianificazione dei test, specifiche dei test, esecuzione dei test, valutazione dei test e report dei risultati dei test.

Creazione collaborativa di User Story

I tester partecipano alla creazione della User Story. I tester contribuiscono con le loro idee sul possibile comportamento del sistema. Ciò aiuta il cliente e / o l'utente finale a comprendere il sistema nell'ambiente reale e quindi a ottenere chiarezza su ciò che effettivamente vogliono come risultato. Ciò si traduce in un congelamento più rapido dei requisiti e riduce anche la probabilità di modifiche dei requisiti in un secondo momento.

I tester forniscono anche i criteri di accettazione per ogni scenario concordato dal cliente.

I tester contribuiscono alla creazione di user story verificabili.

Pianificazione del rilascio

La pianificazione del rilascio viene eseguita per l'intero progetto. Tuttavia, il framework Scrum implica un processo decisionale iterativo poiché più informazioni vengono ottenute nel corso dell'esecuzione degli sprint. Pertanto, la sessione di pianificazione del rilascio all'inizio del progetto non deve produrre un piano di rilascio dettagliato per l'intero progetto. Può essere aggiornato continuamente, man mano che sono disponibili informazioni pertinenti.

Ogni sprint-end non ha bisogno di un rilascio. Un rilascio può avvenire dopo un gruppo di sprint. Il criterio principale di un rilascio è fornire valore commerciale al cliente. Il team decide la durata dello sprint con la pianificazione del rilascio come input.

La pianificazione del rilascio è la base dell'approccio al test e del piano di test per il rilascio. I tester stimano lo sforzo del test e pianificano il test per il rilascio. Quando i piani di rilascio cambiano, i tester devono gestire le modifiche, ottenere una base di test adeguata considerando un contesto di rilascio più ampio. I tester forniscono anche lo sforzo di test richiesto alla fine di tutti gli sprint.

Pianificazione dello sprint

La pianificazione dello sprint viene eseguita all'inizio di ogni sprint. Lo sprint backlog viene creato con le user story raccolte dal product backlog per l'implementazione in quel particolare sprint.

I tester dovrebbero:

Determina la testabilità delle storie utente selezionate per lo sprint
Crea test di accettazione
Definisci i livelli di test
Identifica l'automazione dei test

I tester aggiornano il piano di test con le stime per lo sforzo di test e le durate nello sprint. Ciò garantisce la fornitura di tempo per i test richiesti durante gli sprint time-boxed e anche la responsabilità dello sforzo di test.

Analisi del test

Quando inizia uno sprint, mentre gli sviluppatori proseguono l'analisi della storia per la progettazione e l'implementazione, i tester eseguono l'analisi del test per le storie nello sprint backlog. Tester crea i casi di test richiesti, sia test manuali che automatizzati.

Test

Tutti i membri del team Scrum dovrebbero partecipare ai test.

Gli sviluppatori eseguono gli unit test mentre sviluppano il codice per le user story. Gli unit test vengono creati in ogni sprint, prima che il codice venga scritto. I casi di unit test derivano da specifiche di progettazione di basso livello.
I tester eseguono le caratteristiche funzionali e non funzionali delle storie degli utenti.
I tester fanno da mentore agli altri membri del team di scrum con la loro esperienza nei test in modo che l'intero team abbia una responsabilità collettiva per la qualità del prodotto.
Alla fine dello sprint, il cliente e / o gli utenti finali eseguono il test di accettazione degli utenti e forniscono feedback al team di Scrum. Questo costituisce un input per lo sprint successivo.
I risultati dei test vengono raccolti e conservati.

Test di automazione

Il testing di automazione è molto importante nei team Scrum. I tester dedicano tempo alla creazione, esecuzione, monitoraggio e mantenimento di test e risultati automatizzati. Poiché le modifiche possono verificarsi in qualsiasi momento nei progetti Scrum, i tester devono adattarsi al test delle funzionalità modificate e anche ai test di regressione coinvolti. I test di automazione facilitano la gestione dello sforzo di test associato alle modifiche. I test automatizzati a tutti i livelli facilitano il raggiungimento dell'integrazione continua. I test automatizzati vengono eseguiti molto più velocemente dei test manuali senza alcuno sforzo aggiuntivo.

Il test manuale si concentra maggiormente sui test esplorativi, sulla vulnerabilità del prodotto e sulla previsione dei difetti.

Automazione delle attività di test

L'automazione delle attività di test riduce il carico di lavoro ripetuto e si traduce in risparmi sui costi. Automatizzare

Generazione dei dati di test
Caricamento dei dati di prova
Implementa la distribuzione nell'ambiente di test
Gestione dell'ambiente di test
Confronto dell'output dei dati

Test di regressione

In uno sprint, i tester testano il codice nuovo / modificato in quello sprint. Tuttavia, i tester devono anche assicurarsi che il codice sviluppato e testato negli sprint precedenti funzioni anche con il nuovo codice. Pertanto, in Scrum viene data importanza ai test di regressione. I test di regressione automatizzati vengono eseguiti in integrazione continua.

Gestione della configurazione

Nei progetti Scrum viene utilizzato un sistema di gestione della configurazione che utilizza framework di compilazione e test automatizzati. Ciò consente di eseguire ripetutamente analisi statiche e unit test man mano che il nuovo codice viene archiviato nel sistema di gestione della configurazione. Gestisce inoltre l'integrazione continua del nuovo codice con il sistema. I test di regressione automatizzata vengono eseguiti durante l'integrazione continua.

Casi di test manuali, test automatizzati, dati di test, piani di test, strategia di test e altri artefatti di test devono essere controllati dalla versione e devono essere garantite le autorizzazioni di accesso pertinenti. Ciò può essere ottenuto mantenendo gli artefatti di test nel sistema di gestione della configurazione.

Pratiche di test agili

I tester in uno Scrum Team possono seguire le seguenti pratiche Agile:

Pairing- Due membri del team si siedono insieme e lavorano in modo collaborativo. Le due persone possono essere due Tester o un Tester e uno Sviluppatore.
Incremental Test Design - I casi di test vengono sviluppati man mano che gli Sprint progrediscono in modo incrementale e le User Story vengono sommate.

Metriche agili

Durante lo sviluppo del software, la raccolta e l'analisi delle metriche aiutano a migliorare il processo e quindi a ottenere una migliore produttività, risultati di qualità e soddisfazione del cliente. Nello sviluppo basato su Scrum, questo è possibile ei tester devono prestare attenzione alle metriche di cui hanno bisogno.

Vengono suggerite diverse metriche per lo sviluppo di Scrum. Le metriche significative sono:

Ratio of Successful Sprints - (Number of successful Sprints / Total number of Sprints) * 100. Uno Sprint di successo è quello in cui il Team potrebbe mantenere il suo impegno.
Velocity- La velocità di una squadra si basa sulla quantità di punti storia guadagnati da una squadra durante uno sprint. I punti storia sono la misura delle storie utente conteggiate durante la stima.
Focus Factor - (Velocity / Team’s Work Capacity) / 100. Focus Factor è la percentuale dell'impegno del team che si traduce in storie finite.
Estimation Accuracy - (Estimated effort / Actual effort) / 100. L'accuratezza della stima è la capacità del team di stimare accuratamente lo sforzo.
Sprint Burndown- Lavoro (in Story Point o in ore) che è Remaining vs. Lavoro che deve essere rimanente idealmente (secondo la stima).
- Se è di più, significa che il team ha assunto più lavoro di quanto possa fare.
- Se è inferiore, significa che il team non ha effettuato una stima accurata.
Defect Count- Numero di difetti in uno Sprint. Il conteggio dei difetti è la quantità di difetti nel software rispetto al backlog.
Severity of Defects- I difetti possono essere classificati come minori, maggiori e critici in base alla loro gravità. I tester possono definire la categorizzazione.

Retrospettive Sprint

In Sprint Retrospectives, tutti i membri del team parteciperanno. Condividono -

Le cose che sono andate bene
Metrics
Le possibilità di miglioramento
Elementi di azione da applicare

In Agile Testing, i metodi di test comunemente usati derivano dalle pratiche tradizionali e sono allineati al principio - Test Early. I casi di test vengono scritti prima della scrittura del codice. L'enfasi è sulla prevenzione, il rilevamento e la rimozione dei difetti eseguendo i giusti tipi di test al momento giusto e al giusto livello.

In questo capitolo, acquisirai una comprensione dei metodi:

Test Driven Development (TDD)
Sviluppo basato su test di accettazione (ATDD)
Sviluppo guidato dal comportamento (BDD)

Sviluppo basato su test

Nel metodo Test Driven Development (TDD), il codice è sviluppato sulla base dell'approccio Testfirst diretto da Automated Test Case. Un test case viene scritto prima di fallire, il codice viene sviluppato in base a quello per garantire che il test venga superato. Il metodo viene ripetuto, il refactoring viene eseguito tramite lo sviluppo del codice.

TDD può essere compreso con l'aiuto dei seguenti passaggi:

Step 1 - Scrivere un test case per riflettere il comportamento previsto della funzionalità del codice che deve essere scritto.
Step 2- Esegui il test. Il test fallisce poiché il codice non è ancora sviluppato.
Step 3 - Sviluppa codice in base al test case.
Step 4- Esegui di nuovo il test. Questa volta, il test deve essere superato poiché la funzionalità è codificata. Ripetere il passaggio (3) e il passaggio (4) finché il test non viene superato.
Step 5 - Refactoring del codice.
Step 6 - Eseguire nuovamente il test per assicurarsi che venga superato.

Ripetere Step 1 – Step 6aggiunta di casi di test per aggiungere funzionalità. I test aggiunti e quelli precedenti vengono eseguiti ogni volta per garantire che il codice venga eseguito come previsto. Per velocizzare questo processo, i test sono automatizzati.

I test possono essere a livello di unità, integrazione o sistema. È necessario garantire una comunicazione costante tra tester e sviluppatori.

Sviluppo guidato dal test di accettazione

Nel metodo Acceptance Test Driven Development (ATDD), il codice viene sviluppato in base all'approccio test-first diretto da Acceptance Test Case. L'attenzione si concentra sui criteri di accettazione e sui casi di test di accettazione scritti dai tester durante la creazione della User Story in collaborazione con il cliente, gli utenti finali e le parti interessate pertinenti.

Step 1 - Scrivere casi di test di accettazione insieme a storie degli utenti in collaborazione con il cliente e gli utenti.
Step 2 - Definire i criteri di accettazione associati.
Step 3 - Sviluppare il codice in base ai test di accettazione e ai criteri di accettazione.
Step 4 - Eseguire i test di accettazione per assicurarsi che il codice funzioni come previsto.
Step 5- Automatizza i test di accettazione. RipetereStep 3 – Step 5 finché tutte le user story nell'iterazione non sono state implementate.
Step 6 - Automatizza i test di regressione.
Step 7 - Eseguire i test di regressione automatizzati per garantire la regressione continua.

Sviluppo guidato dal comportamento (BDD)

Behaviour Driven Development (BDD) è simile al Test Driven Development (TDD) e l'attenzione è rivolta al test del codice per garantire il comportamento previsto del sistema.

In BDD, viene utilizzato un linguaggio come l'inglese in modo che abbia senso per utenti, tester e sviluppatori. Assicura -

Comunicazione continua tra utenti, tester e sviluppatori.
Trasparenza su ciò che viene sviluppato e testato.

Le tecniche di test dei test tradizionali possono essere utilizzate anche nei test Agile. Oltre a questi, nei progetti Agile vengono utilizzate tecniche e terminologie di test specifiche Agile.

Base di prova

Nei progetti agili, il backlog del prodotto sostituisce i documenti di specifica dei requisiti. I contenuti del product backlog sono normalmente storie di utenti. Anche i requisiti non funzionali vengono presi in considerazione nelle storie degli utenti. Pertanto, la base di prova nei progetti Agile è la user story.

Per garantire test di qualità, anche quanto segue può essere considerato come base di test:

Esperienza da precedenti iterazioni dello stesso progetto o progetti precedenti.
Funzioni esistenti, architettura, design, codice e caratteristiche di qualità del sistema.
Dati difettosi dai progetti attuali e passati.
Opinione del cliente.
Documentazione utente.

Definizione done

La Definizione di Fatto (DoD) è il criterio utilizzato nei progetti Agile per garantire il completamento di un'attività nello Sprint backlog. Il DoD può variare da un team Scrum all'altro, ma dovrebbe essere coerente all'interno di un team.

DoD è un elenco di controllo delle attività necessarie che assicurano l'implementazione di funzioni e caratteristiche in una user story insieme ai requisiti non funzionali che fanno parte della user story. Una user story raggiunge la fase Completato dopo che tutti gli elementi nell'elenco di controllo DoD sono stati completati. Un DoD è condiviso da tutto il team.

Un tipico DoD per una user story può contenere:

Criteri dettagliati di accettazione verificabili
Criteri per garantire la coerenza della User Story con le altre nell'iterazione
Criteri specifici relativi al prodotto
Aspetti del comportamento funzionale
Caratteristiche non funzionali
Interfaces
Requisiti dei dati di prova
Copertura del test
Refactoring
Requisiti di revisione e approvazione

Oltre al DoD per le storie degli utenti, è richiesto anche il DoD:

ad ogni livello di test
per ogni caratteristica
per ogni iterazione
per il rilascio

Informazioni sul test

Un tester deve avere le seguenti informazioni sul test:

Storie degli utenti che devono essere testate
Criteri di accettazione associati
Interfacce di sistema
Ambiente in cui si prevede che il sistema funzioni
Disponibilità degli strumenti
Copertura del test
DoD

Nei progetti Agile, poiché il test non è un'attività sequenziale e i tester dovrebbero lavorare in modalità collaborativa, è responsabilità del tester:

Ottenere le informazioni necessarie sui test su base continuativa.
Identifica le lacune informative che influiscono sui test.
Risolvi le lacune in collaborazione con altri membri del team.
Decidi quando viene raggiunto un livello di test.
Garantire l'esecuzione di test appropriati nei momenti pertinenti.

Progettazione di test funzionali e non funzionali

Nei progetti Agile, è possibile utilizzare le tecniche di test tradizionali, ma l'attenzione è rivolta ai test iniziali. I casi di test devono essere in atto prima dell'inizio dell'implementazione.

Per la progettazione di test funzionali, i tester e gli sviluppatori possono utilizzare le tradizionali tecniche di progettazione di test Black Box come:

Partizionamento di equivalenza
Analisi del valore limite
Tabelle delle decisioni
Transizione di stato
Albero delle classi

Per la progettazione di test non funzionali, poiché anche i requisiti non funzionali fanno parte di ogni user story, le tecniche di progettazione di test black box possono essere utilizzate solo per progettare i casi di test pertinenti.

Test esplorativi

Nei progetti Agile, il tempo è spesso il fattore limitante per l'analisi e la progettazione dei test. In questi casi, le tecniche di test esplorativo possono essere combinate con le tecniche di test tradizionali.

Il test esplorativo (ET) è definito come apprendimento simultaneo, progettazione di test ed esecuzione di test. In Exploratory Testing, il tester controlla attivamente la progettazione dei test mentre vengono eseguiti e utilizza le informazioni ottenute durante i test per progettare nuovi e migliori test.

Il test esplorativo è utile per accogliere i cambiamenti nei progetti Agile.

Test basati sul rischio

Il test basato sul rischio è un test basato sul rischio di fallimento e mitiga i rischi utilizzando tecniche di progettazione del test.

Un rischio di qualità del prodotto può essere definito come un potenziale problema con la qualità del prodotto. I rischi per la qualità del prodotto includono:

Rischi funzionali
Rischi di prestazioni non funzionali
Rischi di usabilità non funzionali

L'analisi del rischio deve essere eseguita per valutare la probabilità (verosimiglianza) e l'impatto di ciascun rischio. Quindi, i rischi sono prioritari:

Rischi elevati richiedono test approfonditi
Rischi bassi richiedono solo test rapidi

I test sono progettati utilizzando tecniche di test appropriate basate sul livello di rischio e sulle caratteristiche di rischio di ciascun rischio. Vengono quindi eseguiti test per mitigare i rischi.

Test di adattamento

I Fit Test sono test di accettazione automatizzati. Gli strumenti Fit e FitNesse possono essere utilizzati per automatizzare i test di accettazione.

FIT utilizza JUnit, ma estende la funzionalità di test. Le tabelle HTML vengono utilizzate per visualizzare i casi di test. Fixture è una classe Java dietro la tabella HTML. L'apparecchiatura prende il contenuto della tabella HTML ed esegue i casi di test sul progetto in fase di test.

Il piano di test viene preparato al momento della pianificazione del rilascio e viene rivisto ad ogni pianificazione dello sprint. Test Plan funge da guida per il processo di test al fine di avere la copertura completa del test.

I contenuti tipici di un piano di test sono:

Strategia di test
Ambiente di test
Copertura del test
Scopo del test
Prova e programma
Strumenti di test

In Agile Projects, tutti i membri del team sono responsabili della qualità del prodotto. Quindi, tutti partecipano anche alla pianificazione dei test.

La responsabilità di un tester è fornire le indicazioni necessarie e guidare il resto del team con la propria esperienza di test.

Storie degli utenti

Le storie degli utenti non stanno testando i prodotti di lavoro in linea di principio. Tuttavia, nei progetti Agile, i tester partecipano alla creazione di User Story. I tester scrivono User Story che apportano valore al cliente e coprono diversi possibili comportamenti del sistema.

I tester assicurano inoltre che tutte le storie degli utenti siano testabili e assicurano i criteri di accettazione.

Test manuali e automatizzati

Durante la prima esecuzione del test, vengono utilizzati i test manuali. Includono:

Test unitari
Test di integrazione
Test funzionali
Test non funzionali
Test di accettazione

I test vengono quindi automatizzati per le esecuzioni successive.

In Test Driven Development, I test unitari vengono scritti prima di fallire, il codice viene sviluppato e testato per garantire il superamento dei test.

In Acceptance Test Driven Development, I test di accettazione vengono scritti prima di fallire, il codice viene sviluppato e testato per garantire il superamento dei test.

In altri metodi di sviluppo, i tester collaborano con il resto del team per garantire la copertura del test.

In tutti i tipi di metodi, avviene l'integrazione continua, che include test di integrazione continua.

Il team può decidere quando e quali test automatizzare. Anche se l'automazione dei test richiede impegno e tempo, i test automatizzati risultanti riducono in modo significativo lo sforzo e il tempo di test ripetitivi durante le iterazioni del progetto Agile. Questo a sua volta facilita il team a prestare maggiore attenzione alle altre attività richieste, come nuove storie utente, modifiche, ecc.

In Scrum, le iterazioni sono time-boxed. Quindi, se un test di User Story non può essere completato in un particolare Sprint, il tester può segnalare nella riunione quotidiana in piedi che la User story non può raggiungere lo Stato di Completato all'interno di quello Sprint e quindi deve essere mantenuta in attesa dello Sprint successivo.

Risultati del test

Poiché la maggior parte dei test nei progetti Agile è automatizzata, gli strumenti generano i log dei risultati dei test necessari. I tester esaminano i registri dei risultati dei test. I risultati del test devono essere mantenuti per ogni sprint / rilascio.

È inoltre possibile preparare un riepilogo del test che contenga:

Ambito del test (cosa è stato testato e cosa non è stato testato)
Analisi dei difetti insieme all'analisi delle cause principali, se possibile
Stato del test di regressione dopo la correzione dei difetti
Problemi e risoluzione corrispondente
Problemi in sospeso, se presenti
Eventuali modifiche richieste in Test Strategy
Metriche di test

Report metriche di test

Nei progetti Agile, le metriche del test includono quanto segue per ogni Sprint:

Sforzo di prova
Verificare l'accuratezza della stima
Copertura del test
Copertura dei test automatizzati
No. di difetti
Tasso di difetti (numero di difetti per punto User Story)
Gravità del difetto
È tempo di correggere un difetto nello stesso sprint (costa 24 volte di più riparare un bug che sfugge allo sprint corrente)
Numero di difetti risolti nello stesso Sprint
Completamento del test di accettazione da parte del cliente all'interno dello Sprint

Sprint Review e rapporti retrospettivi

I tester contribuiscono anche alla Sprint Review e ai rapporti retrospettivi. I contenuti tipici sono:

Metriche di test
Risultati del test I registri esaminano i risultati
Cosa è andato bene e cosa può essere migliorato da Testing Point of View
Migliori pratiche
Lezioni imparate
Issues
Opinione del cliente

Le attività di Agile Testing possono essere gestite in modo efficace utilizzando i concetti Kanban. Quanto segue garantisce che i test vengano completati in tempo all'interno di un'iterazione / sprint e quindi si concentrano sulla consegna di un prodotto di qualità.

Le User Story che possono essere verificate e dimensionate in modo efficace danno luogo a sviluppo e test entro i limiti di tempo specificati.
Il limite WIP (Work-In-Progress) consente di concentrarsi su un numero limitato di storie utente alla volta.
La lavagna Kanban che rappresenta visivamente il flusso di lavoro, aiuta a tenere traccia delle attività di test e dei colli di bottiglia, se presenti.
Il concetto di collaborazione in team Kanban consente la risoluzione dei colli di bottiglia non appena vengono identificati, senza tempi di attesa.
La preparazione anticipata dei casi di test, il mantenimento della suite di test man mano che lo sviluppo progredisce e l'ottenimento del feedback dei clienti aiuta a eliminare i difetti all'interno dell'iterazione / sprint.
Si dice che la Definizione di Fatto (DoD) è Fatto-Fatto nel senso che una Storia raggiunge uno stato di completamento solo dopo che anche il test è stato completato.

Attività di test nello sviluppo del prodotto

Nello sviluppo del prodotto, le versioni possono essere monitorate con la funzionalità Kanban board. Le funzionalità per una particolare versione vengono assegnate alla scheda Kanban delle funzionalità che traccia visivamente lo stato di sviluppo delle funzionalità.

Le funzionalità di una versione sono suddivise in storie e sviluppate all'interno della versione utilizzando un approccio agile.

Le seguenti attività di Agile Testing garantiscono la consegna di qualità in ogni versione e anche alla fine di tutte le versioni:

I tester partecipano alla creazione della User Story e quindi garantiscono:
- Tutti i possibili Comportamenti del Sistema vengono catturati per mezzo delle User Story e dei Requisiti Non Funzionali che fanno parte delle User Story.
- Le storie degli utenti sono testabili.
- Le dimensioni delle User Story consentono di completare lo sviluppo e il test (DoneDone) all'interno dell'iterazione.
Tabellone Kanban attività visiva -
- Raffigura lo stato e l'avanzamento delle attività
- I colli di bottiglia vengono identificati immediatamente non appena si verificano
- Facilita la misurazione del tempo di ciclo che può essere poi ottimizzato
La collaborazione in team aiuta a -
- Responsabilità dell'intero Team per il prodotto di qualità
- Risoluzione dei colli di bottiglia come e quando si verificano, risparmiando tempo di attesa
- Contributo di ogni competenza in tutte le attività
Integrazione continua che si concentra sui test di integrazione continua
Automazione dei test per risparmiare tempo e fatica
Prevenzione dei difetti con casi di test scritti in precedenza per lo sviluppo e supporto agli sviluppatori su ciò che è previsto dai diversi comportamenti del sistema -
- Limite WIP per concentrarsi su un numero limitato di User Story alla volta
Test continui man mano che lo sviluppo avanza, per garantire correzioni di difetti all'interno dell'iterazione -
- Garantire la copertura del test
- Mantieni basso il conteggio dei difetti aperti

Esplorazione della storia

Story Exploration è la comunicazione all'interno di un team Agile per esplorare la comprensione della storia quando il proprietario del prodotto passa una storia per l'accettazione per lo sviluppo.

Il proprietario del prodotto presenta la storia in base alle funzionalità previste dal sistema. Gli sviluppatori esplorano di più ogni storia prima di contrassegnarla come pronta per l'accettazione. I tester partecipano anche alla comunicazione dal punto di vista del test per renderlo il più testabile possibile.

La finalizzazione della Storia si basa su una comunicazione costante e continua tra Product Owner, Sviluppatori e Testers.

Stima

La stima avviene nella pianificazione del rilascio e in ogni pianificazione dell'iterazione.

Nella pianificazione del rilascio, i tester forniscono:

Informazioni su quali attività di test sono richieste
Stima dello sforzo per lo stesso

Nella pianificazione dell'iterazione, i tester contribuiscono a decidere cosa e quante storie possono essere incluse in un'iterazione. La decisione dipende dallo sforzo del test e dalla stima della pianificazione del test. La stima della storia riflette anche la stima del test.

In Kanban, Done-Done si ottiene solo quando una storia viene sviluppata, testata e contrassegnata come completa senza difetti.

Quindi, la stima del test gioca un ruolo importante nella stima della storia.

Pianificazione della storia

La pianificazione della storia inizia dopo che una storia è stata stimata e assegnata all'iterazione corrente.

La pianificazione della storia include le seguenti attività di test:

Preparare i dati del test
Estendi i test di accettazione
Eseguire test manuali
Condurre sessioni di test esplorativi
Automatizza i test di integrazione continua

Oltre a queste attività di test, potrebbero essere necessarie anche altre attività, come:

Test delle prestazioni
Test di regressione
Aggiornamenti dei relativi test di integrazione continua

Progressione della storia

Story Progression scopre ulteriori test richiesti come risultato della comunicazione continua tra sviluppatori e tester. Nelle situazioni in cui gli sviluppatori necessitano di maggiore chiarezza sull'implementazione, i tester eseguono test esplorativi.

Il test continuo viene eseguito durante l'avanzamento della storia e include il test di integrazione continua. L'intero team partecipa alle attività di test.

Accettazione della storia

L'accettazione della storia si verifica quando la storia raggiunge lo stato Completato. cioè, la storia viene sviluppata, testata e segnalata come completa.

Si dice che il test della storia sia completato quando vengono soddisfatti tutti i test rilevanti per il superamento della storia o il livello di automazione del test.

Nei progetti Agile, i tester sono responsabili delle seguenti attività quotidiane:

Supportare gli sviluppatori nella codifica, con chiarimenti sul comportamento previsto del sistema.
Aiuta gli sviluppatori a creare unit test efficaci ed efficienti.
Sviluppa script di automazione.
Integra strumenti / script di test di automazione con l'integrazione continua per i test di regressione.

Per un'implementazione efficace e rapida di queste attività, nella maggior parte dei progetti Agile viene utilizzato un sistema di integrazione continua (CI) che supporta CI di codice e componenti di test.

I tester e gli sviluppatori in progetti agili possono beneficiare di vari strumenti per gestire le sessioni di test e per creare e inviare rapporti sui difetti. Oltre a strumenti specializzati per test agili, i team agili possono anche trarre vantaggio dall'automazione dei test e dagli strumenti di gestione dei test.

Note - Le soluzioni Record-and-Playback, Test-Last, Heavyweight e Test Automation non sono agili in quanto -

L'ultimo flusso di lavoro incoraggiato da tali strumenti non funziona per i team Agile.
Gli script non mantenibili creati con tali strumenti diventano un ostacolo al cambiamento
Tali strumenti specializzati creano la necessità di specialisti dell'automazione dei test e quindi favoriscono i silos

Gli strumenti ampiamente utilizzati sono:

S.No.	Strumento e scopo
1	Hudson CI Framework
2	Selenium Test funzionale - Integrato con Hudson
3	CruiseControl CI Framework
4	Junit Java Unit Test
5	Nunit .Net Unit Test
6	Cobertura / JavaCodeCoverage / JFeature / JCover / Copertura del test Java
7	Jester Java - Test di mutazione / Seeding automatico degli errori
8	Gretel Strumento di monitoraggio della copertura dei test Java
9	TestCocoon C / C ++ o C #: riduce la quantità di test trovando test ridondanti e trova il codice morto
10	JAZZ Java - Copertura di rami, nodi e disinnesco e implementa una GUI, pianificatori di test, strumentazione dinamica e un analizzatore di test
11	Ant Java - Build automazione
12	Nant .Net - Build di automazione
13	Bonfire Componente aggiuntivo Agile Testing per JIRA

Strumenti di automazione dei test agili

Supporto efficace degli strumenti di automazione dei test Agile -

Automazione dei test iniziali utilizzando un approccio test-first.
Scrittura di codice di automazione del test utilizzando linguaggi reali, linguaggi specifici del dominio.
Concentrandosi sul comportamento previsto del sistema.
Separare l'essenza del test dai dettagli di implementazione, rendendolo così indipendente dalla tecnologia.
Promuovere la collaborazione.

I test di unità automatizzati (utilizzando Junit o NUnit) supportano l'approccio test-first per la codifica. Questi sono test white box e assicurano che il design sia corretto e che non ci siano difetti. Tali test vengono creati dagli sviluppatori con il supporto dei tester e possono essere indipendenti dalla funzionalità richiesta. Ciò si traduce nella fornitura di un prodotto che potrebbe non soddisfare i requisiti del cliente e quindi privo di valore aziendale.

Questa preoccupazione viene risolta automatizzando i test di accettazione scritti con la collaborazione del cliente, di altri stakeholder, tester e sviluppatori. I test di accettazione automatizzati sono scritti dai clienti o dai proprietari del prodotto / analisti aziendali che riflettono il comportamento previsto del prodotto. Il coinvolgimento degli sviluppatori garantisce la produzione del codice secondo i requisiti. Tuttavia, se il test si concentra solo sull'accettazione, il codice risultante potrebbe rimanere non estensibile.

Pertanto, i test unitari automatizzati e i test di accettazione automatizzati sono gratuiti ed entrambi sono necessari nello sviluppo agile.

Gli strumenti e i framework Agile che supportano i test di accettazione automatizzati sono:

Fit
Fitnesse
Concordion
Ruby
Cucumber

In forma

Ward Cunningham ha sviluppato lo strumento Fit che può essere utilizzato per l'Acceptance Test Automation. La vestibilità consente:

Clienti o proprietari del prodotto per fornire esempi di comportamento del prodotto utilizzando Microsoft Word e Microsoft Excel
I programmatori per trasformare facilmente questi esempi in test automatizzati.

Fit 1.1 supporta sia Java che .NET.

FitNesse

FitNesse è un wiki, che è uno stile di server web che consente a qualsiasi visitatore di apportare modifiche, inclusa la modifica di pagine esistenti e la creazione di nuove pagine. Un semplice linguaggio di markup ti consente di creare facilmente intestazioni, rendere il testo in grassetto, sottolineato e corsivo, creare elenchi puntati e eseguire altri tipi di formattazione semplice.

In FitNesse, l'automazione del test di accettazione è la seguente:

Esprimere i test come tabelle di dati di input e dati di output previsti.
Usa FitNesse per inserire la tabella di test nella pagina che puoi modificare.
- In alternativa, metti la tabella di prova in Microsoft Excel, copia negli appunti e quindi usa il file Spreadsheet to FitNesse comando per fare in modo che FitNesse formatta correttamente la tabella
Esegui il test
Si ottengono i risultati del test mediante la codifica a colori delle celle nella tabella del test
- le celle verdi rappresentano che si ottengono i valori attesi
- i globuli rossi rappresentano che si ottiene un valore diverso da quello atteso
- le celle gialle indicano che è stata generata un'eccezione

Cetriolo

Cucumber è uno strumento basato sul framework Behaviour Driven Development (BDD). Le caratteristiche principali sono:

Viene utilizzato per scrivere test di accettazione per applicazioni web.
Consente l'automazione della convalida funzionale in un formato facilmente leggibile e comprensibile come l'inglese normale.
È stato implementato in Ruby e poi esteso al framework Java. Entrambi supportano Junit.
Supporta altri linguaggi come Perl, PHP, Python, .Net ecc.
Può essere utilizzato insieme a Selenio, Watir, Capybara, ecc.