UAT: non vi temo più!

Intervento Teorico-Filosofico

Problema

Contesto

All’inizio della mia carriera mi sono scontrato con il seguente problema: 

l’implementazione dei requisiti da parte del mio gruppo di lavoro non coincideva affatto con quello che l’utente si aspettava. 

Eppure al tempo eravamo certi che quanto era stato realizzato soddisfaceva le richieste dell’utente. Risolvemmo il problema, ma non mi resi conto che quella problematica si sarebbe ripresentata più volte in futuro.

In effetti quello che ancora ad oggi trovo alquanto difficile nel mondo TIC (che per la cronaca indica Tecnologie dell’Informazione e della Comunicazione) è la comunicazione. Non quella digitale ma quella interpersonale perché è interamente incentrata sulle persone. Utenti, sviluppatori e molti altri componenti del gruppo di lavoro che sviluppa programmi (che segua il Manifesto Agile o meno) sono in primo luogo persone. Ed è risaputo che non esistono due persone uguali al mondo.

Ciascuno di noi segue un percorso di vita, professionale e non, tutto suo. Questo aspetto è una cosa meravigliosa poiché ci permette di confrontarsi con diversi punti di vista. Come si fa quindi a realizzare una “simbiosi digitale” tra gli “addetti ai lavori” e utenti? Una risposta ad un tale quesito filosofico è difficile trovarla. Io, nel mio piccolo, mi sono fatto un’idea. Quest’oggi andrò ad illustrare il frammento che riguarda gli User Acceptance Testing (UAT).

Modello

Partiamo innanzitutto con il definire il nostro intento:

dato in ingresso un requisito: produrre in uscita la corrispettiva funzionalità

Per fortuna ad oggi il “produrre in uscita la corrispettiva funzionalità” è un qualcosa di relativamente semplice da realizzare una volta che si sa come padroneggiare i seguenti punti:

• le varie tecnologie (tra i linguaggi di programmazioni con i relativi framework e programmi pronti all’uso ormai vi è solo l’imbarazzo della scelta)
• ed il Domain Driven Design (DDD) (che quasi da 20 anni fa da collante tra il mondo dello sviluppo e quello degli utenti)

Inoltre, grazie all’automatizzazione dei processi di sviluppo dei programmi, il ciclo di prodizione dei programmi è piuttosto breve. Ricordiamo che il Test Driven Development (TDD) fu la pietra miliare posata più di venti anni orsono in tale ambito.

Quello che io invece trovo tuttora alquanto complesso è “dato in ingresso un requisito” perché a seconda

• del gruppo di lavoro,
• dell’azienda,
• della metodologia di sviluppo,
• altro

il requisito ha una forma diversa. Ovvero può assumere una delle seguenti forme:

• user story,
• evento,
• frammento del documento funzionale,
• immagine,
• ticket,
• “disegno sul tovagliolo”,
• altro.

Per la cronaca, il disegno sul tovagliolo fatto all’ora di pranzo, l’ho sempre trovato molto chiaro e conciso.

Difficoltà

Tornando invece alla trattazione generale, La “raccolta del requisito” è dal mio punto di vista uno dei compiti più difficili presenti nell’intera filiera tecnologica perché il requisito per sua natura è soggettivo. Per di più il fallimento o il successo della funzionalità stessa dipende interamente da esso. 

Soluzione

Primo passo

Di certo l’approccio iterativo ed incrementale allo sviluppo dei programmi alleggerisce leggermente questo compito. Tuttavia il problema resta. Quello che fa la differenza tra un requisito “buono” ed uno “cattivo” è la sua oggettività. Questa permette al requisito di essere riproducibile. Se sono in grado di riprodurre una cosa sono in grado anche di comprenderla. Di conseguenza sono in grado di svilupparla.

Ecco che se l’Event Storming ci fa scoprire e comprendere i requisiti, il Behavior Driven Development (BDD) li rende replicabili in maniera automatica. Ed è questa la maniera migliore per iniziare il processo di  trasformazione di un idea in programma applicativo.

