Test automatizzati per il checkout del negozio online

Il nostro negozio viene aggiornato quasi ogni settimana e dopo quasi ogni aggiornamento qualcosa si rompe silenziosamente lungo il percorso verso l'ordine. Un codice promozionale smette di applicarsi, il costo di consegna scompare dal totale, il passaggio di pagamento riporta il cliente a un carrello vuoto. Lo scopriamo dai compratori che scrivono al supporto — che è il modo più costoso per scoprire che il checkout è rotto, perché per ogni persona che scrive ce ne sono diverse che semplicemente se ne vanno. Controllare manualmente dopo ogni modifica non è realistico: non c'è nessuno nel team con un'ora libera per farlo, e dopo il terzo rilascio consecutivo la persona che controlla smette di guardare attentamente.

Quello che voglio è un insieme di scenari automatizzati che seguono lo stesso percorso di un cliente reale. Dalla scheda prodotto a un ordine pagato: aggiungere al carrello, cambiare quantità e rimuovere un articolo, applicare e annullare un codice promozionale, scegliere tra metodi di consegna e vedere il totale ricalcolare, registrazione e accesso con una password errata tra i casi, e l'account personale successivamente — cronologia ordini, indirizzi salvati, ripetere un ordine precedente. Il layout mobile ha bisogno dei propri scenari, non di una copia ridimensionata di quelli desktop: la maggior parte dei nostri ordini viene effettuata da telefoni, ed è proprio lì che il carrello di solito si rompe per primo. Tutto deve avviarsi da solo su ogni build, senza che nessuno si ricordi di premere un pulsante.

Il rapporto è importante tanto quanto i test. Un manager dovrebbe essere in grado di leggerlo senza chiedere a un ingegnere: quale scenario è fallito, a quale passo, cosa c'era sullo schermo in quel momento e com'era l'esecuzione — uno screenshot del punto di fallimento e una registrazione video del test fallito. Ho anche bisogno di istruzioni scritte per i nostri sviluppatori, in modo che aggiungere un nuovo scenario in seguito sia un compito normale e non un progetto di archeologia.

Condizioni che dichiaro in anticipo: i test vengono eseguiti nell'ambiente di staging con una chiave di pagamento di test, i pagamenti reali non vengono mai effettuati; gli ordini di test non devono raggiungere la contabilità e la reportistica del negozio; un test che fallisce ogni altra esecuzione deve essere corretto o eliminato — un test inaffidabile è peggio di nessun test, perché le persone smettono di leggerlo.

Cosa mi aspetto di ricevere:
— scenari end-to-end dalla scheda prodotto all'ordine pagato, inclusi codici promozionali e opzioni di consegna;
— scenari di registrazione, accesso e account personale;
— un insieme separato di scenari per il layout mobile;
— avvio automatico dell'intero pacchetto su ogni build, con un chiaro risultato di passaggio o fallimento;
— un rapporto leggibile da un non ingegnere, con uno screenshot del passo fallito;
— registrazione video di ogni esecuzione fallita, conservata a lungo abbastanza per indagarla;
— istruzioni scritte per i nostri sviluppatori su come aggiungere e mantenere scenari;
— una breve sessione di passaggio in modo che il team possa eseguire ed estendere il pacchetto da solo.