Scrum taskboard con stage QA

Sono un tester dedicato che lavora su un team di Scrum che lavora su un'app web. Quello che facciamo per quanto riguarda le attività di controllo qualità nella bacheca dei compiti, è innanzitutto scegliere le storie degli utenti che devono essere affrontate nello sprint. Quindi suddividiamo queste storie in sotto-attività e aggiungiamo due sotto-compiti per la QA: sviluppare test di accettazione e eseguirli. Generalmente, il compito di sviluppare i test può iniziare immediatamente e in tandem con le attività di engineering, e il compito di eseguire i test di accettazione viene eseguito una volta che il lavoro di ingegneria è stato completato nella storia. Va notato che il team di ingegneri ha anche un'attività di test di accettazione che viene eseguita su una distribuzione di macchine locali, e il team di controllo qualità esegue quindi i test più approfonditi su una distribuzione più vicina alla produzione.

Non è utile per il team addetto al controllo qualità tentare di testare tutte le attività svolte dagli ingegneri, in quanto molte di esse possono essere refactoring o piccole funzionalità che è molto meglio prendere nel loro complesso. Tutti i commit passano comunque attraverso la revisione del codice. Trascorrere molto tempo tra i team di QA e Eng che chiedono come testare le cose e viene detto che la funzionalità è solo sul back-end e non sarebbe visibile all'utente, ecc. Ogni funzionalità è già suddivisa in modo ordinato nelle storie e così queste storie sono le unità di lavoro che vengono testate dal team di QA come parte dello sprint.

L'unico svantaggio di questo approccio è che l'ingegneria può essere lasciata con pochissimo da fare negli ultimi 2/3 giorni di uno sprint, o che possono essere facilmente sopraffatti dagli errori di sprint per risolvere i problemi che potrebbero traboccare prossimo sprint. Tuttavia, abbiamo scoperto che il ciclo di feedback molto breve sulla ricerca di bug (dato che i bug si possono trovare in un solo giorno o due dalla codifica) è molto preferibile ad avere un piano di sprint più pulito ma un ciclo di feedback fino a due settimane.

In realtà sì, il tuo punto di vista è corretto.

Durante lo sprint gli sviluppatori devono verificare che la storia degli utenti completati soddisfi i criteri di accettazione (definizione di fatto). Questo dovrebbe essere fatto scrivendo test automatici. Il proprietario del prodotto deve anche verificare che la storia dell'utente soddisfi realmente le sue aspettative e dopo che è considerata come conclusa e può essere presentata durante la riunione di revisione. Dopo lo sprint hai un incremento del prodotto che puoi spedire e puoi "spedirlo" al QA dove è possibile eseguire test più intensivi, in realtà raccogli feedback perché QA può trovare bug o alcune funzionalità mancanti o incoerenti e inoltrare questo feedback a team o proprietario del prodotto. Il QA può anche fornire un feedback sull'usabilità dell'interfaccia utente.

Il controllo qualità in questo scenario non fa parte del team, ma ciò non significa che il team non testerà il proprio codice! Il controllo qualità agisce come "utente finale" o "cliente" fornendo feedback per l'incremento fornito.

A practical alternative could be that the "To Verify" process should be carried out by another developer in the team, and then to have an additional stage after DONE to QA the whole story (probably after deployment to a stage/test environment).

Does this seem right?

Suppongo che tu stia suggerendo di ridefinire DONE come " Ogni storia è fatta " e aggiungere una nuova colonna chiamata " Prodotto pronto per il rilascio ". Se il team non sta già consegnando una build potenzialmente rilasciabile per ogni sprint, il tuo suggerimento ha molto senso ed è di fatto usato comunemente nelle schede Kanban.

Quindi, cosa succede quando il prodotto NON è pronto per il rilascio? In questa situazione, considera:

1. Creazione di elementi di lavoro per risolvere ogni bug
2. Identifica la storia o le storie che hanno causato quell'errore
3. Annulla lo stato "finito" di quelle storie che in realtà "non sono state fatte"
4. Aggiungi gli errori al backlog per l'assegnazione delle priorità
5. Discuti la causa principale nella retrospettiva

Inoltre, gli sviluppatori sono noti per lo sviluppo fino all'ultimo minuto di ogni iterazione. Ciò rende difficile per " è pronto a rilasciare " i membri del team non di sviluppo a fare il loro lavoro. Kanban aiuta anche qui suggerendo che i team agili eseguono iterazioni di boxe invece di time-boxing. Tuttavia, se ha più senso per il tuo prodotto alle iterazioni time-box, allora potresti essere d'accordo come una squadra di non accettare nuove storie nella successiva iterazione fino a quando non potrai mostrare al cliente che il prodotto è a un livello rilasciabile. Naturalmente, dovrai articolare il PO perché la squadra non è in grado di accettare nuovi lavori.