Stato dell’arte

Così come il TDD rappresenta lo stato dell’arte nello sviluppo del codice, il BDD rappresenta lo stato dell’arte per quanto concerne la raccolta e gestione dei requisiti. Ed è ad oggi secondo me l’unico approccio che rende la documentazione funzionale viva e vegeta durante tutto il ciclo di vita del programma. Fortunatamente esiste una moltitudine di strumenti per realizzare il BDD. Infatti tra Cucumber, Serenity, SpecFlow e l’ultimo arrivato Gauge vi è solo l’imbarazzo della scelta.

UAT: sono difficili

Tuttavia passare dallo scenario al test vero e proprio non sempre è una cosa semplice. La difficoltà non è legata agli strumenti, ma alla velocità con la quale si possono realizzare i test. Perché quando si ha a che fare con un’Interfaccia Utente, è inevitabile affrontare i “famigerati” UAT. Durante i quali vengono fuori una quantità non indifferente di bug. A me i bug piacciono, ma solo quelli che sono capace di replicare. Escludendo gli strumenti per registrare lo schermo, come questo, ben poco altro si può fare per seguire un UAT. Infatti, per quanto si possa essere bravi e veloci, riprodurre le azioni di un utente è complicato.

Web Browser Recorders

Ma “il mondo è bello perché è vario” ed è pieno di sviluppatori più bravi di me. Infatti pure loro si sono scontrati con questo stesso problema. Però, a differenza mia, alcuni di loro hanno pure realizzato una soluzione chiamata “Web Browser Recorder“. In realtà non credo che questo sia il suo nome ufficiale, ma questa definizione a me piace. I Web Browser Recorders sono dei programmi con una caratteristica unica: trasformano l’azione di un utente in uno script. Trovo sorprendente che siano nati soltanto recentemente. La ragione di ciò è presto detta: eliminano completamente il problema di comunicazione tra persone che

• notificano un bug,
• effettuano l’analisi del bug,
• effettuano il bugfix.

Ergo, se domani avete un UAT assicuratevi di avere a portata di “click” un Web Browser Recorder. Perché può fare davvero la differenza!

Implementazione

Web Test Recorder: si va in scena

Recentemente ho avuto l’occasione di utilizzare uno dei suddetti programmi: Web Test Recorder, basato su Selenium, della TestProject.

excursus

Ora, prima prima di procedere oltre, faccio una precisazione. TestProject è il nome dell’azienda che ha sviluppato Web Test Recorder. Inoltre, con TestProject ci si riferisce alla piattaforma cloud gratuita, di cui Web Test Recorder fa parte. Infine Test Project è diverso da TestProject. Quindi se siete confusi è normale. Io ci ho messo un po’ di tempo per riuscire a capire chi fosse chi. L’importante è che vi teniate a mente questa distinzione. Ci tornerà utile di qui a poco.

E’ il momento di tornare alla trattazione. Ho trovato incredibilmente semplice l’utilizzo di Web Test Recorder. Infatti ci vuole più tempo a leggere lo User Agreement piuttosto che a realizzare il vostro primo test automatico. Nondimeno più si utilizza il Web Test Recorder più ci si rende conto che è pieno di funzionalità.

Vi serve:

