Conviene parlare dei test con i clienti?

Questo è il dilemma che affligge gli animi di sviluppatori e commerciali quando devono iniziare un nuovo progetto e definire i budget, spiegando ai clienti cosa comporti questa scelta.

Con questo post voglio raccontare l’esperienza in Cantiere Creativo nella gestione di progetti web sviluppati negli ultimi anni, in cui abbiamo applicato pratiche di testing. Non ho risposte illuminanti, solo riflessioni aperte e qualche suggerimento che nascono da errori commessi.

Qualunque sia la dimensione del progetto da affrontare, abbiamo sempre come obiettivo la "qualità". Concetto vasto e trasversale a molti aspetti: qualità nella gestione del lavoro, della vita in ufficio, dell’estetica e, per lo sviluppo, la qualità del codice che scriviamo. Per fare codice di qualità non ci siamo potuti esimere dall’utilizzo dei test che per noi significano Unit test, Integration test, TDD e BDD. Tecniche che spieghiamo nel dettaglio in una pagina dedicata.

Questo è il dubbio ricorrente durante i nostri incontri commerciali. Nel tempo abbiamo sperimentato differenti approcci facendoci l’idea che:

NO: Se non parliamo dei test al cliente, di fatto, il problema non si pone. Nemmeno verrà tenuto conto del tempo e del budget necessari a scriverli perché il cliente non comprenderà a fondo la differenza di costi/tempi con altri competitors che non adottano questa pratica. Anche se uno sviluppatore, per sua iniziativa e necessità, iniziasse a scrivere test, si troverebbe presto a dover rinunciare (con tristezza e frustrazione) per mancanza di tempo e di risorse.

Quindi, semplicemente: se non ne parli, i test non vengono fatti. Yo!

SI: Far capire cosa siano i test è una cosa davvero difficile e nel 90% dei casi, il cliente non ha idea di cosa si stia parlando. Alcuni volenterosi, affascinati dalla tecnologia, potranno immaginarsi scenari complicatissimi, affascinanti ma sovradimensionati rispetto a ciò di cui pensano di aver bisogno.

In entrambi i casi, durante la spiegazione dettagliata, con molta probabilità, il viso dei nostri interlocutori sarà colmo di scetticismo, noia e paura e, in alcuni casi, si potrà notare anche qualche sfumatura di disgusto!

ndr: sto scherzosamente generalizzando; in alcuni casi ho visto clienti — facilmente con competenze tecniche — felici di sentir parlare di test!

Come sviluppatori siamo perfettamente consapevoli che il codice testato porta benefici a tutti: il cliente avrà ciò che vuole, ovvero un prodotto funzionante e verificabile; lo sviluppatore dormirà sonni tranquilli dopo aver fatto un deploy, oltre ad avere meno timore di mettere le mani là dove può essere pericoloso; di fatto, sarà l’intero progetto a trarre i vantaggi perché potrà avere una vita duratura su una struttura solida.

Per questo abbiamo deciso di parlare dei test ai nostri clienti.

Ci siamo dovuti domandare come arrivare a vendere i test come parte integrante dello sviluppo del progetto. Dopo un po’ di tentativi abbiamo trovato la nostra formula.

FORMAZIONE: i colloqui con i clienti sono diventati delle full immersion in cui spieghiamo l’approccio agile, scrum entrando nei dettagli del metodo che adottiamo. I test fanno parte di questa formazione necessaria.

QUALITÁ: mettiamo bene in chiaro che la qualità interna è un nostro punto fermo. Riguarda l’infrastruttura e il codice da realizzare.

VIDEO: l’utilizzo di video che mostrano un test completo di una app, ci aiuta a far capire visivamente di cosa stiamo parlando. Dove un test umano richiede una o due ore con margine di errore elevato, la suite di test lo fa in poco più di un minuto dandoci garanzia che tutti i punti, pulsanti e form vengano testi nel loro corretto funzionamento.

FULLY TEST CODE: Avere il 95% di coverage significa poter inserire nuove funzionalità senza avere paura delle regression, ovvero di spaccare le funzionalità già scritte in precedenza; significa avere un codice mantenibile nel tempo.

Per fa comprendere meglio questi vantaggi, ci torna utile il grafico che mostra le differenze tra un approccio con o senza test.

nella alternativa senza test, il tempo iniziale di sviluppo è sicuramente più veloce e più economico ma ogni cambiamento ci porterà, in extremis, ad avere un punto invalicabile per cui ogni modifica diventerà tremendamente costosa se non impossibile.

Un'applicazione testata avrà una fase di startup più lenta e quindi costosa ma i costi iniziali saranno ripresi nel tempo grazie al fatto che le funzionalità aggiuntive, non creeranno problematiche all’esistente.

La documentazione del codice è molto importante; sappiamo anche che troppo spesso è la prima attività a saltare con l'avanzare degli sviluppi ed il ridursi dei budget. I test svolgono perfettamente questa funzione perché sono, di per sé, descrittivi di ciò che le funzioni fanno.

