Quality Assurance (Testing) in Scrum

How does testing and quality assurance work for scrum? (So that there is very low occurrence of bugs in production.)

In realtà, non penso che SCRUM si occupi di questo. SCRUM non copre tutte le fasi di un prodotto / progetto . SCRUM si occupa principalmente di organizzare lo sviluppo stesso - la parte da "abbiamo un'idea per una funzionalità" a "il team di sviluppo pensa che questa sia pronta per la produzione". Non copre la prima parte di un progetto (idea di base, visione del progetto, ricerca di parti interessate, ottenere un budget ...), e non copre la consegna finale (distribuzione, feedback dei clienti ecc.).

Quindi, se ritieni di aver bisogno di una fase aggiuntiva dopo che il team SCRUM ha terminato, ha una fase separata di test del QA , test di regressione, certificazione, whathever, prima di entrare in produzione.

Hai ancora il valore delle versioni frequenti perché c'è qualcosa da testare e ricevere feedback dagli stakeholder - ma solo perché vuoi un feedback non significa che devi spedire ai clienti (anche se questo è spesso utile). Nota che SCRUM parla di " potenzialmente prodotto disponibile" , perché potresti non voler spedire il prodotto per vari motivi.

Nota: ovviamente, lo svantaggio di una fase di verifica / controllo della qualità separata è che impiegherà più tempo per spedire effettivamente una funzione ai clienti. Tuttavia, se la qualità è più importante della rapida spedizione di nuove funzionalità, allora questo potrebbe essere il giusto compromesso per te - è compito delle parti interessate e degli sviluppatori decidere.

in Scrum ogni storia ha una definizione di Fatto, se una storia è considerata "conclusa" perché soddisfa questa definizione e è pronta per andare in produzione. Se hai errori di produzione frequenti devi lavorare per avere una migliore definizione di fatto e assicurarti che la cronologia soddisfi questa definizione.

Scrum è solo una tecnica di project management leggera, quando la domanda difficile come la tua si presenta normalmente, la mischia non ha risposte concrete. Hai bisogno di trovare quelle risposte in altri metodi agili (come TDD o coppia di programmazione da programmazione estrema). Ad esempio una definizione generica di fatto che tutte le tue cronologie utente devono passare può essere qualcosa del genere:

• Tutti i test di unit test e la copertura sono revisionati
• Il codice è stato rivisto (preferiamo la programmazione a coppie, è solo un esempio)
• La funzione è stata implementata nel server di test
• La funzione è stata rivista dai responsabili del QA.
• Carica il test ok
• ...

Puoi aggiungere quello che vuoi, la chiave è che devi assicurarti che una storia utente che soddisfi questa definizione sia all'altezza della qualità richiesta dal tuo progetto e possa entrare in produzione.

Solo altre due cose sul controllo qualità

• Il personale del QA non può essere una squadra separata, le persone del QA fanno parte del team. Una squadra di mischia ha bisogno di tutte le abilità per soddisfare il DoD.
• Se il tuo test automatico (TDD o meno) non è abbastanza per raggiungere il livello di qualità necessario per pensare a un lavoro migliore con i tuoi test automatici, probabilmente le persone del QA possono aiutarti con questa automazione. Il rilascio rapido non è possibile se hai bisogno di eseguire lunghi test di regressione manuale (giorni forse), scrum non può darti dei rilasci rapidi se non hai un modo automatico (o semi-automatico, ma molto veloce) per assicurarti che qualcosa possa andare alla produzione con il livello di qualità richiesto.

Se stai praticando lo sviluppo basato sui test, scrum può essere privo di bug, nella misura in cui il software rilasciato al tuo team V & V soddisfa tutte le aspettative stabilite dai tuoi test unitari.

Per dirla in altro modo, potresti non essere in grado di certificare che il tuo software è privo di bug, ma puoi certificare che passa tutti i suoi test unitari. I test unitari sono qualcosa su cui un supervisore o un manager possono firmare. Non è una certificazione di livello medico (hai ancora bisogno del QA per questo), ma alleggerisci il tuo team dall'onere di dimostrare uno stato di privo di bug

Quindi, invece di rivendicare software privo di bug su ogni release (un'asserzione che è probabilmente falsa), si dimostra che i Test unitari approvati dimostrano l'affidabilità nell'ambito del loro ambito concordato.

Puoi anche eseguire test funzionali sul software prima di rilasciarlo al QA. Il QA può aiutarti a sviluppare alcuni o tutti quei test.

Ulteriori letture
link

Il Therac 25 è un caso di studio eccellente perché i problemi con il processo di sviluppo (e non molti bug software specifici trovati) sono stati citati come la ragione principale dell'errore.

Secondo la mia esperienza, tutto dipende da quanto sei flessibile a gestire l'intera cosa SCRUM . Se hai bisogno di una versione senza bug, perché non aggiungi uno stage di controllo qualità prima di rilasciare effettivamente il prodotto al cliente?

Il team addetto al controllo qualità decide lì, se è possibile spedirlo al cliente, se è privo di errori. In caso contrario, creeranno segnalazioni di bug per te che potrai affrontare durante il tuo prossimo sprint.