Che cosa ha causato esattamente il recente aumento dei test automatici?

È una domanda motivata sul motivo per cui vi è un tale aumento percepito dei test automatizzati. Test particolarmente automatizzati eseguiti da sviluppatori, non da tester. I test automatizzati sono vecchi quanto lo sviluppo del software stesso. Potrebbe avere qualcosa a che fare con l'aumento di agile o forse con successo percepito di test automatici presso grandi aziende come Google e Netflix. I manager e le aziende potrebbero iniziare a rendersi conto che è effettivamente più economico investire il 25% degli sviluppatori per creare buoni test automatizzati rispetto al 100% dei tester per testare l'applicazione ogni volta che è necessario il realease.

Una domanda che poni è lo scopo del tester in questo ambiente. Innanzitutto, anche se i tester creano test automatici, i test sono spesso inefficienti. I tester spesso si limitano a interagire con l'applicazione tramite la stessa API utilizzata dall'utente, che di solito è una specie di GUI. E i test che attraversano la GUI sono notoriamente difficili da implementare, lenti da eseguire e facili da interrompere. I tester non hanno accesso alle API degli sviluppatori, né useranno il feedback rapido fornito dai test.

Allo stesso tempo, i tester "facendo clic" passo dopo passo attraverso la GUI per testare secondo un qualche tipo di protocollo di test è quasi immorale. Una volta l'ho sentito paragonato alla tortura moderna. Essendo un lavoro assurdo e monotono, nessuna persona sana di mente vorrebbe qualcun altro.

Invece il compito principale del tester dovrebbe essere quello di rompere effettivamente l'applicazione con nuove idee. Il tester non dovrebbe testare se l'applicazione funziona come funzionava una settimana fa. Questo può essere facilmente automatizzato. Dovrebbe provare se ci sono modi in cui l'applicazione può essere utilizzata per produrre risultati errati o inaspettati. Il tester dovrebbe emulare un utente che non ha letto il manuale e non sa come utilizzare l'applicazione, ma tenta comunque di farlo funzionare in qualche modo.

Oltre alle altre eccellenti risposte, ci sono altri due fattori che ritengo rilevanti qui:

Lo squeeze sul tempo di test

Qualunque sia la metodologia, i test arrivano alla fine della fase di sviluppo. Se lo sviluppo supera, la tentazione è di ridurre la quantità di tempo di test. I test di regressione possono costituire una grande parte di questo, quindi è logico costruirlo nel processo in modo che gli sviluppatori possano eseguirli ad hoc o, meglio ancora, eseguirli con ogni build (dato l'hardware economico attualmente).

L'importanza di fallire presto

Viene letto come letto che è bene "fallire presto" per ragioni economiche. Tuttavia, non è stato molto tempo fa che il ruolo del testing è stato visto come una stravaganza in alcuni ambienti. Qualsiasi bug trovato è stato considerato come un errore di programmazione che potrebbe essere aggirato con programmatori migliori o usando stick o carota per far girare il conto alla rovescia.

Questo errore è fortunatamente svanito con la consapevolezza che programmatori e tester, pur avendo lo stesso obiettivo in mente, hanno mentalità diverse: il programmatore vuole solo qualcosa su cui lavorare mentre il tester non vuole che nulla si rompa.

È avvenuta l'economia del software.

I computer sono diventati sempre più veloci e più economici, mentre salivano i salari. Negli anni '80 era molto spesso meglio assumere qualcuno con competenze minime per svolgere compiti ripetitivi piuttosto che lasciare che un computer lo gestisse, non perché il computer non potesse farlo, ma perché l'hardware e il tempo di calcolo erano rari e preziosi. L'idea di accendere rapidamente un'altra macchina virtuale o persino acquistare un'altra fetta della potenza di calcolo online non esisteva al momento.

La pressione per tagliare i costi è aumentata lentamente attraverso le varie crisi economiche, e allo stesso tempo le persone sono diventate più costose, i computer sono diventati più disponibili fino ad ora sono onnipresenti. Il messaggio ha richiesto un po 'di tempo per raggiungere i decisori più in alto, ma ora viviamo in un'ondata di automazione che non ha ancora raggiunto il picco.

(Si noti che l'economia riguarda i costi marginali e circa i risultati comparativi , non le cifre assolute. È perfettamente possibile per la compensazione umana cadere e ancora non è competitivo perché il prezzo della potenza di calcolo cade ancora più velocemente: per un lungo periodo, questo è esattamente ciò che sta accadendo.)

Couldn't a tester write a script to automate that himself?

No, non potevano. Anche se non sarei d'accordo con il tuo uso di 'recente'.

Nei vecchi tempi un tester sarebbe stato solo un utente esperto del sistema con un lavoro diurno a cui è assegnato il compito di controllare che tutto funzioni come dovrebbe perché "conosce il sistema"

Poi ci siamo spostati su tester dedicati che avrebbero scritto manualmente ed eseguito test case e registrato i risultati.

Ora ci si aspetta che i tester siano in grado di programmare test automatici, la separazione tra tester e programmatore è quasi scomparsa in termini di set di abilità.