Il modo con cui il testing può supportare il business dipende strettamente dalla natura del business e dell’organizzazione che lo realizza.
Ci sono quindi tanti diversi obiettivi di business che il testing può influenzare.
Per esempio,un obiettivo può essere aumentare la fiducia dei clienti. Ovviamente la fiducia viene influenzata dalla qualità del prodotto software che rilasciamo.
Un altro possibile obiettivo è di aumentare la credibilità di cui godiamo in potenziali clienti. Questa credibilità ad esempio la si gioca anche con la qualità delle demo e dei proof-of-concept che realizziamo.
Un altro obiettivo può essere di aumentare la produttività dei dipendenti del nostro cliente. Questo tipo di qualità viene sicuramente influenzata dall’affidabilità del nostro prodotto, dalla sua utilità e usabilità.
Un altro possibile obiettivo è ridurre i costi post-vendita. Lo si può ottenere agendo sull’usabilità del prodotto.
Si noti che non stiamo facendo altro che rispondere alla domanda “perché ci interessa la qualità del prodotto?”. Spesso, quando chiedo ai nostri clienti perché fanno testing ottengo come risposta un’occhiata perplessa. Ciò succede perché raramente ci si chiede qual è lo scopo profondo del testing. Ma, ahimè, è la domanda più importante a cui dare risposta.
Il testing quindi va visto come un servizio che viene offerto al business. Ma come si fa a renderlo davvero utile?
Trovare bachi, la risposta più ovvia, è semplicemente una possibilità.
Il testing può anche essere visto come un modo per monitorare lo stato di qualità della nostra applicazione. Spesso questo monitoraggio viene guidato dai requisiti e dai rischi di qualità. Uno potrebbe essere interessato a sapere, della release corrente, quale sia lo stato di qualità di un certo requisito, ad esempio quello menzionato molto spesso in una campagna di marketing che è appena partita. La tracciabilità dei test ai requisiti è estremamente importante in questo contesto, dato che consente di mostrare come un requisito è stato testato e con che esito. L’esito può venir descritto indicando quanti test sono andati a buon fine, quanti sono falliti e quanti sono incorsi in un errore. Inoltre, dati sulla copertura possono anche essere prodotti per indicare quanti potrebbero essere tutti i test che si potrebbero realizzare e quindi in che percentuale li abbiamo coperti.
Questo monitoraggio della qualità può risultare particolarmente utile nel decidere se rilasciare o meno, o nello stimare l’impegno necessario al supporto post-vendita.
Il testing può aiutarci a capire se il prodotto è conforme a uno standard, o una lista di funzioni critiche. Per esempio, le funzioni critiche possono essere specificate come casi d’uso che sono ritenuti essere critici da parte del cliente.
Il testing può servire anche per monitorare lo stato di salute di un sistema in produzione. Viene anche chiamato “Smoke testing” o “synthetic monitoring”. È particolarmente efficace nel caso di sistemi distribuiti, come quelli basati su micro servizi. L’idea di base è che periodicamente (ad es. ogni ora) viene eseguito un numero piccolo di casi di test che rappresentano degli scenari di utilizzo particolarmente comuni e caratterizzanti per quell’applicazione. La loro esecuzione consente di rilevare tempi di risposta e di identificare i casi in cui questi tempi si allungano oltremodo e segnalano quindi che qualcosa possa non funzionare correttamente. Lo smoke testing non è propriamente un tipo di testing, ma il fatto che lo si faccia usando gli stessi casi di test sviluppati per fare test di sistema, rende lo smoke testing un “cugino” molto vicino ad altre tecniche di testing.
Il testing può fornire una documentazione aggiornata automaticamente del sistema, e quindi affidabile. I casi di test vengono specificati in un linguaggio ad altro livello comprensibile anche a un non programmatore, e privi di dettagli tecnici (ad es. come si usa l’interfaccia del sistema sotto test, quale sia l’ID di un pulsante della sua interfaccia utente, o che parametri occorre usare in una chiamata di una API). In questo modo i casi di test costituiscolo LA documentazione, che viene automaticamente mantenuta aggiornata: se il comportamento del sistema non corrisponde al test, allora o il test viene corretto (e quindi anche la documentazione che viene prodotta automaticamente dal test) o il sistema viene corretto (e il test e la documentazione non serve che cambino).
Il testing può servire per validare i requisiti. Questo è ciò che spesso avviene durante il product backlog refinement, una sessione in cui il tester viene coinvolto per raffinare i requisiti su cui un team agile lavorerà a breve.
Il testing può anche aiutare a validare l’adeguatezza di un sistema al suo contesto di utilizzo. Il testing esplorativo, quello di usabilità, il test di accettazione utente e i test di sicurezza sono dei candidati primari per verificare che il sistema possa venir usato come previsto.
