Risposta.

Nel tempo, il testing manuale si è adattato a metodologie agili come Scrum. Inizialmente, i tester lavoravano "alla fine dello sprint", testando il risultato complessivo del lavoro. Questo portava spesso a situazioni di emergenza e test insufficienti (storia).

Il problema principale è la mancanza di tempo per il testing, frequenti cambiamenti nei requisiti e compiti che non raggiungono i tester durante lo sprint. I tester si trovano sotto pressione, il che riduce la qualità (problema).

La soluzione è integrare i tester nel team sin dall'inizio dello sprint: partecipare alle riunioni, pianificare i test case man mano che emergono nuove attività, organizzare insieme daily standup e retrospettive, e contribuire ad aumentare la trasparenza dello stato degli artefatti di testing (soluzione).

Caratteristiche principali:

Coinvolgimento costante del QA in tutte le fasi dello sprint
Aggiornamento e pianificazione regolare dei test case ‘on-the-fly’
Collaborazione con gli sviluppatori nella definizione della prontezza delle attività per il test

Domande fuorvianti.

È possibile iniziare a testare solo dopo il completamento di tutte le attività dello sprint?

No, il tester dovrebbe essere coinvolto sin dai primi giorni dello sprint e, se possibile, testare funzionalità non completamente completate.

Tutti i bug devono essere corretti nello sprint corrente?

Non necessariamente, i bug critici sì, quelli non critici possono essere trasferiti nel backlog esterno e corretti nel successivo sprint.

È necessario il testing manuale in presenza di automazione in Scrum?

Sì, il testing manuale è critico per la verifica di nuove funzionalità e requisiti non formalizzati, oltre che per il testing esplorativo.

Errori comuni e anti-pattern

Attivazione tardiva del testing
Mancanza di documentazione per le nuove funzionalità all'inizio
Ignorare la comunicazione e le riunioni di team

Esempio dalla vita reale

Caso negativo

Il tester non ha partecipato alla pianificazione e non aveva accesso a nuove storie di attività fino alla fine dello sprint. Di conseguenza, i test sono stati scritti in fretta e parte dei bug sono stati trasferiti agli sprint successivi.

Pro:

Meno riunioni per il tester

Contro:

Errori in produzione, insoddisfazione dei clienti, bassa copertura

Caso positivo

Il tester si è unito al team sin dai primi giorni dello sprint, ha partecipato alle riunioni, ha visto in anticipo le attività emergenti e ha pianificato i test parallelamente allo sviluppo.