Avere una suite di test aiuta in fase di aumento del team di sviluppo per cui un nuovo dev, non avrà paura di “sporcarsi le mani” e giocare con il codice esistente; permette al cliente di cambiare fornitore, cosa che può succedere per mille motivi. Può succedere anche che il progetto vada bene e che il cliente decida di costruire un team interno per la manutenzione o lo sviluppo di altre parti della app. Quel giorno, farete una gran bella figura! ;)

Quindi, perché esiste il dilemma? Sembra tutto logico e bellissimo... Dove sta esattamente il problema?

Per Scrivere i test è necessario avere le idee chiare sui comportamenti. Sappiamo che i clienti, soprattutto nella fase iniziale di un progetto, non sanno mai cosa vogliono veramente e cambieranno idea mille volte! Attenzione però, il problema non sono i test; al contrario, i test fanno emergere il problema, lo rendono evidente e non possono essere scritti fintanto che questo non viene affrontato e risolto.

Qualunque sviluppatore ha bisogno di far pratica per prendere confidenza con la mentalità per cui il codice parte dal vincolo dei test per svilupparsi successivamente. Questo dipende certamente dagli skill e l'esperienza dello sviluppatore ma anche uno molto bravo che non abbia particolare confidenza con il TDD, troverà estremamente scomodo abituarsi a questo modo di procedere nel ragionamento.

Scrivere dei buoni test non è affatto banale. Si deve testare qualcosa che ancora non esiste senza cadere nell’errore di fare pre-ingegnerizzazione della applicazione. Inoltre l’over-engineering è sempre in agguato: entrando smisuratamente nel dettaglio di un funzionamento, si rischia di generalizzare troppo, implementando comportamenti e test che non sono realmente richiesti o necessari.

Si entra poi nel magico mondo dei raddoppi! Oltre all’applicazione “che si vede”, deve essere mantenuta anche la suite di test, che a sua volta è fatta di codice! Se non si trattano i test con la medesima cura (o forse con più cura) il rischio è quello di riporre la nostra fiducia su un uno strumento che in realtà è fragile.

Doppia quantità di codice. Il ratio dei test è generalmente 2:1. Se una suite di test arriva ad avere il doppio del codice della app e dato che i test sono anch’essi del codice, dove si corre il maggior rischio di esplosione di caos? Cura, cura, cura!

Doppio budget. Abbiamo da scrivere il 200% di codice in più, soprattutto per la fase iniziale di startup. Serve tempo, quindi soldi!

Dagli errori si impara e non si smette mai. Come dicevo, non ho grandi risposte al dilemma ma dal punto di vista della gestione, ci siamo fatti delle idee. Abbiamo verificato che esistono due domande fondamentali a cui i clienti sono chiamati a rispondere con il massimo della trasparenza.

Se la app non richiede sviluppi futuri, nasce già legacy e quindi possiamo azzardare a dire, con una certa tranquillità, che non avrà bisogno di test. Se cambierà “un po’”, dovremo cercare di capire bene dove e quanto, in modo da identificare le aree più delicate del progetto.

Questa sembra ancora più banale come domanda! Tutti rispondono “moltissimo”, nessuno vuole i bug, da nessuna parte. Ma i bug esistono! Basta approfondire un minimo per scoprire l’esistenza di aree della applicazione più delicate di altre, in cui il bug non è ammissibile. Immaginiamo uno scenario in cui parliamo di pagamenti o di analisi di dati importanti per il monitoraggio della salute. Un bug qui peserà molto di più rispetto ad uno sulla pagina “chi siamo”. Dare priorità ai bug, ci aiuta nuovamente a capire quali siano le aree più delicate del progetto su cui effettuare, senza dubbi, dei test.

Se un progetto ha bisogno di test, è necessario avvalersi di sviluppatori che abbiano esperienza con queste pratiche. È molto probabile che i primi tentativi di scrittura di test siano instabili e avere un suite in produzione che non sia solida, non è auspicabile.

Il cliente percepisce il valore dei test dal fatto che la sua app non si rompe e rimane solida nei mesi. Anche se andasse sempre tutto bene, col tempo la percezione del valore dei test viene a mancare, il cliente tende a dimenticarla. Conviene consegnare periodicamente dei report generati da un qualunque strumento che fa questo di mestiere, che documenti lo stato di salute del codice che si crea; i clienti non ci capiranno nulla, ma saranno felici lo stesso di sapere che la loro app sta bene!

Siate risoluti! Il cliente vorrà sempre risparmiare e a volte si casca nella tentazione di assecondare l’apparente risparmio. Dobbiamo sempre rimanere consapevoli che così, prima o poi, ci faremmo male. Il reale valore dei test lo conosce chi scrive e vende prodotti testati. I clienti no. Per questo è fondamentale rimanere fermi nella posizione che si prende, al di là delle paure commerciali che, soprattutto in questo caso, proprio non aiutano.

Possiamo ancora avere dubbi su come gestire al meglio le pratiche di test, ma non abbiamo dubbi sul fatto che la risposta alla prima domanda è SI, fare test, parlarne col cliente, mettendo sul piatto una grande dose di buon senso riflettendo su cosa significhi testare nelle differenti situazioni.

To test or not to test? this is the problem