Revisione paritaria per test come le revisioni del codice

Pratichiamo anche SCRUM. E proprio come te, includiamo anche test funzionali come parte della nostra definizione.

Dalla mia esperienza, lo trovo incredibilmente utile. Abbiamo ridotto significativamente il numero di bug nel nostro codice semplicemente forzando il test funzionale.

Una seconda cosa interessante della revisione del codice è che ti dà un'altra visione delle funzionalità effettive e per assicurarti al 100% che sia in linea con ciò che il cliente / cliente desiderava. Ci sono state alcune volte in cui qualcuno stava passando per il codice e le funzionalità in cui la persona andava ... "Aspetta, non è giusto ..." e si è scoperto che la persona che implementa il codice ho appena frainteso qualcosa.

Buon Dio sì (cerco di non usare le imprecazioni su SO; p). La revisione paritaria dei test funzionali è fondamentalmente una revisione da parte dei pari delle tue esigenze e analisi, è incredibilmente importante e se usi un linguaggio BDD come il cetriolo puoi coinvolgere anche i non programmatori!

È fantastico quando i nostri utenti finali riscontrano problemi con i nostri test funzionali e li fanno sentire enormemente parte del processo di sviluppo "Posso leggere anche il codice !!"

Ha perfettamente senso per me. Qualsiasi codice che scrivi dovrebbe essere guardato da qualcun altro, anche se il codice è utilizzato solo internamente e non verrà mai gestito dal cliente.

Con le metodologie che mettono tanto peso nei test la revisione dei test diventa molto più importante, eventualmente necessaria, a volte più importante della revisione del codice stesso poiché spesso si presume che possa essere sostituito con qualsiasi codice che soddisfi lo stesso risultato dei test automatici.

Riesaminare che i test siano corretti è un aspetto, che sono abbastanza completi e anche accurato / rappresentativo è molto importante.

Manca questo punto è una delle cose che rende queste metodologie un aspetto sciatto per i revisori esterni.

Puoi fare ispezioni di coppia!

Le coppie di controlli sono:

Una revisione dei documenti attivamente e amp; informalmente come parte dell'authoring & ciclo di produzione del documento.

I motivi per cui questo funziona bene con i test sono:

1. Puoi ispezionare frequentemente requisiti o documenti con più di un paio di occhi.
2. Puoi coinvolgere più che semplici sviluppatori: prova BA con Test Lead, BA con PM, BA con Dev.
3. Puoi impostare le riunioni di reticolazione come parte di un processo Agile. Assicurati di essere serio con gli impegni solidi dei membri del team.
4. Puoi utilizzare queste ispezioni di coppia come parte di un esercizio di costruzione di rapporti e di un esercizio di comunicazione con i tuoi stakeholder. Porta avanti la conversazione!

Esaminiamo i test funzionali peer-review almeno casualmente ed è strongmente incoraggiato presso la nostra organizzazione la revisione di tutto il codice.

Consiglierei di scegliere il revisore in base ai tuoi obiettivi per la revisione. I test codificati potrebbero essere esaminati al meglio sia da un dev (principalmente per la qualità del codice) che da un altro tester (principalmente per la copertura del test). I test privi di codice (utilizzando un'imbracatura, ad es. Test basati sui dati) potrebbero essere esaminati al meglio solo da un altro tester. Le recensioni tra pari sono anche un ottimo modo per incoraggiare i tester a imparare gli uni dagli altri.