3 Casi Reali in cui i Test di UAT hanno fatto la differenza

In Application Performance ci occupiamo di testare le applicazioni e monitorare le loro performance nel tempo. Ciò implica lo sviluppo di test funzionali automatizzati, test di performance e, sempre più frequentemente, test di UAT.

Gli User Acceptance Test (UAT) sono dei test manuali ad alto livello che verificano che gli sviluppi rispettino gli standard degli utenti finali. Questa tipologia di test permette di alzare ulteriormente l'asticella poiché non si limitano a validare il corretto funzionamento di ciò che è stato sviluppato. Il loro valore aggiunto consiste nel verificare che il prodotto finale soddisfi effettivamente le aspettative e le esigenze degli utenti. In sostanza, rispondono alla domanda: "Il problema è stato risolto? La soluzione adottata è efficace?"

Per spiegare in modo pratico i benefici dei test di UAT, abbiamo elencato alcuni errori significativi che sono stati rilevati (e risolti) su diversi progetti. L'individuazione di ciascuno di essi ha permesso di rilasciare in produzione un prodotto di qualità superiore e ridurre i rischi post-rilascio.

1) Link di disiscrizione Per un'applicazione di networking, è stata richiesta la creazione di un link per annullare l'iscrizione a un evento. La user story, scritta dal punto di vista dell'amministratore della piattaforma, richiedeva semplicemente la creazione di questo link. L'idea era che il link sarebbe stato inviato manualmente agli utenti che ne facevano richiesta quindi, dal punto di vista del PO, era pensato per essere cliccato solo quando necessario.

Nonostante la richiesta sia stata soddisfatta, dal punto di vista degli utenti, i link di disiscrizione funzionano in modo differente.

Solitamente vengono ricevuti tramite email all'interno di comunicazioni relative all'evento stesso ("Clicca qui per disiscriverti", "Clicca qui se non vuoi più ricevere informazioni"), le quali vengono inviate in modo massivo e restano nella casella di posta ben oltre la data di scadenza dell'evento stesso. Introducendo questo scenario, si è introdotto anche il rischio che un utente potesse cliccare su un link di disiscrizione a evento terminato. I test hanno rilevato che, dopo la data di termine, il processo di disiscrizione andava comunque a buon fine, ma chiaramente si trattava di un comportamento anomalo e involontario poiché non coperto dalla feature. I test di UAT hanno dunque individuato uno scenario che, sebbene non previsto, il Product Owner ha deciso di implementare con una feature successiva (impedire agli utenti di disiscriversi oltre la data di fine evento) proprio perché il link sarebbe stato utilizzato anche per invii massivi.

2) Azioni Distruttive Un errore piuttosto comune riguarda la gestione delle azioni distruttive. Ad esempio, se all'interno di un modale di caricamento l'utente vuole rimuovere un file che ha selezionato erroneamente, una 'x' è più che sufficiente. Quando invece si tratta di un'azione non reversibile (cancellazione di una foto già caricata, rimozione dei privilegi di un determinato utente, eliminazione di dati societari...), bisognerebbe ragionare in termini di worst-case scenario ovvero chiedersi: "Se l'utente effettuasse questa azione per errore, cosa accadrebbe? Quanto è grave la perdita involontaria di questo dato?". Questi scenari sono facilmente gestibili con l'introduzione di un popup confermativo ("Confermi di voler eliminare il seguente contenuto?"), il quale chiaramente non può essere inserito per ogni azione effettuata dagli utenti. Tuttavia, se questo step intermedio non è espressamente richiesto dalla feature, gli sviluppatori, non essendo utenti finali dell'applicazione, potrebbero non intuirne la necessità e quindi semplicemente non implementarlo. I test di UAT, ragionando dal punto di vista dell'utente finale, permettono di rilevare queste sottigliezze e intervenire in tempo.

