Agile bug fixing - qual è il processo preferito per il test?

Negli ambienti più agili che ho visto, esiste un ambiente integrazione continua . Questo produce nuove build ed esegue una suite di test su quella build su base regolare - dopo ogni check-in nel ramo di integrazione del repository, ogni notte o ogni settimana. Dipende da quanto sono lunghi e complessi i cicli di build / test - potrebbe non essere fattibile farlo molto frequentemente.

In termini di quando una build dovrebbe andare a una persona per il test di accettazione degli utenti, dopo ogni correzione di bug sembra un po 'troppo. Dovresti avere test di unità e di sistema automatizzati che assicurino che le tue build siano abbastanza stabili e per trovare eventuali problemi chiave. Il tempo esatto per eseguire i test di accettazione degli utenti dipende dal numero di bug corretti e dalla lunghezza della tua iterazione. Prima si ottiene un feedback sul lavoro, meglio è, in modo che sia possibile risolvere eventuali problemi con le correzioni o le nuove funzionalità.

La mia raccomandazione sarebbe quella di rendere disponibile una build per i test di accettazione degli utenti il più frequentemente possibile (preferibilmente ogni mattina). Questa build dovrebbe essere già stata sottoposta a test degli sviluppatori e test automatici. I test di accettazione degli utenti devono essere eseguiti tutte le volte che il programma lo consente, ma potrebbe non succedere giornalmente. È necessario notare i rischi di aspettare troppo tardi per il test di accettazione degli utenti - il feedback sul nuovo sviluppo o le correzioni potrebbero dover essere rimandati alla prossima iterazione.

Mi sembra che tu stia mescolando due tipi di test.

Test funzionale è quando controlli le regressioni o che un bug è stato corretto. Questo può essere fatto tramite test automatici o un test manuale da uno sviluppatore. Per esempio. "Funziona la funzionalità X?"

Test di accettazione si verifica quando l'OP verifica che una storia o un'unità di lavoro implementa ciò che è stato chiesto. Questo può anche essere automatizzato ma è semanticamente separato dal precedente. Per esempio. "il software ora mi consente di raggiungere Y?"

A molte persone sembra mancare la differenza tra i due, tuttavia nella mia esperienza c'è un enorme divario e padroneggiare quali sono queste due forme di test sono fondamentali per un progetto di successo.

Gli OP non eseguono test del software. Eseguono un controllo rapido per assicurarsi che il prodotto in fase di sviluppo vada nella direzione corretta. Ciò significa che ci deve essere qualcun altro che si assicuri che il software sia testato. Questo ruolo, tuttavia, dovrebbe a sua volta astenersi completamente dal giudicare dove il prodotto sta andando in termini di caratteristiche.

I progetti che mescolano le due cose tendono a fallire:

• I QA diventeranno mini-PO non selezionati e falliranno in tal senso
• Gli OP non testeranno il tuo software e se lo fanno, perderanno la capacità di giudicare da lontano.

Potresti considerare di avere un ruolo di QA separato per questo. Il QA può dedicarsi al follow up e assicurarsi che funzionino nuove funzioni, che i bug siano corretti come previsto e le suite di regressione mostrano ancora tutto il resto.

Divulgazione: sono in un ruolo di QA che fondamentalmente ho creato per me stesso per affrontare questi problemi.