Risposta.

Le forme multi-step (wizard, multi-step forms) sono comuni durante la registrazione, la configurazione dell'account e nei lunghi processi aziendali (ad esempio, la richiesta di un prestito o l'ordine di servizi). Il loro test manuale è soggetto a errori e richiede molto tempo; l'automazione qui risparmia risorse e garantisce una copertura di tutti gli scenari "angolari".

Storia della domanda: Sin dall'apparizione dei wizard e delle lunghe forme, tali scenari erano solitamente coperti solo da test manuali. Con l'arrivo di framework come Selenium, Cypress e Playwright è diventato possibile riprodurre automaticamente storie multi-step complesse, aumentando notevolmente la stabilità del software e riducendo il numero di difetti di regressione.

Problema: I wizard e le lunghe forme sono spesso soggetti a modifiche logiche (passaggi che appaiono/scompaiono, condizioni di validazione cambiano, campi dinamici vengono aggiunti). È importante mantenere la stabilità dei test durante tali cambiamenti. I principali problemi includono: fragilità dei localizzatori a causa della natura dinamica dei passaggi, corretta gestione delle transizioni tra passaggi, gestione dei dati di test, simulazione di errori dell'utente, e cliccare scenari non lineari con ritorni e stati variabili.

Soluzione: Viene utilizzato il pattern Step Object (un'estensione del Page Object), che consente di separare la logica di lavoro con ogni passaggio in entità separate. Nei test è fondamentale implementare transizioni per tutti gli scenari possibili, inclusi ritorni e dati errati. Per aumentare la stabilità, vengono impiegati attese dinamiche e metodi di ricerca degli elementi che non dipendono dalla posizione nella pagina. I dati di test vengono strutturati in modo da coprire complessivamente tutte le diramazioni logiche.

Caratteristiche chiave:

Implementazione di Step Object per ogni passaggio.
Verifica non solo dei "percorsi verdi", ma anche di passaggi alternativi ed errati (inserimento di dati errati o al limite).
Uso dell'approccio data-driven: formulazione degli scenari sulla base di un array di dati di test per massimizzare la copertura della logica delle transizioni.

Domande trabocchetto.

Domanda trabocchetto 1

"È sufficiente coprire solo il happy path (scenari utente principali), se la forma è stabile?"

Risposta: No, spesso gli errori si verificano proprio nella gestione di scenari inaspettati — ritorni indietro, salti di passaggi, valori al limite. Senza di essi, i test non forniscono piena sicurezza di stabilità.

Domanda trabocchetto 2

"È possibile implementare transizioni tra passaggi solo tramite il passaggio di URL?"

Risposta: Non sempre. Molti wizard utilizzano rotte dinamiche o sono gestiti solo dallo stato JS interno, quindi è necessario riprodurre clic e interazioni come un utente reale.

Domanda trabocchetto 3

"La gestione dei dati di test non gioca un ruolo significativo, se tutti i passaggi sono obbligatori e statici?"

Risposta: Falso. Anche per forme statiche, diversi riempimenti di dati possono causare risposte completamente diverse, apparizione di suggerimenti, errori, suggerimenti dinamici.

Errori tipici e anti-pattern

Conservare tutta la logica del wizard multi-step in un unico lungo test («monolite»), invece di suddividerlo in passaggi/componenti.
Assenza di generazione di scenari negativi, copertura di casi al limite e ritorni.
Collegamento dei test a localizzatori/posizioni di elementi instabili.

Esempio dalla vita reale

Caso negativo

Nell'automazione del processo della richiesta bancaria, è stato scritto un unico test end-to-end sul happy path, senza ritorni e errori. Quando uno dei passaggi è stato cambiato (aggiunta di un blocco dinamico), il test non solo ha smesso di passare, ma non ha catturato bug nel ritorno al passaggio precedente o nell'elaborazione di dati non validi.

Vantaggi:

Copertura rapida degli scenari principali.

Svantaggi:

Qualsiasi cambiamento nella forma richiedeva la modifica dell'intero lungo test.
Errori critici sfuggivano ai test — specialmente sugli "incroci" e casi rari.

Caso positivo

È stata implementata una struttura Step Object, ogni passaggio era coperto da un test separato, al wizard venivano simulati ritorni, errori, switching tra rami diversi. Tutto era gestito tramite set di dati di test. Nuovi passaggi o cambiamenti non distruggevano il valore della base di test.