3) Placeholder, traduzioni e falsi positivi Durante i test di UAT è possibile imbattersi in errori che in realtà non esistono, si tratta di falsi positivi. Nella barra di ricerca di un'applicazione era stato inserito il placeholder "Cerca gli utenti per nome, email o username". Eseguendo uno scenario basato su quanto suggerito, è stato rilevato che la ricerca per email non produceva alcun risultato. Durante il debugging è però emerso che la funzione di ricerca non era mai stata implementata per gli indirizzi email! L'errore è stato dare per scontato questa tipologia di ricerca al punto da suggerirla nel placeholder. Questi errori sono molto frequenti anche nelle applicazioni multilingua. Ad esempio, se allo sviluppatore viene fornito un testo in italiano ma deve inserirlo anche in inglese, può capitare che la traduzione risulti distorta o fuorviante.

Ovviamente la maggior parte degli errori che emergono durante le fasi di UAT consistono in pagine bianche, eccezioni non gestite, errori in console, pagine non completamente responsive, accessi negati e così via. In questo articolo abbiamo voluto mettere l'accento su alcune dinamiche meno note dei test di UAT per mostrare come, preoccuparsi delle esigenze degli utenti finali, aiuti a ridurre i rischi post-rilascio.

In Application Performance sircle, we are specialized in testing applications and monitoring their performance over time. This involves the development of automated functional tests, performance tests, and increasingly, User Acceptance Tests (UAT).

User Acceptance Tests are high-level tests that verify that developments adhere to end users' standards. This type of testing raises the bar even higher, as it goes beyond validating the correct functioning of what has been developed. Their added value lies in ensuring that the final product actually meets users' expectations and needs. In essence, they answer the question: 'Has the problem been solved? Is the adopted solution effective?'

To explain the benefits of UAT tests, we have listed significant errors that were detected (and resolved) in various projects. Identifying each of these errors allowed for the release of a higher-quality product into production and reduced post-release risks.

1) Unsubscription Links For a networking application, the creation of an event unsubscription link was requested. The user story, written from the perspective of the platform administrator, simply required creating this link. The idea was that the link would be manually sent to users who requested it, so from the PO point of view, it was meant to be clicked only when necessary. Although the request was fulfilled, from the users' perspective, unsubscription links worked differently. They are usually received via email within communications related to the event itself ('Click here to unsubscribe', 'Click here if you no longer wish to receive information'), which are sent massively and remain in the inbox long past the event's expiration date. Introducing this scenario also introduced the risk that a user could click on an unsubscription link after the event had ended. The tests found that after the end date, the unsubscription process still worked, but it was clearly anomalous and unintentional behaviour as it was not covered by the feature. UAT tests thus identified a scenario that, although not anticipated, the Product Owner decided to implement with a subsequent feature (preventing users from unsubscribing after the event end date) precisely because the link would also be used for mass communications.

2) Destructive Actions A quite common error concerns the handling of destructive actions. For example, if a user wants to remove a mistakenly selected file within a loading modal, an 'x' is more than sufficient. But when it comes to an irreversible action (deleting a photo, revoking privileges of a specific user, erasing company data, etc.), worst-case scenario thinking should apply. The question is: 'If the user performed this action by mistake, what would happen? How severe is the unintended loss of this data?'. These scenarios can easily be managed by introducing a confirmation popup ('Do you confirm you want to delete the following content?'), which of course cannot be added for every user action. However if this intermediate step is not explicitly required by the feature, developers, not being end-users of the application, might not realize its necessity and therefore simply omit it. UAT tests, thinking from the end user's perspective, help to identify these subtleties and intervene in time.

3) Placeholders, Translations, and False Positives During UAT tests, it's also possible to encounter errors that don't actually exist: false positives. In the search bar of an application, the placeholder 'Search users by name, email, or username' was inserted. By following the suggested scenario, it was found that searching by email produced no results. Debugging revealed that the search function had never been implemented for email addresses! The error was assuming this type of search to the extent of suggesting it in the placeholder. These errors are also quite common in multilingual applications. For instance, if a developer is provided with text in Italian but needs to include it in English as well, the translation might end up distorted or misleading.

Of course, most of the errors that emerge during UAT phases consist of blank pages, unhandled exceptions, console errors, incomplete responsive pages, denied accesses, and so on. In this article, we wanted to emphasize some lesser-known dynamics of UAT tests to show how caring about end-users' needs helps reduce post-release risks.