Scroll Top
Via Antonio Amato, 20/22 84131 Salerno (SA)

Ottimizzazione del Piano di Test Software con il supporto dell’AI

TestSoftware_supportoAI_cover

(articolo redatto da Karl Gallo e Marco Sabato)

Da qualche tempo Nexsoft è partner di un’importante software house italiana in ambito gestionale/finanziario. L’azienda cliente è in forte espansione, sta ampliando la sua presenza in alcuni paesi europei e si sta avvalendo della nostra consulenza su diversi gruppi di progettazione, sviluppo e manutenzione relativi ad alcuni prodotti di punta.

In relazione al nostro supporto per la progettazione e l’esecuzione di test, sia manuali che automatizzati, Marco e Karl (autori del case study che stai per leggere👇) stanno rivestendo rispettivamente il ruolo di analista/tester specialist e test manager.

Introduzione

Abbiamo deciso di scrivere questo articolo per condividere l’esperienza sul campo che abbiamo vissuto. Vi raccontiamo  come abbiamo velocemente ed efficacemente migliorato i processi del testing software nell’azienda cliente, con l’ausilio di strumenti gratuiti di intelligenza artificiale .

La situazione di partenza

La metodologia che abbiamo sempre usato, come da prassi Nexsoft, è lo standard internazionale STQB, nella versione italiana ISTQB, che ci ha permesso, e ci permette ancora, di perseguire ottimi risultati nella gestione di tutti gli aspetti del testing software in ogni situazione.

Nella fase iniziale del nostro lavoro presso l’azienda cliente abbiamo utilizzato una modalità di pianificazione dei test basato su un foglio Excel. Questo file include un template sofisticato che specifica in dettaglio le precondizioni e le postcondizioni di ogni caso di test, permettendo un’efficace pianificazione dei test, una esecuzione puntuale e documentata per ogni singolo use case.

La metodologia utilizzata ha, quindi, consentito un ottimo tracciamento dei risultati e la possibilità di ottenere report completi e anche apprezzati dagli stakeholder e da chi di dovere, oltre che  raggiungere i principali obiettivi che una attività di testing efficace deve prefiggersi, tra i quali:

  • Rilevazione dei difetti;
  • Riduzione del livello di rischio di una qualità del software inadeguata;
  • Verifica del rispetto dei requisiti richiesti nel prodotto finale;
  • Controllo della completezza e del corretto funzionamento del software secondo le richieste degli stakeholder.

Proseguendo nelle nostre attività di gestione dei test, abbiamo però riscontrato alcuni aspetti critici nell’utilizzo della testlist così come originariamente impostata. Infatti, sebbene gli aspetti tecnici della stesura dei casi di test erano tutti adeguatamente coperti, con correttezza ed efficienza (ad esempio replicabilità e tracciabilità), non altrettanto efficaci erano gli aspetti che riguardavano la facilità di utilizzo dello strumento e la comprensibilità dei casi di test sviluppati, nonché i tempi lunghi di elaborazione che necessitava la costruzione della testlist tabellare.

Inizialmente, l’integrazione nel workflow aziendale di una metodologia così strutturata, professionale e rigorosa per la stesura dei casi di test ha suscitato entusiasmo, ottimismo e fiducia tra tutti i professionisti coinvolti, inclusi gli stakeholder. Tuttavia, presto abbiamo osservato un crescente senso di rifiuto verso questo strumento, percepito come complicato, prolisso e difficile da interpretare, specialmente da parte dei non addetti ai lavori e in determinate e specifiche situazioni.

Software Testing con il supporto dell'AI

L’adozione di Gherkin

Abbiamo quindi cercato di capire quali fossero gli aspetti più critici nell’utilizzo del template Excel, e come poter migliorare la percezione dei colleghi nello sfruttare uno strumento rigoroso nei flussi aziendali. Per questo motivo abbiamo ritenuto opportuno studiare una alternativa o un miglioramento all’attuale metodologia, focalizzandoci su degli aspetti specifici, in particolar modo:

  • Descrizioni dei casi di test meno ostici;
  • Precondizioni e postcondizioni meno prolisse;
  • Struttura generale meno tecnica e più discorsiva;
  • Leggibilità migliorata per tutti gli stakeholder.

Naturalmente le modifiche al sistema esistente non avrebbero dovuto intaccare gli aspetti positivi e i risultati raggiunti, altrimenti avremmo vanificato il lavoro precedente, comunque ottimo, che ci ha consentito di instaurare una corretta implementazione di tutte le attività di testing software da portare avanti e di far comprendere all’azienda cliente la giusta importanza che i test hanno nell’ambito dello sviluppo software.

L’innesto dell’Intelligenza Artificiale

