I video dell’Agile Alliance Functional Testing Tools Visioning Workshop sono online

Logo Agile Alliance Due mesi fa l’Agile Alliance ha organizzato un workshop dedicato a strumenti per test funzionali o, più in generale, test di accettazione (AAFTT 2007). Recentemente James Shore ha pubblicato il transcript del suo intervento controverso e nonostante i video siano in realtà online già da alcuni giorni, questa è l’occasione per fare il punto sulla querelle tra lui ed Elisabeth Hendrickson.

Un minimo di contesto però:

  • James Shore è un XPer conosciuto per il suo impegno su FIT, il framework per la specifica e l’automazione di test funzionali ideato da Ward Cunningham. Recentemente Shore ha però espresso un punto di vista inusualmente negativo nei confronti di FIT, a partire dal proprio blog e da interventi come quello all’AAFTT 2007.
  • Elisabeth Hendrickson è esperta di temi agili in generale e di agile testing in particolare.

La provocazione di James Shore sta nel dire: beh, in fondo possiamo anche fare a meno dei test funzionali, risparmiando tempo ed eliminando inutili sprechi. Apriti cielo: anni e anni spesi a promuovere e giustificare l’automazione di test funzionali come strumento non ambiguo per l’accettazione del software finiscono all’improvviso dove non vorresti vederli.

L’intervento di James Shore però mette in realtà in luce più l’abuso di FIT, ovvero il suo uso in un contesto improprio, una specie di Mercury Test Director open source e basato su HTML. Fin qui niente di male: FIT è essenzialmente un framework che favorisce la comunicazione tra committente / analista di business e team di sviluppo, tramite il quale è possibile trasformare gli esempi concreti in codice eseguibile, specificando gli esempi sotto forma di tabelle HTML. Anche nell’ipotesi di usare FIT tramite Fitnesse, stiamo pur sempre parlando di strumenti collaborativi, più che di tool di automazione vera e propria. Ciò nondimeno, un’implementazione efficace di tecniche come continuous integration si basano proprio anche sull’esistenza di una suite corposa di test funzionali.

Dove non riesco proprio a seguire Shore è quando, con un triplo salto carpiato, dice che in fondo basta chiedere al cliente, un po’ di TDD, qualche test di tipo esplorativo, et voilà, il gioco è fatto.

La risposta a tratti polemica di Elisabeth Hendrickson mette il dito nella piaga: i test di accettazione forniscono un modo per verificare le aspettative del committente e sono fondamentali soprattutto in quei progetti che vivono al di là di un iniziale e temporaneo rilascio. Quello cioè che Hendrickson dice è che la natura di non regressione dei test di accettazione è insostituibile e viene fuori alla distanza, quando lo stesso team deve convivere con un sistema che evolve nel corso degli anni. La mia esperienza personale, sia in aziende di prodotto che presso system integrator, conferma in pieno quanto sostenuto da Elisabeth Hendrickson: è la stessa evoluzione del codice che è minata in profondità in assenza dei test funzionali.

Va da sé che Shore ci ricorda giustamente come i test funzionali siano un mezzo e non un fine: il nostro fine è capire in modo congiunto con il committente se il software funziona come ci si aspetta (“Does it work?”), se il suo comportamento è stato definito correttamente (“Is it right?”) e in ultima analisi se abbiamo fatto tutto quello che c’era da fare (“Are we done?”): tre domande che dovrebbero sempre guidare lo sviluppo del nostro sistema e che ne costituiscono la verifica ultima.

Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.