Valore relativo del test manuale o automatico

Sarei attento quando penso al test "manuale" o al test "automatizzato" in un contesto di ROI (return-on-investment). È una forma di pensiero fallace quando si parla del valore dell'automazione (vedere la sezione "Macchina del tempo" di link).

L'errore di Time Machine riassunto è questo: l'unico modo per determinare realmente il ROI di un approccio di test è avere una macchina del tempo in cui è possibile visitare il futuro e vedere cosa è successo. Dal momento che tu (molto probabilmente) non puoi farlo, le stime del ROI dovrebbero essere viste come euristiche nel migliore dei casi, e non alcune regole difficili. Utilizzare le informazioni correnti per prendere una decisione informata su un determinato sforzo di test è utile o meno per la tua squadra.

Invece, quando si tratta di test, pensa a quali aree del tuo prodotto richiedono maggiore attenzione e dove possono essere i rischi maggiori. Forse è stato identificato che i test di integrazione end-to-end potrebbero trovare più problemi con la tua app. Anche se i test unitari apportano benefici, tali benefici potrebbero non valere i costi associati (acquisizione dello sviluppatore, scrittura e test di esecuzione, ecc.). Allo stesso modo, prova a pensare a benefici / costi invece di vantaggi / svantaggi per i test.

In primo luogo, devi distinguere chiaramente unit test e altri test automatici . Sono due cose diverse, con obiettivi diversi.

I test unitari sono test per convalidare porzioni molto piccole del codice. Si tratta in genere di test in white box, scritti da uno sviluppatore che conosce il codice sorgente "in prova". In TDD, sono scritti in modo test-first, da uno sviluppatore che sta per scrivere il codice sorgente dopo aver scritto il test. Questi tipi di test non possono essere trasferiti a un "test officer" per loro natura, e se la tua organizzazione non è completamente fuorviata, non dovresti chiedere al tuo capo se e quando ti è permesso di scriverli - proprio come non dovresti avere per chiedere al tuo capo se e quando ti è permesso scrivere commenti nel tuo codice sorgente.

Test di integrazione, test di accettazione e altri test black-box sono un'altra cosa. Se hai un ufficiale addetto al test che applicherà questi test solo manualmente, e dovrà ripetere lo stesso tipo di test più e più volte, la necessità di automazione dovrebbe essere richiesta da lui, non da te (ovviamente, dovresti rendi trasparente a lui quali tipi di test puoi automatizzare e quali no). Dovrebbe dirti per quale tipo di test pensa che l'automazione abbia senso, e per quale no. Forse sta andando a fare l'automazione da solo, usando uno strumento di test di regressione, o chiederà il tuo aiuto per creare alcuni strumenti per lui.

Naturalmente, quando pensi che se non è esperto o abbastanza intelligente da arrivare a questa conclusione da solo, dovresti parlargli (e se ciò non aiuta, forse al tuo capo). Tuttavia, IMHO dovresti farlo solo quando hai l'impressione che il tuo responsabile del test sia un collo di bottiglia nella tua produzione a causa della mancanza dell'automazione del test.

Tutti vogliono sempre esempi e studi esterni, ma questi non sono molto efficaci per convincere la direzione. Se il collaudo manuale è davvero un collo di bottiglia per la tua azienda, allora avrai tutti gli interni di cui hai bisogno:

A bug accidentally goes out the door. You state that it used to work and request it get added to the regression tests. Manual tester states it will make regression testing take too long. You offer to make an automated test for it. Manual tester welcomes the idea because he has been feeling overwhelmed and would like more time to focus on the more "interesting" test cases. With the voices of angry customers still ringing in their ears, management starts to see your point about test automation.

Se incontri come questo non accadono nella tua azienda, nessun numero di studi esterni renderà il tuo caso.