Mentre lavoravamo al progetto, stavamo utilizzando diverse app di intelligenza artificiale per rendere più efficienti le attività di testing nelle diverse fasi, dalla progettazione alla esecuzione. Ad un certo punto la lettura dell’articolo di Fiore Braciglianese sull’automazione dei test ci ha fatto venire l’idea di esplorare quali tecniche e strumenti utilizzati nei test automatici avrebbero potuto aiutarci nelle nostre attività di test manuali.

È stata una risposta precisa di un’applicazione di intelligenza artificiale a seguito di un prompt specifico a suggerirci l’uso della sintassi Gherkin, tipicamente impiegata per i test automatici, come alternativa per scrivere i casi di test manuali, in sostituzione delle testlist in Excel precedentemente usate.

Caratteristiche e usi della sintassi Gherkin

Prima di continuare è opportuno dare qualche dettaglio sulle caratteristiche e gli utilizzi della sintassi Gherkin. Nell’ambito dello sviluppo software, la metodologia BDD (Behavior-driven development, traducibile in Sviluppo guidato dal comportamento) viene implementata da strumenti che consentono di basarsi sul comportamento del software più che dai dettagli implementativi, e uno di questi strumenti è Cucumber. Ed è proprio in Cucumber che viene utilizzato Gherkin. Quest’ultimo prevede una sintassi, con un preciso pattern, che serve a descrivere gli scenari e i casi d’uso che dovranno essere implementati dal software in sviluppo. Ogni scenario Gherkin segue lo stesso pattern fondamentale: dato un contesto (Given), un evento o un’azione (When) produce un risultato (Then). I contesti, gli eventi e i risultati vanno descritti in normale linguaggio naturale, ad esempio la lingua inglese o italiana, ed è quindi indicato per condividere la descrizione di scenari di uso all’interno di team composti da anche da professionisti non tecnici informatici, che è uno dei pilastri del BDD.

Naturalmente l’utilizzo adatto ai nostri scopi doveva essere molto semplificato, e anche leggermente modificato per venire incontro alle esigenze individuate, e per risolvere le criticità dell’altro metodo, per cui abbiamo individuato un pattern di questo tipo:

GIVEN
Contesto iniziale – Dati di partenza – Precondizioni

WHEN
Evento – Trigger – Azioni da eseguire

THEN
Risultati attesi – Dati finali accettati – Postcondizioni

Facoltativi:

SCENARIO (prima del GIVEN)
Descrizione della situazione – Preparazione dei dati o degli applicativi – Contesto generale del caso d’uso 

EXAMPLE  (dopo il THEN)
Esempio chiarificatore – Template di dati accettati

Come linguaggi naturali abbiamo scelto di mantenere l’inglese per le parole chiavi fisse, in modo che fossero riconoscibili e rigorose, come When e Then, mentre la descrizione dei paragrafi relativi ad eventi, risultati attesi, contesti e dati iniziali, abbiamo scelto di mantenere l’italiano, visto che è la lingua ufficiale dell’azienda cliente, essendo una realtà presente principalmente nel nostro Paese, e non essendoci nessun collega straniero nel team.

Sebbene quasi tutte le clausole, così come provengono dalla sintassi originale, si presentavano già adatte ad essere usate direttamente così come in Gherkin, quella a cui prestare attenzione è stata la clausola THEN, che nel nostro caso doveva rappresentare la descrizione precisa dei risultati attesi, sia quelli per i quali il test è considerato superato, sia i controesempi per i quali il test è considerato non superato.
L’altra caratteristica chiave, che è stata lasciata così come viene usata in Gherkin è la descrizione dei casi di test come azioni dell’utente sul software e non come implementazioni che lo sviluppatore deve eseguire, e ciò è stato un grande vantaggio in diversi aspetti, come vedremo successivamente.

I primi casi di test

Avendo deciso, quindi, di avviare una fase di sperimentazione dell’utilizzo di questo strumento, è stato semplice ed immediato iniziare a scrivere i primi casi di test per verificarne l’efficacia. Poiché il progetto software in cui siamo coinvolti utilizza una metodologia di sviluppo agile, abbiamo scelto di avviare la prima fase di sperimentazione durante uno sprint privo di scadenze, rilasci o altre attività critiche in modo da sfruttare un periodo in cui potevamo focalizzarci sulla nuova modalità “Gherkin” senza distrazioni o altre priorità urgenti.

Dopo aver scelto, sprint e periodo, abbiamo quindi individuato quali schede di test, tra quelle assegnateci in fase di sprint planning, potevano essere adatte ad una pianificazione con la stesura dei casi di test scritti con la sintassi “Given-When-Then” che avevamo deciso di adottare, e quindi circa il 50% delle schede dello sprint sono state interessate dalla nuova modalità, mentre sono state tralasciate quelle in cui il tipo di test sarebbe stato più efficacemente descritto da una struttura tabellare, e quindi descritte con il consueto modello a testlist.

