Tutorial sulla metodologia di test Scrum
⚡ Riepilogo intelligente
Scrum Testing è un approccio di validazione continua incorporato in Sprint cicli in cui sviluppatori, tester e Product Owner collaborano per verificare i requisiti funzionali e non funzionali, mantenendo trasparenza, adattabilità e rapidità di consegna durante l'intero ciclo di vita del progetto.

Scrum nel test del software
Scrum nel test del software Scrum è una metodologia per la creazione di applicazioni software complesse. Offre soluzioni semplici per l'esecuzione di attività complesse. Scrum aiuta il team di sviluppo a concentrarsi su tutti gli aspetti dello sviluppo del prodotto software, inclusi qualità, prestazioni e usabilità. Garantisce trasparenza, controllo e adattamento durante lo sviluppo del software per evitare complessità.
Test di mischia
Test di mischia Il test viene eseguito nella metodologia Scrum per verificare che i requisiti dell'applicazione software siano soddisfatti. Comprende il controllo di parametri non funzionali come sicurezza, usabilità e prestazioni. Non c'è un ruolo attivo di un tester nel processo, quindi viene solitamente eseguito dagli sviluppatori con i test unitari. A volte sono necessari team di test dedicati a seconda della natura e della complessità del progetto. I team moderni spesso coordinano questo lavoro in Jira, Linear, Azure DevOps, o Asana.
Caratteristiche principali della metodologia Scrum
Di seguito sono elencate le caratteristiche principali di Scrum:
- Scrum ha un programma breve e fisso di cicli di rilascio con ambito regolabile, noto come Sprints, per rispondere alle esigenze di sviluppo in rapida evoluzione. Ogni rilascio può avere più Sprints. Ogni progetto Scrum può avere più cicli di rilascio.
- Una sequenza ripetuta di riunioni, eventi e traguardi.
- Una pratica di test e implementazione di nuovi requisiti, nota come storie, per assicurarsi che alcuni lavori siano pronti per il rilascio dopo ogni Sprint.
Scrum si basa sui seguenti 3 pilastri:
Analizziamoli uno per uno.
1. Ruoli in Scrum
Nel contesto dello Scrum Testing, i tre ruoli principali sono: Product Owner, Scrum Master e Team di Sviluppo. Analizziamoli nel dettaglio.
| Product Owner | Scrum master | Il nostro Team |
|---|---|---|
| È lui o lei a definire le caratteristiche del prodotto. | Questa persona gestisce il team e si occupa della sua produttività. | Il team è generalmente composto da 5 a 9 membri. |
| Il Product Owner decide la data di rilascio e le relative funzionalità. | Questa persona si occupa di mantenere la lista dei blocchi e di rimuovere gli ostacoli allo sviluppo. | Comprende sviluppatori, progettisti e, a volte, collaudatori. |
| Danno priorità alle caratteristiche in base al valore di mercato e alla redditività del prodotto. | Si coordina con tutti i ruoli e le funzioni. | Il team organizza e pianifica il proprio lavoro in autonomia. |
| È responsabile della redditività del prodotto. | Protegge la squadra dalle interferenze esterne. | Ha il diritto di fare tutto entro i limiti del progetto per soddisfare il Sprint obbiettivo. |
| Può accettare o rifiutare i risultati dell'attività. | Inviti allo Daily Scrum, Sprint Revriunioni di visione e pianificazione. | Partecipa attivamente alle cerimonie quotidiane. |
2. Artefatti di mischia
Un processo Scrum include:
- Storie degli utenti: Si tratta di una breve spiegazione delle funzionalità del sistema in fase di test. Ad esempio, per una compagnia assicurativa: "Il premio può essere pagato tramite il sistema online".
- Portafoglio prodotti: Si tratta di una raccolta di user story relative a un prodotto Scrum. Il Product Owner prepara e mantiene il Product Backlog. È prioritario per il Product Owner e chiunque può aggiungervi qualcosa con l'approvazione del Product Owner. I team moderni mantengono il Product Backlog in Jira, Linear, Azure DevOps, o Asana.
- Arretrato di rilascio: Una release è un intervallo di tempo in cui vengono completate diverse iterazioni. Il Product Owner coordina Insieme allo Scrum Master, si decide quali storie includere in una release. Le storie presenti nel Release Backlog sono destinate a essere completate in una release.
- Sprints: Si tratta di un periodo di tempo prestabilito per il completamento delle user story, deciso dal Product Owner e dal team di sviluppo, solitamente di 2-4 settimane.
- Sprint Arretrato: Si tratta di un insieme di storie utente da completare in un Sprint. Durante Sprint Backlog, il lavoro non viene mai assegnato e il team si iscrive al lavoro di sua iniziativa. È di proprietà e gestito dal team mentre il lavoro rimanente stimato viene aggiornato quotidianamente. È l'elenco delle attività che devono essere eseguite in un Sprint.
- Lista di Bloccati: Si tratta di un elenco di blocchi e decisioni non ancora prese, di proprietà dello Scrum Master e aggiornato quotidianamente.
- Grafico del burn-down: Il grafico burndown rappresenta l'avanzamento complessivo del lavoro in corso e del lavoro completato durante l'intero processo. Rappresenta graficamente le storie e le funzionalità non ancora completate.
3. Cerimonie (processi) in Scrum
- Sprint Pianificazione: A Sprint inizia con il team che importa storie dal Release Backlog nel Sprint Backlog; è gestito dallo Scrum Master. I tester stimano lo sforzo necessario per testare le varie storie nel Sprint Arretrato.
- Stand-up giornaliero: Chiamato anche Daily Scrum, è ospitato dallo Scrum Master e dura circa 15 minuti. Durante il Daily Stand-up, i membri discutono del lavoro completato il giorno precedente, del lavoro pianificato per il giorno successivo e dei problemi riscontrati durante un Sprint. Il progresso della squadra è traccolto qui.
- Sprint RevVista / Retrospettiva: È ospitato anche dallo Scrum Master, dura circa 2-4 ore e discute di ciò che il team ha realizzato negli ultimi Sprint e quali lezioni sono state apprese.
Una volta definiti ruoli, artefatti e cerimonie Scrum, è importante chiarire esattamente dove si collocano i tester all'interno di questo framework.
Ruolo del Tester in Scrum
Non esiste un ruolo attivo del Tester nello Scrum processo. Solitamente, i test vengono eseguiti da uno sviluppatore con i test unitari, mentre il Product Owner è spesso coinvolto nel processo di test durante ogni Sprint. Alcuni progetti Scrum dispongono di team di test dedicati, a seconda della natura e della complessità del progetto..
La domanda successiva è: cosa fa un tester in Scrum? La sezione seguente risponderà a questa domanda.
Attività di test in Scrum
Durante le varie fasi di Scrum, i tester svolgono le seguenti attività:
Sprint Pianificazione
- In Sprint In fase di pianificazione, un tester dovrebbe scegliere una user story dal Product Backlog da testare.
- In qualità di tester, dovrebbe decidere quante ore (stima dello sforzo) ci vorranno finire test per ciascuna delle user story selezionate.
- In qualità di tester, deve sapere cosa Sprint gli obiettivi sono.
- In qualità di tester, contribuisci al processo di definizione delle priorità.
Sprint
- Fornire supporto agli sviluppatori nei test unitari.
- Una volta completata, testa la user story. Viene eseguita l'esecuzione del test in un laboratorio dove sia il tester che lo sviluppatore lavorano fianco a fianco. I difetti vengono registrati in un Strumento di gestione dei difetti and tracrilevati quotidianamente. I difetti possono essere discussi e analizzati durante la riunione Scrum. I difetti vengono ritestati non appena vengono rilevati. risoluto e distribuito per i test. I moderni team Scrum in genere utilizzano Jira, Linear, Azure DevOps, o Asana per questo flusso di lavoro.
- In qualità di tester, partecipa a tutte le riunioni giornaliere di stand-up per esprimere la propria opinione.
- In qualità di tester, può portare qualsiasi elemento del backlog che non può essere completato nell'attuale Sprint e metterlo nel prossimo Sprint.
- Il tester è responsabile dello sviluppoping script di automazione. Lui o lei pianifica i test di automazione con un Sistema di integrazione continua (CI).L'automazione assume importanza a causa delle tempistiche di consegna ristrette. L'automazione dei test può essere realizzata utilizzando diversi strumenti open source o a pagamento disponibili sul mercato. Questo si dimostra efficace nel garantire che tutto ciò che deve essere testato venga coperto. Una copertura di test sufficiente può essere raggiunta grazie a una stretta comunicazione all'interno del team.
- RevVisualizza i risultati dell'automazione CI e invia i report alle parti interessate.
- Eseguire test non funzionali per le user story approvate.
- Collaborare con il cliente e il Product Owner per definire i criteri di accettazione per i test di accettazione.
- Alla fine del Sprint, il tester esegue anche test di accettazione (UAT) in alcuni casi e conferma la completezza dei test per l'attuale Sprint.
Sprint Retrospettiva
- In qualità di tester, scoprirà cosa è andato storto e cosa è andato bene nell'attuale Sprint.
- In qualità di tester, individua le lezioni apprese e le migliori pratiche.
Una volta che queste attività di test sono in esecuzione ciascuna SprintI team dipendono da metriche chiare per comunicare i progressi, ed è qui che la reportistica dei test diventa essenziale.
Report di prova
La reportistica delle metriche di test Scrum fornisce trasparenza e visibilità agli stakeholder sul progetto. Le metriche riportate consentono a un team di analizzare i propri progressi e pianificare la strategia futura per migliorare il prodotto. Strumenti come Jira, Linear, Azure DevOps e Asana genera automaticamente molti di questi report. Ci sono due metriche che vengono utilizzate frequentemente per la creazione dei report.
Grafico del burn-down: Ogni giorno, lo Scrum Master registra il lavoro rimanente stimato per il SprintQuesto è il grafico di avanzamento, aggiornato quotidianamente.
Un grafico burndown fornisce una rapida panoramica dell'avanzamento del progetto. Questo grafico contiene informazioni come la quantità totale di lavoro nel progetto che deve essere completato, la quantità di lavoro completato durante ogni Sprint, E così via.
Grafico storico della velocità: Il grafico della cronologia della velocità prevede la velocità che la squadra raggiunge in ogni SprintSi tratta di un grafico a barre che rappresenta l'andamento della produzione del team nel tempo.
Altre metriche che potrebbero essere utili sono: tempo di realizzazione pianificato, tempo di realizzazione del budget, percentuale di completamento del tema, storie completate, storie rimanenti e così via.




