Revisione tra pari per i test, proprio come le recensioni di codice

Qualcuno pratica il processo di "revisione del codice" per i test funzionali? Lo trovi utile? Nel modo in cui il mio attuale datore di lavoro pratica SCRUM, includiamo test funzionali come parte delle nostre cose "indispensabili" in ogni dato sprint.

Pratichiamo anche SCRUM. E come te, includiamo anche i 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 i test funzionali.

Una seconda cosa positiva della revisione del codice è che ti dà un'altra visione della funzionalità effettiva e di assicurarti al 100% che sia in linea con ciò che il cliente / cliente desiderava. Ci sono state alcune volte in cui qualcuno stava esaminando il codice e la funzionalità in cui la persona andava ... "Aspetta, questo non è giusto ..." e si è scoperto che la persona che implementava il codice aveva semplicemente frainteso qualcosa.

Buon cielo sì (cerco di non usare le imprecazioni su SO; p). La revisione tra pari dei tuoi test funzionali è sostanzialmente una revisione tra 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 individuano problemi con i nostri test funzionali e li fanno sentire parte del processo di sviluppo "Riesco a leggere anche il codice !!"

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

Con le metodologie che danno così tanto peso ai test, la revisione dei test diventa molto più importante, forse 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 automatizzato risultato del test.

Revisionare che i test sono corretti è un aspetto, che sono abbastanza completi e accurati / rappresentativi è anche molto importante.

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

Puoi fare ispezioni di coppia!

Le ispezioni di coppia sono:

Una revisione dei documenti attivamente e informalmente come parte del ciclo di creazione e produzione dei documenti.

I motivi per cui questo funziona bene con i test è che:

1. È possibile ispezionare frequentemente requisiti o documenti con più di un paio di occhi.
2. Puoi coinvolgere più di semplici sviluppatori: prova BA con Test Lead, BA con un PM, BA con Dev.
3. Puoi organizzare riunioni di ri-cura come parte di un processo Agile: assicurati di essere serio con gli impegni solidi dei membri del team.
4. È possibile utilizzare queste ispezioni di coppia come parte di un esercizio di costruzione di rapporti e di comunicazione con le parti interessate. Dai inizio alla conversazione!

Revisioniamo i test funzionali almeno per caso, ed è fortemente incoraggiato dalla nostra organizzazione a far rivedere tutto il codice.

Consiglierei di scegliere il tuo revisore in base ai tuoi obiettivi per la recensione. I test codificati potrebbero essere esaminati meglio da uno sviluppatore (principalmente per la qualità del codice) e da un altro tester (principalmente per la copertura dei test). I test senza codice (utilizzando un cablaggio, ad es. Test basati sui dati) potrebbero essere esaminati meglio solo da un altro tester. Le revisioni tra pari sono anche un ottimo modo per incoraggiare i tester ad imparare gli uni dagli altri.