Dal primo utilizzo di questa nuova modalità abbiamo immediatamente riscontrato i primi risultati positivi, osservando dall’inizio come l’introduzione di tale strumento sia stata subito accettata, in maniera quasi naturale, dai colleghi, non avendo necessità di apprendimento o formazione propedeutica, né tempi tecnici di preparazione.

Ben presto sono stati riscontrati ulteriori effetti benefici anche in altre aree, sia quelle che ci aspettavamo, ma anche su aspetti che inizialmente non avevamo considerato, ma che comunque ci hanno sorpreso con risultati inaspettati.

I miglioramenti ottenuti

Possiamo indicare i miglioramenti rispetto alla vecchia modalità nei seguenti punti:

  • Accessibilità: casi di test più accessibili e condivisibili con altri membri del team, con conseguente riduzione gli errori di comunicazione tra colleghi e stakeholders;
  • Manutenibilità: casi di test organizzati e facilmente gestibili e manutenibili, anche quando il numero di test cresce;
  • Scalabilità: migliorata facilità di aggiungere, modificare o eliminare i casi di test senza compromettere la struttura generale dei test;
  • Leggibilità: struttura chiara e coesa per i casi di test, evitando interpretazioni errate, grazie al linguaggio naturale ma comunque rigoroso utilizzato dalla sintassi Gherkin;
  • Efficacia: aumento della qualità dei test e riduzione del rischio di errori nel prodotto finale.

L’accessibilità era una delle caratteristiche su cui ci aspettavamo un miglioramento visibile, e in effetti le nostre previsioni non sono state disattese. La nuova modalità di scrittura permette una condivisione della documentazione della fase di testing sia alle figure tecniche del team, come analisti e sviluppatori, sia verso gli stakeholders, che ora hanno una visione più chiara delle attività che noi tester svolgiamo, e hanno una interazione maggiore che permette a tutti di partecipare più attivamente allo sviluppo agile.

La manutenibilità, invece, era uno di quegli aspetti su cui non ci aspettavamo grossi cambiamenti, anzi temevamo un peggioramento o comunque maggiori difficoltà a tenere aggiornati e ben organizzati i documenti dei casi di test. Per fortuna, a differenza di ciò che ci aspettavamo, anche in questo caso i miglioramenti sono stati piuttosto evidenti, nonostante la documentazione, soprattutto in alcuni tipi di casi di test, mediamente ha una lunghezza superiore rispetto alla rispettiva versione testlist in Excel. La scelta di non abbandonare la “vecchia” modalità di scrittura dei casi di test in maniera tabellare, ma di affiancarla alla nuova, ci ha permesso di ottimizzare la documentazione, così da avere ogni caso di test progettato e scritto secondo la modalità più consona.

La scalabilità è stata un altro di quegli aspetti dai quali siamo stati positivamente sorpresi, in quanto non ci aspettavamo miglioramenti. Un approccio tabellare alla scrittura dei casi di test sembrerebbe più adatto ad essere gestito in termini di scalabilità, e invece, da come abbiamo rilevato, anche la struttura “discorsiva” del nostro nuovo metodo basato sulla sintassi Gherkin, ci ha permesso di ottenere ottimi risultati anche in questo ambito. Da sottolineare, in particolare, che l’elemento più evidente è stata la facilità di collaborazione con altre figure professionali del team, nel gestire i test cases insieme a noi, nel valutare azioni come aggiungere, modificare ed eliminare elementi.

Indubbiamente i risultati migliori ce li aspettavamo dalla forte evoluzione della chiarezza, della comprensibilità e della intelligibilità dei casi di test scritti in sintassi Gherkin, e le attese sono state ampiamente confermate. È facilmente intuibile, infatti, come il linguaggio naturale sia un grande alleato nella descrizione delle varie fasi di un caso di test, come ad esempio precondizioni e postcondizioni, pur mantenendo la rigorosità di una sintassi formale e ben strutturata.

Diretta conseguenza della leggibilità è l’efficacia in termini di riduzione degli errori, soprattutto nelle situazioni in cui, ad esempio, chi progetta i test case non è la stessa persona che si occupa dell’esecuzione dei test manuali. In tali casi, che nella nostra esperienza non sono stati rari, l’esecuzione dei test è semplificata dalla forma descrittiva dello stesso, come se fosse un manuale d’uso o un tutorial, snellendo i processi aziendali e azzerando i tempi di apprendimento e/o comprensione delle attività da svolgere per portare a termine i task relativi al controllo qualità.

Software Testing con il supporto dell'AI

I benefici riscontrati e l’estensione ad altre attività dello sviluppo agile

