Qual è la giusta strategia di test nei team Agile Scrum / Kanban?

Sì, testare assolutamente dovrebbe essere parte della definizione di "Fatto". Senza domande.

Da un punto di vista prettamente agile, l'approccio giusto è che tutti i membri del team possano contribuire alla stesura dei test. Il tester sarebbe quello che coordina lo sforzo, ma è responsabilità di tutto il team assicurarsi che il software sia testato correttamente.

In primo luogo, un rapporto di 10: 2 è cattivo. Per esperienza, un rapporto tra sviluppatori 3: 1 o 4: 1 per i tester funziona bene. Probabilmente avrai bisogno di almeno un tester in più, altrimenti il backlog di test crescerà e non verrà mai cancellato, o sarai tagliato da qualche parte.

Se collaudi le attività nel prossimo sprint, stai implementando mini-waterfall o "scrumfall" mentre stai separando i test dallo sviluppo. Hai ragione nel sostenere che i test dovrebbero assolutamente far parte della definizione fatta. Se un'attività non è stata testata, come può essere dichiarata "completata"?

L'approccio corretto sarebbe quindi:

1. Se possibile, aggiungi un tester al team, altrimenti fai eseguire alcuni test agli sviluppatori (anche se probabilmente non faranno un buon lavoro come tester professionista).
2. Modifica la tua tabella scrum / kanban per includere le colonne "pronto per il test" e "in test" e concorda con il team che parte del flusso di lavoro deve avere tutte le attività in queste corsie.
3. Le attività eseguono solo la colonna "Fine" quando sono state accettate dal test.

Questo è abbastanza comune, se non tipico. Per rispondere a quali sono diverse domande:

• Quale dovrebbe essere l'approccio giusto per tenere traccia delle attività in tali scenari?
• Le funzioni verranno eseguite senza QA ma con difetti?
• Come posso tracciare gli sforzi senza problemi?
• I test dovrebbero far parte di "Done Definition"?
• Quali sono le insidie se non lo è?

Vorrei adottare un approccio generale che:

• consente ai tester di aggiungere valore
• fornisce loro l'autorizzazione
• massimizza il loro valore
• incoraggia le persone del QA a formare gli sviluppatori

e per farlo (e rispondere alle tue domande) vorrei:

• assicurati che possano inserire i bug in un sistema di tracciamento dei bug di facile utilizzo che contiene anche funzioni come Jira, Trello, Pivotal Tracker, ecc.

• assicurati che siano addestrati a creare buoni rapporti sui bug che descrivono:

  • passaggi per la riproduzione
  • valori iniziali / di impostazione
  • valori inseriti
  • screenshot quando appropriato
  • registra il server quando appropriato
• assicurati che i bug vengano assegnati, elaborati e completati.
• formali nelle migliori pratiche e inviali alle conferenze.
• addestrarli nella programmazione e nell'uso di un framework di test.
• permetti loro di insegnare ai programmatori i buoni approcci e la mentalità per i test.

Inoltre, sì, alcune funzionalità possono essere eseguite senza QA ma con difetti. Trovo spesso che il QA sia una seconda serie di occhi. A volte questo ruolo può essere riempito da un altro sviluppatore. Personalmente trovo che questo trovi alcuni errori, ma non tutti quelli che una diversa mentalità QA potrebbe trovare.

I test dovrebbero essere parte del lavoro svolto, ma ciò non significa che la persona responsabile del controllo qualità debba eseguire il test. Data la scarsità di risorse e un ambiente Agile che evita le specifiche che il QA può osservare, il QA deve essere coinvolto nell'apprendimento del dominio degli utenti, nelle riunioni di progettazione, nelle riunioni di grooming, standup, retrospettive, ecc.

Per quanto riguarda la grande questione della strategia di test, utilizza i quadranti di test Agile per guidare l'utente:

                   |
      Integrated   |     Performance
_________________________________________
                   |     
           Unit    |     Exploratory

Gli sviluppatori potrebbero già fare test di unità. Un'area chiave su cui il controllo qualità può aggiungere valore mediante la copertura è il test integrato e l'utilizzo dell'automazione dell'interfaccia utente. Anche i buoni test di esplorazione sono molto preziosi: non si tratta solo di cliccare su ogni link della pagina, si tratta di apprendere il dominio degli utenti finali e di cosa significa utilizzare l'applicazione per loro.

Per il rapporto tra QA e tester, considera anche il triangolo di test:

    Exploratory
  Integrated Tests
Individual Unit Tests

per cui un test esplorativo o integrato può rappresentare dozzine se non centinaia di test unitari esercitando l'intero "stack".

Considera anche che, come nei team Agile, generalmente dovrebbe esserci un approccio che chiunque può codificare, chiunque può testare. La chiave del corso è dare alle persone la guida e la struttura in modo che possano fare ciò che è necessario e dare loro formazione per l'altra area.

In termini di proporzioni effettive, non sono d'accordo sulla precisione della risposta di David di 3: 1 o 4: 1 In alcune organizzazioni in cui gli sviluppatori stanno scrivendo buoni test unitari e integrati, potrebbe essere ok 7: 1 in un'organizzazione con pochissimi test eseguiti dagli sviluppatori potrebbe essere necessario 1: 1 Dipende davvero "dall'organizzazione, struttura, conoscenza, industria, ecc. ecc.

Quando abbiamo iniziato a costruire il nostro prodotto , abbiamo implementato anche Kanban e, insieme a questo, abbiamo implementato una strategia completa di automazione dei test. Di conseguenza, oggi non abbiamo tester nel nostro team. Invece, gli sviluppatori devono scrivere casi di test e automatizzarli come parte del lavoro su qualsiasi storia utente, miglioramento o difetto. La nostra definizione di Dev Complete include test unitari e automazione funzionale.

Abbiamo ancora una fase di "Convalida" dopo Dev complete - in cui tutti i nuovi dev work (funzionalità, correzioni di bug) sono distribuiti su un server di staging e qualcuno - chiunque abbia una comprensione funzionale della funzionalità - deve convalidarlo. Usiamo le persone del nostro team di documentazione, nonché la gestione dei prodotti - e talvolta Sr. Engg lead / architects - per validare. Ogni versione deve rimanere almeno 1 settimana in staging prima di essere distribuito in produzione.

Ecco un'istantanea della nostra scheda Kanban -

Il processo e Kanban hanno funzionato per noi. Abbiamo un'automazione di prova quasi al 100%, abbiamo una cadenza di rilascio della produzione di 3-4 settimane e, soprattutto, la maggior parte dei membri del team ha la flessibilità di lavorare su quasi tutte le parti del nostro prodotto!

Quindi, anche se questo potrebbe non soddisfare i tuoi obiettivi a breve termine, potresti sicuramente voler vedere come puoi ristrutturare la tua squadra a lungo termine e se non lo hai già fatto, allora guarda le strategie di automazione del test che potrebbero sicuramente aiutarti il team offre una maggiore qualità a intervalli più brevi.