La revisione del codice è in ritardo rispetto al ciclo di consegna / test

I tester non vogliono ripetere il test è come dire "i programmatori non vogliono refactoring". Fa parte del lavoro. Il processo può essere riformulato come qualcosa di simile: Le attività vengono create. Il codice è generato Il codice è testato Il codice è revisionato. Le imperfezioni si trovano nel codice. Nuovi compiti sono creati per affrontare queste imperfezioni (ad esempio il codice è refactored). Queste nuove attività richiedono nuovi test.

Se hai intenzione di rivedere il codice a un certo punto, non è più costoso effettuare la revisione in anticipo. E sembra che tu abbia un processo di test costoso, quindi non vuoi testare due volte. Pertanto è più economico rivedere il codice prima di testare. Revisionare il codice dopo i test non fa andare più veloce il lavoro. Rende più lento e ti spinge a consegnare codice scritto male ma testato con successo. Nel corso del tempo tutto questo codice non revisionato renderà il lavoro più lento e lento. Quindi un concorrente più efficiente offre un prodotto migliore a costi inferiori ed è game over.

Inoltre, automatizza i test. Il test manuale è così del 1970.

Se hai difficoltà a far sì che le revisioni del codice avvengano nel tempo che hai attualmente prima del controllo qualità, dovresti prendere in considerazione la possibilità di rendere più leggere le revisioni del codice, come Code Review in Agile Teams, Parte II che @Dukeling ha pubblicato discute.

Ho scoperto che anche la cosa più semplice che potrebbe essere chiamata revisione del codice ha dato dei vantaggi: prima di eseguire il codice (o di inserire un DVCS), chiama un altro sviluppatore e passa loro le modifiche. Questo potrebbe richiedere cinque o dieci minuti. L'obiettivo di questa revisione del codice è "Questo ha senso per l'altro sviluppatore?" L'obiettivo non era quello di snellire le implementazioni di progettazione o di conformarsi completamente alle idee personali del recensore su come avrebbe dovuto essere scritto. Ha dato questi benefici:

• Conoscenza condivisa migliorata del funzionamento del codice
• Catturato codice confuso o potenzialmente errato perché l'atto di spiegare il codice era sufficiente a far ripensare l'autore
• Aiutato a sviluppare gradualmente gli idiomi e lo stile del team, perché rendeva più facile spiegare le cose
• Poche lamentele dal team

Le recensioni dei codici più approfondite funzionano assolutamente meglio per trovare i problemi. Ma devi essere in grado di eseguirli e agire di conseguenza per ottenere il valore. Un processo leggero che puoi fare tutto il tempo può essere più utile di un processo pesante che continua a essere rimandato o semplicemente aggiunge elementi al backlog.

Una soluzione a questo problema è fare una rapida revisione del codice da parte di un altro peer una volta che la storia di un utente è terminata, in modo che non ci siano errori di base / ovvi nel codice.

Ma questo deve accadere prima del ciclo di test. Quindi ci saranno meno modifiche al codice dopo il test, quando si effettuano revisioni più ampie con tutto il team.

Dai suoni di esso i tester non vogliono ripetere il test perché il test è un processo doloroso / costoso.

Controllare l'automazione sia da sviluppatori che da tester è un enorme vantaggio per i team che cercano di lavorare in modo agile. I test più economici, più facili e più riproducibili sono quindi più li puoi eseguire - e meno resistenza potrai cambiare qualcosa.

Fatto un refactor veloce basato su qualche feedback di sviluppo? Premi il grande pulsante rosso che esegue la tua suite di regressione / fumo e fai una rapida operazione manuale per verificare eventuali problemi visivi che potrebbero essersi verificati. Facile!

Una volta che sei in un posto del genere, ripetere i test non sarà un compito ingrato, sarà una seconda natura.