Perché la guida Scrum non dice tester?

Ho letto la Scrum Guide da scrum.org e dice:

I team di sviluppo non contengono sotto-team dedicati a domini particolari come test o analisi di business.

Nella sua traduzione letterale questo significa che non ci sono tester che sono fonte di confusione. Come possono suggerire questo?

Significa che:

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

   o:

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

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

Nella sua traduzione letterale questo significa che non ci sono tester che confondono ... Come possono suggerire questo?

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à e la qualità del codice .

Ciò non significa che il codice non sia testato, ma che le persone coinvolte nella sua scrittura siano quelle coinvolte nella verifica: non vi è alcuna separazione delle responsabilità.

Il problema che questo approccio sta cercando di affrontare è la separazione fin troppo comune tra sviluppatori e tester, in cui gli sviluppatori scriveranno il codice e "lo lanceranno oltre il muro" all'altro team e poi andrà avanti e indietro, ritardando il progetto e producendo software sub-standard.

La parte fondamentale di ciò è 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 programmatore significa che al programmatore è ora richiesto di inserire altre mentalità per altre attività, tuttavia, come programmatore, è difficile impossibile divorziare completamente se stessi da quella mentalità.

La responsabilità del tester è quella di trovare bug e luoghi in cui la funzionalità si discosta 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 richiesti dal cliente. Ciò richiede un'altra mentalità di "l'applicazione non funziona in questo modo, ma dovrebbe".

Affinché un programmatore funzioni in una qualsiasi di quelle altre capacità, esiste una ragionevole probabilità che le mentalità siano in conflitto e che il programmatore eseguirà un sottoparagrafo:

• Coder / QA - "Il codice funziona perfettamente e ho già programmato per gestire ogni possibile modo in cui riesco a pensare che potrebbe romperlo."
• Coder / BA - "Il codice dovrebbe funzionare nel modo in cui lo desidero e queste sarebbero cose interessanti da aggiungere a cui il cliente non ha pensato.

Questo non vuol dire che ogni programmatore sia sensibile a questi problemi (ho incontrato alcuni programmatori / tipi di QA molto dotati ... anche se non per il codice che hanno scritto).

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

Dice che non esiste un sub- team dedicato ai test. Ciò non significa che non siano stati effettuati test di sorta. Significa solo che i membri del team eseguiranno i propri test e spesso testeranno il codice / le funzionalità di altre persone. Non ho familiarità con la metodologia Scrum, ma andrò su un arto e dirò che anche il cliente potrebbe essere coinvolto nei test.

Penso che questo in parte significhi che dovresti scrivere test per il tuo codice in modo che tu sappia che funziona (in caso contrario, non l'hai davvero finito) e in parte che potresti aspettarti di essere un tester per il codice di altre persone a volte .

Piuttosto che consentire 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 sempre da una prospettiva di qualità, quindi è una buona idea.

Questa affermazione sta fondamentalmente cercando di evitare di lavorare senza problemi. Una parte della soluzione a questo è pratiche come: Test Driven Development - Pair Programming - Pull Requests - Test automation e simili che rendono tutti i test una parte intrinseca del processo di sviluppo piuttosto che qualcosa che viene fatto isolatamente sul lato o 'dopo'.

Inoltre, ci sono discorsi molto limitati sui ruoli nella Guida Scrum. In realtà, parlano del team di sviluppo. Quello che vogliono dire è che vuoi un forte team interfunzionale. Ciò significa che, a seconda delle esigenze dei tuoi progetti, hai bisogno di una serie di competenze, come UX, BA, QA / Tester, Ops, Coder, ecc ecc, ma se questo è uno o più individui che li riguardano, non importa davvero.

I team con cui lavoro hanno sicuramente un ruolo di controllo qualità, poiché abbiamo persone DevOps. Ma sono tutti anche sviluppatori, solo con specializzazione in queste aree. Il trucco è davvero quello di non cadere nei silos e lavorare in isolamento.

Ciò non significa necessariamente che non ci siano tester. Può darsi che un team Scrum abbia tester dedicati oppure no.

Per me, ciò che questa affermazione su Scrum significa è che dovresti pensare all'intera pipeline di consegna come un singolo team. Far parte della stessa squadra suggerisce alcune cose:

1. C'è una singola stima su una storia / bug / attività. Non esiste una stima degli sviluppatori e una stima del test.
2. Il team non stima una storia e si impegna ad essa senza il tester presente.
3. Se qualcosa va storto, non è più colpa del tester che colpa dello sviluppatore. È colpa della squadra .
4. Il team non ha mai bisogno di prendere in prestito, richiedere o chiedere tester.
5. Il test fa parte della definizione di done. Il lavoro non testato è un lavoro incompleto.
6. Gli sviluppatori dovrebbero considerare la testabilità mentre progettano il loro codice.

Se lavorano insieme in una sola squadra, allora la squadra ha successo insieme e fallisce insieme. Ho fatto parte di un team Scrum di grande successo che aveva diversi tester. I tester erano presenti durante tutti gli standup, le sessioni di preparazione, la pianificazione, ecc. Se non fosse chiaro come testare una storia, il team non si sarebbe impegnato. Durante la stima abbiamo sempre parlato con i nostri tester.

Potenziali segni che potresti non considerare i tester come parte del team di consegna, anche se pensi di fare:

1. I tester hanno un "QA standup" (sì, l'ho visto).
2. I tester hanno una struttura di gestione separata.
3. Hai un controllo di qualità.
4. Ti affidi fortemente ai test end-to-end.
5. I test vengono scritti il ​​seguente sprint.
6. La maggior parte dei test ha luogo l'ultimo giorno dello sprint.

Questi sono soggettivi e non necessariamente sbagliati. Sono bandiere rosse però, secondo me.

Detto questo, è del tutto possibile avere un team Scrum senza nessuno che abbia un ruolo designato di tester. Anche questo può funzionare bene. Soprattutto se automatizzi i test. Anche il TDD aiuta.