I tester dovrebbero automatizzare il loro lavoro?

Stiamo cercando di impostare il nostro processo di test. Ci chiediamo se i nostri tester dovrebbero sviluppare test di regressione automatizzati o se gli sviluppatori dovrebbero farlo.

E gli altri tipi di test automatizzati? I tester dovrebbero svilupparli?

Dico che i tester dovrebbero sviluppare i test automatizzati - hanno l'approccio "al di fuori degli occhi" al codice e individueranno (o dovrebbe essere solo "può"?) Individuare i bug a cui non hai pensato, figuriamoci gestire .

Inoltre, la loro comprensione dei requisiti funzionali potrebbe essere di livello superiore rispetto a quella degli sviluppatori, quindi si colloca tra le conoscenze di basso livello del programmatore, ma non altrettanto elevate di quelle 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 avviso, sviluppatori e tester sono responsabili di diversi tipi di test.

Lo sviluppatore, mentre scrive la logica, dovrebbe anche scrivere test unitari e di integrazione. Ciò consentirà allo sviluppatore di assicurarsi che ciò che ha scritto finora funzioni come previsto. Inoltre, questi test saranno ancora disponibili affinché lo sviluppatore possa eseguire le modifiche future. Una volta completata la logica, lo sviluppatore può essere certo che ciò che è scritto funziona nel momento in cui comprende le specifiche e può passare al tester.

Il tester da 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 degli sviluppatori, ma non viceversa.

Nella mia esperienza, il modo in cui un tester configura ed esegue automaticamente un caso di test differisce in realtà dal modo in cui lo sviluppatore lo fa. I tester penseranno di più su come ottenere il maggior numero di informazioni dal test case, su come eseguire i test rapidamente, su come mantenere i test mantenibili e così via. Soprattutto, i tester vedranno sfumature di copertura dei test che gli sviluppatori mancheranno.

Se le risorse di sviluppo del test sono scarse, gli sviluppatori possono dare una mano, ma un tester dovrebbe rivedere attentamente il loro lavoro. Gli sviluppatori dovrebbero lavorare su dispositivi 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 possono aiutare con i test ha dei vantaggi: espone gli sviluppatori ad altri pezzi del prodotto e i test possono aiutarli a diventare sviluppatori migliori. Tuttavia, proprio come il lavoro di uno sviluppatore junior non passerebbe mai senza una revisione del codice, il lavoro di controllo qualità di uno sviluppatore dovrebbe ottenere una revisione del QA da 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 nei test.

Una cosa che vorrei davvero poter vedere sono i solidi strumenti di automazione per i tester che consentiranno loro di registrare in modo efficace i loro progressi attraverso uno script di test e quindi consentire che lo script venga eseguito automaticamente in futuro. Soprattutto se ciò facilita anche l'esecuzione dello stesso script su diverse versioni del sistema operativo senza che il tester debba esaminarle tutte manualmente.

Sfortunatamente, certamente per il prodotto su cui lavoro, nessuno degli strumenti sul mercato fa proprio il lavoro. Ma vale la pena tenerlo a mente e guardare a 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 stanno semplicemente controllando o stanno testando ?

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

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

Ad esempio, i controlli di unità scritti dagli sviluppatori fungono da rilevatori di modifiche, consentendo di rilevare le regressioni in anticipo quando vengono rieseguite regolarmente: si tratta di test che supportano il team. Controlli di regressione a livello di sistema che sono automatizzati in modo da poter essere rieseguiti regolarmente e rapidamente supportano anche il team rilevando precocemente le regressioni e completando i test unitari effettuati dagli sviluppatori. Ciò consente di risparmiare tempo per i tester per eseguire test che criticano il prodotto, ad esempio test esplorativi. O eventualmente applicare alcuni dei controlli automatici per lo stress test del prodotto.

L'altra cosa che mi piace molto della presentazione di Lisa Crispin che ho collegato è che sottolinea che l'automazione può anche essere usata per supportare i test manuali - creando dati di test, automazione usata per ottenere uno scenario al punto su cui vuoi concentrarti oggi, per esempio.

Considerando che questi due articoli, si spera, ti aiuteranno ad analizzare quale tipo di test vuoi fare, a rendere più facile individuare quale potrebbe essere adatto per l'automazione e capire quali bit di automazione sono più adatti per essere eseguiti dai tester e quali dagli sviluppatori.