Risposta.

Implementare l'automazione dei test in un progetto già esistente è un compito complesso e multilivello.

Storia della questione: Nell'organizzazione in cui il test è stato eseguito manualmente per lungo tempo, i processi, la documentazione e l'architettura del codice non sempre soddisfano i requisiti per l'automazione. I tester non possiedono strumenti di automazione e l'architettura dei test e delle applicazioni potrebbe non supportare l'esecuzione rapida dei test automatici.

Problema: Le principali difficoltà nell'implementazione:

Mancanza di cultura dell'automazione: nessuna esperienza, strumenti, processi.
Complessità del codice legacy: difficoltà nell'integrazione dei test, assenza di interfacce testabili e struttura stabile degli elementi.
Mancanza di criteri di priorità: cosa automatizzare per prima e dove questo darà il maggior effetto?

Soluzione: Il team deve attraversare le seguenti fasi:

Valutazione della prontezza: identificare i test manuali più critici e ripetitivi, che porteranno a un risparmio di tempo.
Pilotaggio: scegliere un piccolo blocco del sistema e implementare un set pilota di test automatici per una rapida verifica delle ipotesi.
Implementazione graduale: man mano che il pilota ha successo, ampliare la copertura dei test automatici, formando nel contempo il team sull'automazione.

Caratteristiche chiave:

È vantaggioso iniziare l'automazione con test di regressione e "smoke".
È importante integrare i test automatici nel processo di sviluppo esistente (ad esempio, eseguirli in base alle pull request).
È necessario tenere in considerazione la comunicazione: spiegare al business e ai tester vantaggi e limiti dell'automazione.

Domande insidiose.

I test automatici possono sostituire completamente i test manuali?

No. Anche con un'alta copertura, i test automatici sono applicabili solo a scenari ripetitivi e deterministici. I bug di usabilità non rilevabili, l'explorative testing, i difetti di design e i bug "umani" atipici vengono solitamente catturati manualmente.

Bisogna automatizzare tutti i test case senza eccezione?

No. Non tutti i test case è opportuno automatizzare: scenari a bassa frequenza o complessi sono meglio lasciati per i test manuali a causa del costo e del basso ritorno.

I tester devono necessariamente essere programmatori per un'automazione di successo?

No, ma è auspicabile un livello base di programmazione. Il team viene spesso costruito su una combinazione: tester esperti - architetti di test automatici, automatizzatori - sviluppatori.

Errori tipici e anti-pattern

Tentativo di coprire tutto con l'automazione senza definire priorità.
Comunicazione insufficiente tra tester manuali e automatizzatori.
Scelta degli strumenti "alla moda" invece di quelli adatti al progetto specifico.
Assenza di un processo di supporto e aggiornamento dei test automatici: "eseguiti e dimenticati".

Esempio della vita reale

Caso negativo

L'azienda ha deciso di automatizzare tutti i test manuali contemporaneamente, senza costituire un team separato e senza discutere le priorità. Hanno acquistato uno strumento alla moda, ma non supportava alcuni browser necessari. Di conseguenza, metà dei test ha smesso di funzionare dopo un trimestre.

Vantaggi:

Implementazione iniziale rapida, entusiasmo del team.

Svantaggi:

Costi enormi, delusione arrivata rapidamente, costi di formazione, scarsa copertura degli scenari realmente necessari.

Caso positivo

Il team ha selezionato manualmente i 10 scenari di regressione più frequenti. Hanno condotto formazione sull'automazione in Python (Selenium), aggiunto test in CI. Dopo sei mesi, il 70% dei controlli di regressione veniva eseguito automaticamente, mentre i tester manuali si occupavano della creatività.