• un test di navigazione? Basta fare un click!
• un test di qualità? Sempre un click!
• trasformare lo script in sorgenti di Selenium (Java 😍 o Python o C#)? La via è sempre quella del “click”!
• un altra cosa che non vi viene in mente? La risposta sarà comunque un click!

Infine, cito la  funzionalità che rende il Web Test Recorder “intelligente”: la sua capacità, sia durante la registrazione e/o esecuzione dello script, di sistemare da sé alcuni “noiosi” e frequenti problemi. Infatti, Web Test Recorder possiede in modo nativo TestProject’s AI (Intelligenza Artificiale realizzata da TestProject per in grado di rendere “dinamici” gli script).

Web Test Recorder: dietro le quinte

Fino ad ora, la trattazione si è concentrata sugli aspetti legati all’Esperienza di Utilizzo (UX) da parte degli sviluppatori di Web Test Recorder. Tuttavia agli sviluppatori interessa anche conoscere la compatibilità di uno strumento con il loro status quo. Da questo punto di vista TestProject ha fatto un ottimo lavoro. Infatti una volta installato l’Agent (disponibile per linux, windows e mac), un “banale” eseguibile, non serve fare altro. Nessun driver da ricercare e nemmeno una dipendenza di risolvere. Inoltre lo script generato dal Web Test Recorder non è fine a se stesso. Infatti dal cloud di TestProject o da offline è possibile eseguire gli script in maniera automatica. Tale “esecuzione” come risultato produce un report “*.html” non solo carino, ma pure utile. Difatti da qualunque browser è possibile approfondire gli esiti dei test automatici. Da ciò si può cominciare ad intuire che TestProject in realtà non è sinonimo di Web Test Recorder.

TestProject: la mente dietro a tutto

Infatti, TestProject è una piattaforma, gratuita, in grado di semplificare il processo di creazione e di gestione dei test automatici a 360 gradi. All’interno di TestProject possiamo trovare tutto l’occorrente per “domare” l’automatizzazione. Difatti l’Agent, di cui abbiamo discusso poc’anzi, in realtà contiene molto strumenti al suo interno. Ad esempio ci troviamo il Mobile Test Recorder , fratello del Web Test Recorder, utile per i colleghi che si occupano delle app mobile. Eppure l’Agent, che può essere utilizzato senza il cloud, è solo la punta dell’iceberg. Poiché la piattaforma online offre altre numerose funzionalità per gestire in maniera armoniosa test automatici cross-platform e molti ambiente. Nondimeno TestProject ha una community abbastanza attiva con un blog dedicato che tratta di molti argomenti interessanti che tocca tutti gli aspetti che riguardano l’automatizzazione dei test.

Conclusioni

E’ arrivato il momento di trarre le dovute somme teorico-filosofiche. Web Browser Recorder è di sicuro il tool in grado di farvi cambiare l’idea sulla “drammaticità” degli UAT. Quindi vi consiglio di aggiungerlo quantomeno in “Trial” nel vostro radar tecnologico personale.  Invece TestProject, dall’alto della sua visione a 360 gradi, può fare davvero la differenza per quanto concerne la semplificazione della gestione dei test automatici nella vostra azienda. 

Intervento Concretamente-Pratico

Introduzione

Ora visto che sono pur sempre uno sviluppatore è giusto che faccia qualcosa di concreto. Vediamo quindi di rendere le cose più movimentate realizzando un Hello World con Web Test Recorder. Ragione per la quale se non vi siete ancora addormentati vi propongo un Hello World qui sotto. Ci vorranno dai 5 ai 25 minuti di tempo, tutto dipende dalla vostra velocità nel fare click!

In questo Hello World andremo a verificare se nel capitolo “Supported Environments” della seguente documentazione è presente la seguente stringa di testo: “on any iOS device running version 10 or above”. Per rendere la cosa più interessante faremo pure qualche Test di navigazione.

Prerequisiti

Come prerequisiti è necessario:

• registrarsi alla piattaforma TestProject
• scaricare e installare l’Agent
• avviare l’Agent
• creare un nuovo Project

e avere 5-10 minuti di tempo libero. (Solo alla fine del tutorial scopriremo se sono commutativi con quelli dichiarati sopra)

Ora se va la sentite, ma soprattutto, se non avete rinunciato ad installare il tutto diamo il via alle danze! 💃

Go Live

Preparazione & SetUP

1. Per prima cosa clicchiamo sul pulsante “New Test” presente nella schermata home della piattaforma TestProject. Fin qui è tutto facile.

2. Scegliamo opzione Web (che ci darà la possibilità di utilizzare il fantomatico Web Test Recorder).  Da questa immagine comunque si può intuire che TestProject fa molto altro. No, sai a cosa mi riferisco? Nemmeno io!

3. Proseguiamo cliccando sul tasto “Next“. Eh si questo Hello World sarà Pedante!

4. Come da tradizione del Hello World il nome del nostro test non può che essere: Hello World. Scommetto che te lo ricordi ancora il tuo primo Hello, World!

5. Seguiamo le indicazioni del wizard e clicchiamo su “Next“. Senza termini inglesi è dura la vita. Infatti “Segui il Mago” è più un espressione fiabesca che tecnologica.

6. Ogni test deve essere associato ad un applicazione (che nel nostro caso è web). Cosa più che ragionevole. Quindi clicchiamo su “Web Applications”. Se sei arrivato fin qui hai coraggio!

7. Se non avete ancora censito alcuna web app nel vostro Project, allora la lista delle web app risulterà vuota. Se avete precedentemente registrato delle web app, avreste potuto comodamente sceglierla dall’elenco. Procediamo con la registrazione della nostra web app all’interno della piattaforma TestProject cliccando su “+ Add new application for testing”. Probabilmente stai ancora subendo questo Hello World solo perché vuoi dare un senso al tempo speso per aver letto l’introduzione.8. Inseriamo il nome della nostra web app, che nel nostro caso è: TestProjectIoDocs. Inoltre inseriamo l’URL della nostra Web App, che nel nostro caso è: https://docs.testproject.io/ (p.s. l’URL ci sarà utile in quanto funge da entry point dello Web Test Recorder). Hai visto le freccette verdi? Ti sono state utili? Ci hai fatto caso che la punta della freccia invade in maniera fastidiosa il rettangolo?

9. Proseguiamo avanti cliccando sul tasto “Done”.

10. A questo punto l’unica web app che abbiamo associato al nostro Project è quella che abbiamo appena creato. TestProject lo ha capito da sé e di conseguenza l’ha scelta per noi di default. Proseguiamo avanti cliccando su “Next”. Anche questa passaggio si poteva evitare ma è giusto che facciamo le cose step by step insieme!

11. A questo punto abbiamo finito con la “burocrazia” della piattaforma . Quindi abbiamo correttamente associato il nostro futuro caso di test con la nostra web app. In contesti reali tale funzionalità della piattaforma più che burocratica è cruciale, perché gestire molti casi di test tra progetti diversi non è una cosa semplice. Quindi scegliamo finalmente l’opzione “Record” che ci permetterà di creare il nostro primo caso di test automatico. 

12. Procediamo con la registrazione in modalità file. Ossia la modalità che ci permette di salvare lo script di test sulla nostra macchina. Quindi tutto quello che faremo durante il test verrà salvato offline in un file. Clicchiamo or dunque su “File”.

13. Siamo finalmente pronti per iniziare a fare sul serio. Iniziamo la creazione del nostro caso di test automatizzato cliccando su “Start Recording”.  Manca solo un alto screenshot e potrai fare cose da te!

14. A questo punto se tutto è andato bene dovrebbe comparire la seguente schermata. Ci vorranno un paio di secondi o forse più. Hai mai pensato di mettere una musichetta insieme al Loader in stile ascensore americano? Io si!

Prima di procedere ho una domanda. Vorrei sapere se pure a voi il Loader mentre gira crea qualche emozione? 😎

Go Web Test Recorder, Go!

15. Se tutto è andato bene, ora dovresti avere di fronte a te lo strumento delle meraviglie: il fantomatico Web Test Recorder! Ora ci serve la massima concentrazione perché arriva la parte difficile: creare un test automatizzato! Come avrete notato insieme allo “Web Test Recorder” si è aperta pure un’istanza di Chrome (in modalità automatizzata). Fate attenzione ai click. Infatti qualunque attività (click) noi facciamo nella suddetta istanza di Chrome lo “Web Test Recorder” la “registra”. Con il “registrare” intendo la creazione in tempo reale di uno step automatizzato. Senza annoiarvi con tecnicismi infatti ogni test è composto da una serie di step. Ogni volta che facciamo un’azione possiamo vedere il relativo step realizzato automaticamente in “pancia” allo Web Test Recorder. Si poteva scrivere un paragrafo più corto? Forse…

16. Con massima attenzione, senza cliccare da nessun’altra parte, ignorando quello che lo “Web Test Recorder” vi dice mentre muovete il mouse cliccate su “Cerca” (Immagine sotto). Lo so che mentre muoverai il mouse verrà fuori quel “menù fastidioso”.  Cercate di mantenere la calma. Oggi è il fardello da portare per finire il Hello World.  Vedrete però che domani quel “menù fastidioso” sarà il vostro migliore amico! Se sei ancora sveglio la cosa è notevole!

17. Se tutto è andato a buon fine dopo il click dovrebbe essere comparso nello Web Test Recorder lo Step numero 2 come da illustrazione qui sotto. 

17.b Se vi è partito qualche click extra o avete premuto qualche tasto avrete più step dell’illustrazione precedente. Non vi preoccupate è tutto risolvibile. Infatti gli step possono essere comodamente cancellati: basta posizionarsi con il cursore sullo step e cliccare il tasto “Delete Step”. Ovviamente nei casi in cui avete solo due step, come da illustrazione precedente, potete completamente ignorare questo passaggio. Tuttavia vedrete che a questo passaggio avrete modo di ritornare più avanti. Il tempo perso non ritornerà!

18. Scriviamo nella textbox di ricerca la parola: “Linux”. Non so nemmeno io del perché ho deciso di usare Linux in questo Hello World. Quel che è fatto e fatto.

19. Ora clicchiamo su “Supported Environments” che è il risultato della nostra ricerca. Non sarà una cosa semplice quindi armatevi di pazienza e nel caso fate riferimento al punti 17.b per eliminare gli step in eccesso. Un punto che richiama un punto è come un sogno dentro ad un sogno? 😵

20. Se tutto è andato a buon fine dovresti avere solo 4 Step (come da illustrazione qui sotto). Se ne avete di più: 17.b è la via!

21. Stavolta creiamo uno step non di navigazione (che sono quelli fatti fino ad ora). Infatti creeremo uno step che verifica la qualità del dato. Posizioniamoci con il cursore, senza fare alcun click, sulla sezione che riguarda iOS come da illustrazione. Ci mancava solo il Latino per appesantire la lettura…

24. Cicchiamo su “Contains Text?“. Anche qui molto ci sarebbe da dire ma immagino che hai intuito quello che con il click si ottiene, vero?

25. Se tutto è andato a buon fine è fatta! Abbiamo gli step che ci servono e quindi il nostro primo  test automatico è pronto. Nell’illustrazione sotto è il numero degli step è 6. A questo punto che ne abbiate 5, 7, 8 o 10 poco importa. L’importante è che lo step finale inizi con “Does…..”. Non sempre la perfezione è utile alla causa.

26. In realtà in punto 25 non è un punto, ma un osservazione, ma è giusto così … Torniamo invece al punto corrente. Clicchiamo sul tasto “Pause”. Tale azione ci permette di mettere in pausala registrazione degli eventi. Quindi da questo momento in poi Web Test Recorder non creerà più step . Play, Pause e poi?

27. Ora che abbiamo il nostro test automatico possiamo farlo funzionare. Clicchiamo sul tasto “Run” e stupiamoci della magia della tecnologia! Perché nella tecnologia bisogna credere!

 

28. Lasciate finire lo Web Test Recorder con il test automatico che abbiamo avviato al punto 27. Ora è veramente finita. Tant’è che l’ultima cosa che ci rimane da fare è quello di salvare il nostro test automatico (che poi è uno script) sul file. Basta cliccare su  “Save”. Ecco questa operazione conclude ufficialmente il nostro Hello World. Da qui è tutto, passo la parola al mondo reale.