Perché la guida di Scrum non dice nessun tester?

Significa che:

1. I tester sono integrati nel team di sviluppo - creazione di strumenti per aiutare gli sviluppatori a testare e testare

   o

2. Il team pratica il Test Driven Development, cioè scrive test automatici che esercitano il sistema.

Ciascuno di questi significa che non è necessario un team di test separato.

In its literal translation this means that there are no testers which is confusing... How can they be suggesting this?

Sì, questo è esattamente ciò che suggeriscono. In altre parole: gli sviluppatori sono i tester e i tester sono gli sviluppatori.

L'idea è di promuovere la proprietà del codice e la qualità .

Questo non significa che il codice non è testato, ma che le persone coinvolte nella scrittura sono quelle coinvolte nel testarlo - non c'è separazione delle responsabilità.

Il problema che questo approccio sta tentando di affrontare è la separazione fin troppo comune tra sviluppatori e tester, in cui gli sviluppatori scriveranno il codice e "buttarlo oltre il muro" all'altra squadra e poi andrà avanti e indietro, ritardando la progetto e produzione di software sub-standard.

La parte fondamentale di questo è che la responsabilità del programmatore è quella di creare codice che funzioni e soddisfi i requisiti. Ciò richiede una particolare mentalità: "Il codice che sto scrivendo fa quello che dovrebbe fare".

Mescolare le responsabilità del codificatore significa che ora al codificatore è richiesto di entrare in altre menti per altre attività, tuttavia, come programmatore, è difficile non riuscire a separare completamente se stessi da quella mentalità.

La responsabilità del tester è quella di trovare bug e luoghi in cui la funzionalità si discosti dalla funzionalità richiesta. Ciò ha richiesto la mentalità di "Il codice è rotto e scoprirò come."

Allo stesso modo, un analista aziendale sta cercando di identificare i requisiti che il cliente sta effettivamente chiedendo. Ciò richiede un'altra mentalità di "l'applicazione non funziona in questo modo, ma dovrebbe."

Affinché un programmatore funzioni in una di queste altre capacità, è ragionevole che la mentalità sia in conflitto e il codificatore preformerà il sotto-par:

• Coder / QA - "Il codice funziona perfettamente, e ho già programmato Gestire ogni possibile modo in cui posso pensare che potrebbe romperlo. "
• Coder / BA - "Il codice dovrebbe funzionare nel modo in cui lo voglio e questi sarebbero cose belle da aggiungere che il cliente non ha pensato.

Questo non vuol dire che ogni coder sia suscettibile a questi problemi (ho incontrato alcuni coder / QA molto dotati ... anche se non per codice che hanno scritto).

Questo si estende anche al team di sviluppo. Mescolare le responsabilità e le mentalità associate di tali responsabilità per un team di sviluppo compromette il prodotto finale (il codice).

Dice che non c'è sub -team dedicato al testing. Ciò non significa che non ci siano test fatti di sorta. Significa solo che i membri del team eseguiranno i propri test e spesso testeranno il codice / le caratteristiche di altre persone. Non ho familiarità con la metodologia scrum, ma andrò su un arto e dire che il client potrebbe anche essere coinvolto nel test.

Penso che questo significhi in parte che devi scrivere test per il tuo codice in modo che tu sappia che funziona (in caso contrario, non lo hai davvero finito) e in parte che potresti essere considerato un tester per altri codice della gente a volte.

Piuttosto che permettere alle persone di scaricare il lavoro di qualità del software su qualcun altro e ignorarlo, questo costringe tutti a pensare al codice che stanno scrivendo da una prospettiva di qualità tutto il tempo, quindi è una buona idea.