Dopo un iniziale studio di fattibilità, l’adozione di questo nuovo framework è stato quasi immediato, entrando a pieno regime l’utilizzo nei nostri sprint, anche molto prima di quello che ci aspettavamo, essendo stato accolto molto positivamente sia dai colleghi del team che dagli stakeholder.

Nel successivo periodo di affermazione e consolidamento, abbiamo tracciato l’efficacia dei risultati, confrontandoli con periodi precedenti aventi gli stessi carichi lavorativi e abbiamo continuato ad ottenere i miglioramenti attesi, di cui abbiamo già ampiamente discusso sopra.

Allo stato attuale delle cose, nel nostro team stiamo utilizzando questa modalità come strumento definitivo, e stiamo prendendo in considerazione l’idea di estendere l’utilizzo della nuova sintassi anche per altre fasi dello sviluppo agile del software. In particolare Gherkin sembrerebbe essere particolarmente adatto anche per due specifiche attività: la raccolta dei bug e la richiesta di implementazione.

Analisti funzionali e stakeholder, potrebbero essere avvantaggiati da una sintassi del tipo given-when-then perché continuerebbero a scrivere le richieste di implementazione sempre nel linguaggio naturale, ma con una rigorosità aggiuntiva e una precisione maggiore per i programmatori che dovranno sviluppare tali richieste.

Altro utilizzo che potrebbe ricevere dei vantaggi da una simile sintassi è quello della raccolta delle anomalie da parte di utilizzatori finali e di operatori di assistenza, dato che verrebbe descritto, in maniera più precisa, il comportamento che genera l’errore o il comportamento inatteso. In questo caso, però, potrebbe sorgere il rischio di ambiguità in quanto nella clausola THEN, nel caso specifico, viene seguita la descrizione dell’anomalia e quindi del comportamento che NON deve avere il software, mentre, viceversa, negli altri casi di progettazione dei casi di test e di richieste di anomalie, verrebbe descritto il risultato atteso. Per questo motivo è da studiare con molta attenzione l’opportunità di inserire questa modalità di raccolta dei bug tramite la sintassi Gherkin.

Software Testing con il supporto dell'AI

Conclusioni

Da questa nostra esperienza abbiamo verificato in prima persona come non sia necessario utilizzare strumenti di intelligenza artificiale avanzati, ma con un prompt ben scritto e una semplice app gratis di intelligenza artificiale abbiamo ottenuto una risposta che ha migliorato in modo sostanziale i processi produttivi di una grande azienda software di livello nazionale.

L’introduzione della sintassi Gherkin e degli strumenti di intelligenza artificiale ha significativamente migliorato l’efficienza e l’efficacia del processo di testing software presso il nostro cliente.

Non solo è stato possibile mantenere l’elevato rigore tecnico della metodologia ISTQB adottata, ma anche rendere i casi di test più accessibili e comprensibili per tutti gli stakeholder e i colleghi del team.

Questo cambiamento non ha solo ridotto i tempi di realizzazione e aumentato la qualità del prodotto software finale, ma ha anche incrementato la soddisfazione e il coinvolgimento di tutti i soggetti coinvolti nel progetto.

Facendo tesoro di questa esperienza, abbiamo intenzione di continuare ad esplorare e implementare nuove soluzioni innovative per migliorare ulteriormente i nostri processi di testing.


Se anche tu vuoi far parte del team di Quality Assurance Nexsoft,
dai un’occhiata alle nostre opportunità di lavoro e conosciamoci subito!

Questo sito utilizza cookies propri e si riserva di utilizzare anche cookie di terze parti per garantire la funzionalità del sito e per tenere conto delle scelte di navigazione.
Per maggiori dettagli e sapere come negare il consenso a tutti o ad alcuni cookie è possibile consultare la Cookie Policy.

USO DEI COOKIE

Se abiliti i cookie nella tabella sottostante, ci autorizzi a memorizzare i tuoi comportamenti di utilizzo sul nostro sito web. Questo ci consente di migliorare il nostro sito web e di personalizzare le pubblicità. Se non abiliti i cookie, noi utilizzeremo solo cookies di sessione per migliorare la facilità di utilizzo.

Cookie tecnicinon richiedono il consenso, perciò vengono installati automaticamente a seguito dell’accesso al Sito.

Cookie di statisticaVengono utilizzati da terze parti, anche in forma disaggregata, per la gestione di statistiche

Cookie di social networkVengono utilizzati per la condivisione di contenuti sui social network.

Cookie di profilazione pubblicitariaVengono utilizzati per erogare pubblicità basata sugli interessi manifestati attraverso la navigazione in internet.

AltriCookie di terze parti da altri servizi di terze parti che non sono cookie di statistica, social media o pubblicitari.