I tester dovrebbero automatizzare il loro lavoro?

Dico che i tester dovrebbero sviluppare i test automatici - hanno l'approccio "al di fuori degli occhi" al codice, e (o dovrebbero essere solo "potrebbe"?) individuare bug che non avevate pensato, per non parlare di gestire.

Inoltre, la loro comprensione dei requisiti funzionali potrebbe essere più elevata rispetto alla comprensione degli sviluppatori, quindi stare seduti tra la conoscenza di basso livello del programmatore, ma non di livello elevato rispetto a quella del BA.

Se puoi automatizzarlo, automatizzalo.

Lascia i tester liberi di trovare le cose che non puoi automatizzare. E quando trovano un nuovo bug, se può essere automatizzato e aggiunto ai test automatici, aggiungilo.

A mio parere, sviluppatori e tester sono responsabili per diversi tipi di test.

Lo sviluppatore, mentre scrive la logica, dovrebbe scrivere anche test di unità e integrazione. Ciò consentirà allo sviluppatore di assicurarsi che ciò che hanno scritto fino a quel momento funzioni come previsto. Inoltre, questi test saranno ancora disponibili per l'esecuzione del dev quando eseguono modifiche future. Una volta completata la logica, lo sviluppatore può essere certo che ciò che è scritto funziona nel modo in cui capisce le specifiche e può passare al tester.

Il tester di questo punto dovrebbe essere responsabile della scrittura di test a livello di sistema che assicurino che la logica aziendale funzioni come previsto.

Dato che gli sviluppatori sono spesso troppo attaccati al codice, i tester dovrebbero essere in grado di aiutare a ripulire i test dello sviluppatore, ma non viceversa.

Secondo la mia esperienza, il modo in cui un tester imposta ed esegue automaticamente un test case differisce dal modo in cui lo fa uno sviluppatore. I tester penseranno di più su come ottenere maggiori informazioni dal caso di test, come eseguire rapidamente i test, come mantenere i test mantenibili e così via. La cosa più importante è che i tester vedranno sfumature di copertura del test che gli sviluppatori non vedranno.

Se le risorse di sviluppo del test sono basse, gli sviluppatori possono dare una mano, ma un tester dovrebbe esaminare attentamente il proprio lavoro. Devs dovrebbe lavorare su fixture e strumenti di test prima di scrivere casi di test reali e gli sviluppatori non dovrebbero mai scrivere casi di test per il proprio codice. Avere sviluppatori che aiutano con i test ha vantaggi: espone gli sviluppatori ad altri pezzi del prodotto e il testing può aiutarli a diventare sviluppatori migliori. Tuttavia, proprio come il lavoro di uno sviluppatore junior non andrebbe mai senza una revisione del codice, il lavoro di QA di uno sviluppatore dovrebbe ottenere una revisione del QA da parte di qualcuno con più esperienza di test.

Modificato per aggiungere: Sono un SDET con 5 anni di esperienza. Lavoro con grandi sviluppatori con oltre 10 anni di esperienza ciascuno, e ultimamente ho lavorato con loro per superare un collo di bottiglia di prova.

Una cosa che vorrei davvero essere in grado di vedere sono solidi strumenti di automazione per i tester che permetteranno loro di registrare efficacemente i loro progressi attraverso uno script di test e quindi permettere che lo script venga eseguito automaticamente in futuro. Soprattutto se questo facilita anche lo stesso script che viene eseguito su diverse versioni del sistema operativo senza che il tester debba esaminarle tutte a mano.

Sfortunatamente, certamente per il prodotto su cui lavoro, nessuno degli strumenti sul mercato fa abbastanza il lavoro. Ma vale la pena tenerlo a mente e guardare ciò che è disponibile sul mercato nel caso in cui ci sia qualcosa che potrebbe funzionare per quello che stai facendo.

Una distinzione fondamentale che è davvero importante qui è questa: i tuoi tester semplicemente controllano , o sono test ?

Questo post di blog di Michael Bolton lo spiega meglio, ma in sostanza: stanno cercando semplicemente di confermare il comportamento o stanno cercando problemi con il sistema?

Penso che sia utile considerare anche i quadranti di test di agilità (Brian Marick li ha descritti originariamente, ma li ho incontrati nel libro "Agile Testing" di Lisa Crispin e Janet Gregory: anche se non stai seguendo una metodologia di sviluppo Agile, penso che la distinzione tra test che criticano il prodotto e test che supportano il team sia davvero utile quando si considera l'automazione, e cercando di sviluppare un piano per chi fa cosa e perché.

Ad esempio, i controlli unitari scritti dagli sviluppatori fungono da rilevatori di modifiche, consentendo di rilevare le regressioni in anticipo quando vengono ripetute regolarmente: si tratta di test che supportano il team. Controlli di regressione a livello di sistema che sono automatizzati in modo che possano essere eseguiti regolarmente e rapidamente supportano anche il team ottenendo regressioni in anticipo e completano i test unitari effettuati dagli sviluppatori. Ciò consente ai tuoi tester di non sottoporsi a test che criticano il prodotto, ad esempio i test di esplorazione. O eventualmente applicando alcuni dei controlli automatici per testare il prodotto.

L'altra cosa che mi piace davvero della presentazione di Lisa Crispin che ho collegato è che sottolinea che l'automazione può essere utilizzata anche per supportare il test manuale - creare dati di test, l'automazione utilizzata per ottenere uno scenario al punto che si desidera mettere a fuoco oggi, per esempio.

Considerando questi due articoli si spera che ti aiutino ad analizzare che tipo di test vuoi fare, rendere più facile individuare ciò che potrebbe essere adatto all'automazione e capire quali parti dell'automazione sono più adatte per essere eseguite dai tester e quali dagli sviluppatori.