I passi necessari, i rapporti con il management, l’importanza della comunicazione. L’approccio start small and grow
by Randy Rice
Nel corso degli anni ho avuto il piacere di aiutare molte persone, appartenenti alle più diverse organizzazioni, nell’implementazione di strumenti dedicati al collaudo del software. Ho così avuto modo di osservare quali sono le criticità inerenti questa attività, cosa funziona e cosa non funziona.
La maggior parte delle persone ritiene che vi siano due criticità di fondo. La prima legata ad aspettative spesso poco realistiche, la seconda relativa alla capacità di ottenere il supporto del management. Nel corso di un progetto ho avuto modo di toccare con mano come uno dei miei clienti sia riuscito a gestire al meglio queste criticità.
Un po’ di storia
Per prima cosa è bene spendere qualche parola sull’ambito di business del progetto sopra menzionato, il settore finanziario, una dimensione che presenta complessità elevate sia in termini di tecnologia che di business application. L’organizzazione disponeva di quattro differenti piattaforme tecnologiche e tre di queste facevano affidamento su tool di automazione dei test. Ero stato ingaggiato per stabilire il livello di maturità dei processi e per valutare quanto la quarta piattaforma fosse pronta per introdurre una nuova attività di testing. Il cliente scelse di fare un assessment dei processi prima di iniziare una ricerca del tool.
È bene tenere presente che l’automazione dei test in utilizzo era molto poco funzionale. Il livello di automazione su una delle piattaforme non era stato mantenuto allineato all’applicazione per cui era inutilizzabile. Non vi era poi nessuna integrazione tra i tool e il livello di conoscenza tecnologico dei consulenti che avevano implementato la soluzione.
Perché tutto questo è importante? Mettetevi nei panni di un senior vice president dell’organizzazione. Uno dei vostri test manager vi dice che per mantenere il passo con i tempi di consegna (più di 500 release nel sistema principale in un solo anno) è indispensabile disporre di una qualche automazione il cui costo è superiore ai 250mila dollari. Non siete uno stupido. Sapete che la vostra azienda dispone già di tre tool. Due funzionano molto bene mentre il terzo, seppur non utilizzato, non può essere usato per la nuova attività. Cosa fare?
Ecco cosa ha fatto il cliente
1) Non ha promesso nessun immediato risultato, ma ha garantito una crescita graduale. Ha comunicato al senior management che avrebbe impiegato dai 12 ai 18 mesi per gettare le basi per una nuova automazione dei test. Ovviamente sapeva bene quanto fosse importante garantire risultati nel breve periodo. Questa strategia ha permesso di acquisire ritorni immediati e di guadagnare tempo per il costante impegno.
2) Non ha sovrastimato i vantaggi. Ha messo in risalto la necessità del tool, non i suoi vantaggi o la convenienza.
3) Ha messo a punto, prima di tutto, i processi e raccolto gli skill necessari. Invece di focalizzarsi su un tool e sulle sue capacità, il cliente si è concentrato nel comprendere come il tool potesse essere utilizzato. Sapeva che il tool aveva possibilità di avere successo soltanto se le persone lo avessero realmente utilizzato.
Perché il tutto ha funzionato
1) Il cliente era riuscito ad avere credibilità e a ottenere la fiducia del management. Questo è il motivo per cui la credibilità è da ritenersi l’attributo più importante che si debba possedere.
2) Il cliente ha avuto il coraggio di comunicare un messaggio impopolare. Non è stato facile promettere aspettative di basso profilo, ma sapeva che creare illusioni ed elevate aspettative avrebbe creato maggiori difficoltà.
3) Vi erano almeno tre precedenti in azienda circa l’utilizzo immediato di un tool, approccio rivelatosi un fiasco o non all’altezza delle aspettative. Questo rendeva legittimo tentare un approccio differente, start small and grow. Iniziare da un progetto di automazione di piccole dimensioni permette di comprendere i vari aspetti delle attività senza misurarsi con una complessità eccessiva. Questo approccio permette inoltre di pubblicizzare il successo e ottenere il consenso da parte delle persone che si dimostrano più scettiche.
4) Il cliente ha consolidato il proprio approccio fornendo aggiornamenti e costante informazione al management. Si è dimostrato sempre disponibile nel fornire informazione nei tempi utili acquisendo nuova credibilità. Le cattive notizie venivano date insieme alle cattive, trovando sempre il modo di presentare delle possibili soluzioni.
5) La società ha investito nelle risorse interne per trovare gli skill più appropriati. Il team non aveva ricevuto nessuna formazione per anni. Si sono quindi gettate le basi del disegno dell’automazione, cercando di fare comprendere quali fossero gli elementi costituenti un buon test. Si è fatto anche in modo che la gente imparasse a definire il design avendo in testa un modello di automazione e che le persone imparassero a lavorare bene insieme nelle fasi di progettazione e di automazione.
6) Si è preferito procedere con un proof-of-concept (Poc) evitando una quick evaluation. Un aspetto, quest’ultimo, molto importante che si è rivelato in seguito un fattore decisivo. Attraverso un Poc il fornitore del tool viene in azienda e lavora insieme alle vostre persone per implementare il tool. Ovviamente tutto questo ha un costo, ma la maggior parte dei fornitori sono motivati a ridurre i costi di consulenza standard per favorire la vendita. La maggior parte dei vendor preferiscono avere l’opportunità di minimizzare i rischi collaborando attivamente con i clienti. Nel nostro primo Poc il consulente del vendor è di fatto riuscito a completare l’automazione di un’applicazione. È stato un tipico caso di win-win-win. Il vendor ha venduto i suoi tool, il cliente ha ottenuto il rispetto del management e io ho ottenuto il dovuto apprezzamento per avere suggerito l’idea.
7) Siamo stati in grado di presentare i successi immediati e ottenere progressivamente un maggiore supporto. Questi primi successi ci hanno permesso di acquisire conoscenza abbassando il livello di rischio. Il consenso acquisito ha poi permesso di accelerare il processo. Procedendo lentamente all’inizio siamo riusciti, in seguito, ad accelerare e procedere più speditamente.
Anche voi potete fare lo stesso
Può essere che pensiate sia difficile fare accettare al vostro management un approccio simile a quello descritto. Credetemi, comprendo il vostro scetticismo. A ogni modo, qualcuno deve far fronte alle aspettative del management e dell’organizzazione in generale. In definitiva, non ho nessuna risposta esaustiva. Tuttavia, credo in alcuni principi:
1) Siate aperti e onesti con il vostro management – Quando ci sono delle cattive notizie tiratele fuori finché c’è ancora tempo di trovare una possibile soluzione. Nella mia esperienza se i problemi non si affrontano subito, possono solo peggiorare.
2) Tenete la comunicazione il più aperta possibile. Dovete sempre ricordare al vostro management che state costruendo un framework.
3) Pubblicizzate i quick wins. Non devono essere necessariamente dei grandi risultati. Guardate alle situazioni in cui siete riusciti a risparmiare tempo, avete ottenuto un miglioramento dei test e siete stati in grado di consentire alle persone di essere impegnate anche su altri lavori.
4) Definite prima i processi e gli skill necessari. Serve ad avere una guida, una sorta di road map. Il tool forzerà probabilmente dei cambiamenti al processo, ok. Tool, persone e processi di solito crescono insieme.
5) Siate flessibili. Siate aperti a nuove esperienze, anche nel processo di implementazione del tool. Ascoltate il team e provate a metterne in pratica i suggerimenti.
6) Imparate dai vostri errori e da quelli degli altri. Facciamo tutti degli errori, quindi dobbiamo imparare a trarne il dovuto vantaggio. Un buon libro su questo argomento è Project Retrospectives di Norm Kerth.
Conclusioni
Spero abbiate imparato a memoria questo case study e siate pronti a metterlo in pratica, soprattutto se avete provato a implementare soluzioni di questo tipo in passato, ma non ne avete compreso nel dettaglio gli obiettivi. L’approccio descritto risolve due dei maggiori problemi del test automation ovvero aspettative troppo elevate e supporto del management. Non dovete essere dei superuomini per fare le cose sin qui descritte. Dovete comunque educare il management e lavorare con loro perché comprendano di cosa si sta parlando, i rischi e i benefici associati a questa attività. Se sarete in grado di soddisfare le aspettative e ottenere la fiducia dei vostri dirigenti, scoprirete che nel giro di un anno la vostra reputazione sarà cresciuta e sarete riusciti a completare con successo l’implementazione del test automation.
————————–
Randy Rice
Randy Rice è un autorevole esperto di fama internazionale nei settori del Software Testing e del Software Quality. È un Certified Software Quality Analyst, Certified Software Tester, Certified Software Test Manager e Astqb Certified Tester, ha lavorato con molte organizzazioni in tutto il mondo per migliorare la qualità dei loro sistemi informativi e per ottimizzare i loro processi di Testing. È membro dell’American Software Testing Qualifications Board ed è editore di The Software Quality Advisor. È co-autore con William E. Perry dei libri Surviving the Top Ten Challenger of Software Testing e Testing Dirty Systems pubblicati da Dorset House Publishing. È stato chairman del Quality Assurance Institute’s International Software Testing Conference, membro fondatore del programma di certificazione Cste (Certified Software Test Engineer) e ha fatto parte del board of directors di Astqb (American Software Testing Qualifications Board). Nel 1990 ha fondato la Rice Consulting Service.
Randy Rice presenterà a Roma per Technology Transfer nella primavera 2012 “Testing di sistemi Legacy complessi e non documentati” e “Software Test Automation”.
