is there any start stop boundary qa s role scrum
Qual è il ruolo del QA in Scrum: attività Scrum per i tester
Questo articolo non è solo un tutorial su alcuni processi o metodi o istruzioni su come lavorare come QA. Piuttosto, questo è un articolo in cui voglio condividere la mia esperienza di lavoro come Senior QA in SCRUM.
Il mio precedente CTO lo diceva sempre 'Con la libertà viene la responsabilità'. Se ti viene data la libertà di svolgere il tuo lavoro a modo tuo, allora sei tu e solo tu che sei responsabile del tuo lavoro o dei tuoi compiti o attività.
Questo è ciò di cui parla Scrum !! Lasciate che vi dia un'idea di base su Scrum mentre procediamo oltre.
Cosa imparerai:
Panoramica di Scrum
Scrum è un sottoinsieme di metodologia agile ed è un framework di processo leggero ampiamente utilizzato.
Scrum ci aiuta a mantenere i clienti felici offrendo loro il prodotto in piccoli moduli, ma tiene anche il cliente consapevole che le loro esigenze in costante cambiamento possono rallentare le attività. I rilasci sono brevi e il lavoro viene svolto in base alle capacità del team coinvolto, quindi le possibilità di guasti o di clienti insoddisfatti si riducono in larga misura.
D'altra parte, i requisiti (in questo caso le User Story) vengono finalizzati prima dell'inizio dello Sprint per evitare rielaborazioni e quindi si traduce in Sprint ritardato o fallito (le eccezioni ci sono sempre).
Ma la sfida più grande per un QA è che il periodo di rilascio è breve, uno Sprint è principalmente un ciclo di 15 giorni. Quindi, fornire un prodotto 'gratuito' di bug in un massimo di 4-5 giorni (eliminando il tempo di sviluppo) richiede molti sforzi e un pensiero intelligente.
Sono il QA del mio team:
Oh sì, sono il QA della mia squadra e sono un giocatore importante della mia squadra. Perché?? Perché i clienti, BA, Scrum Master e tutti gli altri sono confusi sulla qualità, l'aspetto grafico e le prestazioni dell'applicazione o del prodotto.
In Scrum, poiché la durata dello sprint è breve, il QA deve funzionare in modo intelligente e quindi la necessità del QA di essere coinvolto fin dall'inizio 'Pianificazione' diventa molto importante. Ci sono momenti in cui un QA può svolgere il ruolo di proprietario di un prodotto proxy quando il PO non è disponibile, aiutando così il BA nella creazione degli scenari / casi di test dei criteri di accettazione.
Gli sviluppatori si rivolgono anche al QA nei momenti in cui incontrano problemi con la funzionalità o le regole aziendali. In Scrum, l'obiettivo è solo avere un rilascio di Sprint fluido e di successo e non si tratta di 'Il mio lavoro' o 'Il tuo lavoro' per dare una mano quando il tuo team si rivolge a te per chiedere aiuto.
Nello Scrum team bonding, le relazioni sane tra i membri del team giocano un ruolo cruciale ed essendo un QA, dovresti stare molto attento mentre comunichi la tua opinione sulle storie degli utenti che stai testando. La tua comunicazione dovrebbe riguardare la storia dell'utente o la funzionalità e non la persona che ci ha lavorato.
In Scrum, il QA non viene giudicato o apprezzato per il numero di bug che scopre ma anche per come interagisce con il team, aiutandolo e motivandolo anche nei momenti difficili.
Oltre a testare le attività di sprint, la scrittura di piani di test / casi di test / documenti di rilascio cerca anche di coinvolgere di più perché la durata del rilascio dello Sprint è breve e l'obiettivo è lo stesso per tutti 'Per fornire un prodotto funzionante senza bug con successo aiutandosi a vicenda'.
Un QA è coinvolto in quasi tutte le attività svolte in uno Sprint e tecnicamente non ci sono limiti per l'inizio o l'arresto delle attività di QA. A differenza del tradizionale modello Waterfall in cui il QA è limitato al solo test del rilascio, qui il QA ha molte più responsabilità. Quindi, suggerirei di provare e svolgere più delle seguenti attività.
Attività da seguire
Di seguito sono riportate alcune attività che ti suggerirei di seguire come QA in Scrum.
come faccio ad aprire un torrent
# 1) Dimora più a fondo:
Con questo, intendo che quando le storie degli utenti ei loro criteri di accettazione sono pronti, studiateli a fondo e pensate più a fondo sulle dipendenze, sui risultati nascosti e se esiste un modo migliore per farlo.
Comunicare e collaborare con il BA e il team di sviluppo su questo perché può accadere che anche loro non abbiano pensato a questo. Condividi le tue idee e i tuoi risultati con il team.
Se scopri che ci sono ostacoli nascosti o impatti negativi, sollevarli con lo Scrum Master e gli sviluppatori darà loro il tempo di pensare e agire di conseguenza. Questa attività in Scrum diventa molto critica quando il progetto è su larga scala e quando ci sono moduli distribuiti tra i team.
Ora, mentre si studiano le dipendenze, un impatto è molto importante per un QA e rende anche il team di sviluppo consapevole dello stesso. Per fare ciò, discuti con i QA degli altri team e prendi input da loro.
# 2) Coinvolgi nelle stime:
La pratica abituale è quella di coinvolgere un QA nelle stime, ma molte volte a causa del piccolo sprint, il QA potrebbe non essere richiesto per la stima per testare le attività e lasciarli con 3/4/5 giorni per il lavoro di test.
Non accettarlo mai. Alza la voce se è necessario, ma assicurati di fornire la stima del test che dovrebbe includere il tempo necessario per ogni lavoro.
Può includere tempo per la ricerca, tempo per le impostazioni, tempo per la raccolta di dati storici, ecc., Ma essere rigorosi e specifici sul tempo necessario per eseguire le attività di test e aggiungere questi valori di tempo alla storia dell'utente insieme al tempo delle attività di sviluppo .
Questo è molto importante perché se provi a svolgere il tuo lavoro nel tempo assegnato e se non sei in grado di completarlo, solo tu sarai responsabile del fallimento. Quando viene aggiunto il tempo QA, lo Scrum Master e il PO saranno a conoscenza delle attività di QA coinvolte e della quantità di tempo richiesta.
# 3) Associazione QA per sviluppatori:
Idealmente, in Scrum, le Sprint User Story vengono consegnate per il test dopo che lo sviluppo è stato completato e una volta che il test di sviluppo è stato fatto, ma il problema qui è che nel momento in cui viene consegnato al QA per i test appena 4-5 giorni alla Demo o alla recensione rimangono.
Ora, se come QA trovi anche 4 blocchi o guasti funzionali, dovrai lavorare a tarda notte o nel fine settimana per rispettare la data di rilascio poiché ci saranno test funzionali, regressioni ecc. Da fare. Questo sembra il tradizionale modello a cascata che non è il modo migliore per farlo, in Scrum il modo più intelligente lo è 'Prevenire i difetti piuttosto che trovare difetti'.
Quindi la soluzione è eseguire l'accoppiamento del QA dello sviluppatore ed eseguire un giro di base di test sulla configurazione dello sviluppatore non appena gli sviluppatori sono pronti con le storie anche prima del rilascio formale per il test.
I seguenti criteri possono essere presi in considerazione per eseguire un BVT sulla configurazione di sviluppo per le storie degli utenti:
- Criteri di accettazione per ogni user story: BVT delle user story secondo i criteri di accettazione.
- Mancanza di fiducia negli sviluppatori: A volte gli sviluppatori non sono sicuri di alcune implementazioni e quindi discutono di tali implementazioni e fanno un BVT per quelli sulla stessa configurazione di sviluppo.
- Dipendenze / Test di impatto: BVT delle dipendenze o impatto su / degli altri moduli delle nuove implementazioni.
- Test unitario: Fai un BVT con lo sviluppatore degli unit test che hanno creato, se necessario aiutali aggiungendo o aggiornando gli unit test.
Ciò contribuirà a ridurre il va e vieni di bug, risparmiando tempo a tutti poiché prima del rilascio al QA la maggior parte dei bug funzionanti o arresti anomali è già stata risolta. Ricordati di registrare questi difetti nei tuoi strumenti prima della revisione dello sprint e di spostarli fino allo stato 'chiuso'.
# 4) QA sulla lavagna bianca:
Ho sempre personalmente incoraggiato il mio team a includere attività di QA nella lavagna White Scrum, inclusi anche i bug. Questo aiuta lo Scrum Master a capire lo stato del QA di una User story semplicemente guardando la lavagna.
Il no. di bug nell'elenco Da fare, i bug nell'elenco In corso, le attività di QA nell'elenco Da fare, In corso e l'elenco Completato parlano da soli. Trovo davvero doloroso quando qualcuno viene a chiedere informazioni sullo stato del test di storie individuali per uno Sprint perché devo dedicare più tempo per estrarre il mio stato dagli strumenti di compilazione e mostrarli o redigere un'e-mail.
Preferisco semplicemente indirizzare la persona alla Scrum Board e lasciare che lo facciano da soli. Preferisci un colore brillante e eccezionale per i foglietti adesivi QA.
# 5) Documentazione:
Questo è uno degli svantaggi o degli svantaggi di Scrum che a causa delle ridotte dimensioni dello Sprint non c'è molto tempo per la documentazione e non ho mai visto un Technical Writer in un team Scrum. Lo Scrum Master / BA non può e non aggiorna sempre i documenti sulle informazioni sul prodotto.
Il problema sorge se nuovi membri si uniscono o, nel peggiore dei casi, se le regole aziendali, le funzionalità cambiano e come tenerne traccia perché cercare informazioni nelle storie degli utenti 'Completate' sarà come cercare un ago in un pagliaio.
La soluzione è avere un'attività separata creata in uno sprint quando possibile (principalmente in tempi di inattività o quando il carico di lavoro è molto inferiore) per la documentazione in modo da poter rivedere i documenti e aggiornarli o fare in modo che lo Scrum Master o il BA li aggiornino.
Un QA è la persona giusta per aiutare nell'aggiornamento dei documenti perché sei tu a testare, verificare le storie degli utenti e conoscere le funzionalità dentro e fuori. Fallo da solo se non c'è BA e se il tuo Scrum Master è impegnato ad aggiornare.
# 6) Sprint Review / Sprint Demo:
Per lo più accade che il QA sia colui che viene scelto per dare la demo al PO e agli stakeholder. ma se non convinci il tuo Scrum Master a farlo. Un QA è la persona giusta per fornire la demo mentre ha testato la user story dentro e fuori.
Un QA può fare una dimostrazione dal punto di vista aziendale perché conosce le funzionalità, i flussi e le regole aziendali. Preparati bene per la demo e cerca di rispondere a tutte le domande poste dal PO e dagli stakeholder. Questo ti aiuterà a diventare il punto di contatto per loro in assenza dello Scrum Master e del BA.
# 7) Agisci come un BA:
Questo non è un compito normale e non ci si aspetta nemmeno da un QA, ma cerca di entrare in questo ruolo quando si presenta un'opportunità perché un QA è la persona migliore per essere un BA. Ad esempio, prova a pensare e visualizzare se i flussi, le funzionalità o le regole aziendali possono essere modificati in modo da avvantaggiare il cliente.
Pensa e cerca le tendenze attuali nell'interfaccia utente, l'aspetto dell'applicazione e come può essere beatificata, resa più user-friendly, ecc. Se il team è bloccato su qualche problema, fatti coinvolgere e prova a dare un semplice e intelligente soluzione. Questo darà una spinta al tuo ruolo e sarà un fattore per contribuire alla crescita della tua carriera.
Le possibilità arrivano durante le chiamate con il PO quando vengono discussi alcuni problemi o in revisione / demo in cui è possibile dare suggerimenti.
Conclusione
Scrum è una metodologia molto diversa dal normale metodo Waterfall e lo Scrum Master è un facilitatore. Quindi non aspettarti che lui / lei definisca le tue attività per te.
In Scrum, non esiste un confine di inizio e di fine per il ruolo di un QA. Il QA ha bisogno e deve essere coinvolto in ogni attività dall'inizio alla fine, dalla Pre-pianificazione fino allo sprint review / demo e deve partecipare a tutte le attività.
Ciò aiuterà a comprendere il prodotto o l'applicazione poiché (come ho detto prima) non è disponibile una documentazione adeguata quando si lavora in Scrum. Ci si aspetta che tu sia responsabile, motivato e proattivo. Quindi non aspettare che qualcuno venga a dirti cosa o come dovresti fare.
Dovresti prendere iniziative da solo, aiutare il team in ogni modo possibile, mantenere una relazione sana, tenere traccia delle cose in corso nel team e, soprattutto, essere chiari sui tuoi compiti in un dato sprint.
Qui non ci sono Manager che ti monitoreranno o terranno traccia delle tue attività. Sii sempre pronto con una mano per la tua squadra e otterrai le migliori opportunità.
Sentiti libero di esprimere i tuoi pensieri / suggerimenti su questo articolo informativo nella sezione commenti qui sotto.
Lettura consigliata
- Ruolo degli analisti aziendali in SCRUM e perché un QA è il migliore per questo ruolo?
- Quiz online su Agile Scrum: prova la tua conoscenza di Agile Scrum
- Installazione dell'applicazione sul dispositivo e avvio del test da Eclipse
- Kanban vs Scrum vs Agile: un confronto dettagliato per trovare le differenze
- Come fornire funzionalità software di alto valore in un breve periodo di tempo utilizzando Agile Scrum Process
- Manifesto Agile: Comprensione dei valori e dei principi Agile
- Valutazione dei difetti in Scrum: come è organizzata in un setup di Scrum
- Migliori strumenti di test del software 2021 (Strumenti di automazione del test QA)