Google e i Test Mercenaries

Di - 11 September 2012 - in

Tra le aziende che forniscono servizi per il web, Google è certamente tra le piú attente per quanto riguarda il testing delle applicazioni prima del rilascio: raramente si trovano bug particolarmente gravi, gli standard di sicurezza sono sempre molto alti al punto da influenzare anche terzi (come nel caso dell’HSTS) e spesso vengono indette vere e proprie cacce ai bug pubbliche come Pwnium.

Ottenere e mantenere standard cosí elevati, per un’azienda in cui si sviluppano molti progetti contemporaneamente e in cui moltissime persone lavorano assieme allo stesso progetto, non è affatto facile. Richiede delle linee guida che tutti devono rispettare attentamente per evitare di introdurre errori che potrebbe non essere facile poi individuare o riparare.

Per questo motivo, nel 2005, Google ha istituito una piccola task force chiamata Testing Grouplet, con lo scopo di definire degli standard per ottenere una strategia e una collezione di software per il test delle applicazioni uniforme per tutti i progetti. Nonostante questa task force fosse un gruppo come gli altri, e quindi non avesse nessuna particolare autorità, si diede molto da fare creando un’ampia documentazione sulle tecniche di testing pre-esistenti in azienda e permettendo cosí di conoscerle e di individuarne i limiti tanto ai nuovi assunti quanto a chiunque volesse mettere in discussione il proprio modo di approcciarsi al problema. Tale documentazione è stata anche presentata in una serie di lezioni chiamate Noogler (new googler).

Le iniziative piú felici ideate dalla genialità di questo gruppo di persone sono Testing on the Toilet e Test Certified.

La prima, piuttosto nota, è una serie di articoli sulle pratiche di testing e sugli errori piú facili da commettere ideata in maniera che ogni articolo possa essere letto… in bagno. Nato come scherzo, è diventato rapidamente noto prima internamente e poi portato all’esterno, poiché in effetti la formula “articolo breve, chiaro ed utile” è comodissima per chi è impegnato in un lavoro che non gli permette di studiare un manuale di testing, ma che ha molto da imparare da esempi pratici e rapidamente assimilabili.

Tali articoli venivano effettivamente stampati, come pubblicazione periodica, e appesi nei bagni delle sedi Google.

La seconda iniziativa, proposta anche nel numero 49 di Testing on the Toilet è una linea guida per la realizzazione di un progetto semplice da testare e quindi piú facilmente a prova di errore. Un progetto che rispondesse completamente alle linee guida veniva detto Test Certified.

Le linee guida Test Certified consistono in tre livelli, ognuno diviso in punti.

Il primo livello richiede di mettere in atto una macchina produttiva definita e continua, e una serie di misure per determinare quali test siano necessari per il progetto. Nel primo livello è anche necessario distinguere tra test piccoli, medi e grandi, in base a quanto siano locali le cose testate, e di individuare i test superflui perché non deterministici, ovvero i test che possano dare esiti diversi ogni volta pur testando lo stesso codice. Questa cosa, che può sembrare strana, è invece plausibile poiché spesso l’esecuzione del codice dipende da fattori esterni al codice stesso (orologio di sistema, servizi esterni) che creano problemi alla correttezza del test.

Il secondo richiede rigore nel testare ogni modifica non banale al codice e nell’evitare di mandare avanti nella catena di produzione del codice non testato o sul quale i test abbiano dato esiti negativi. Inoltre, richiede di stabilire in percentuale quanti siano i test grandi, quanti i medi e quanti i piccoli. Insomma, mentre il primo livello è piú una questione di misurazioni e raccolte di dati, il secondo è la richiesta di scrivere e rispettare un regolamento interno su come lavorare nel team.

Il terzo livello definisce una serie di standard che funzionano da tetto massimo per le policy definite nel secondo, richiedendo in sostanza un regolamento particolarmente rigoroso. I parametri sono le percentuali dei test di varie dimensioni, la richiesta di totale assenza di test non deterministici, e i tempi di durata dei test.

Sono stati in seguito definiti due livelli ancora piú stringenti.

Il principale problema riscontrato nei feedback a Testing on the Toilet era lo scarso tempo a disposizione per i test che, con gli strumenti di test in mano agli sviluppatori, di fatto non permetteva dei test ragionevolmente ben fatti. Il Grouplet si è quindi dato da fare per la realizzazione di una piattaforma di test avanzata e automatizzata, che permettesse di migliorare le performance e accelerare i tempi: i Google Engineering Tools.

Per aiutare i vari gruppi di lavoro a raggiungere gli obiettivi di Test Certified, i leader del Testing Grouplet Bharat Mediratta e Nick Lesiecki, assieme a Mark Striebeck proposero l’istituzione dei Testing Mercenaries, di fatto un gruppo di ingegneri del software impiegati a tempo pieno come consulenti interni. La proposta fu accettata, con alcune modifiche per ingrandirne le proporzioni, e si provò a dare il via ad una vera e propria rivoluzione nella gestione delle procedure di test.

La vita di questo team non è stata semplice fin dall’inizio, come spesso accade in questi casi. L’idea che una persona si affianchi ad un gruppo di lavoro preesistente e inizi a dare consigli su come si facciano le cose, e che tali consigli vengano accettati di buon grado e messi in pratica, è un’idea che non appartiene al mondo reale. Quando poi in sostanza è necessario sapere quanti bug sono stati trovati nel codice a cui il gruppo sta lavorando, quanti bug si sono evitati con la procedura corrente di testing (ammesso che esista), quanti problemi sono stati individuati dagli automatismi degli Engineering Tools, e si chiede di misurare ed evidenziare quanto tempo si risparmia grazie al testing, le cose possono facilmente andare molto molto male.

Storicamente, poi, Google è un’azienda estremamente attenta a tutto ciò che è misurabile, come spesso accade dove si concentrano ingegneri e scienziati. I criteri di qualità considerati erano quindi quelli chiaramente misurabili, come la quantità di codice scritto, la quantità di revisioni effettuate, la quantità di risorse risparmiate, il successo in termini di vendite o visite a pagine web, la capacità di recuperare la stabilità qualora bug – palesi o meno – diano problemi. Su questi parametri, quindi, si basava il successo personale dei dipendenti, le note positive dai manager e ai manager, e le promozioni. E questi parametri, nella creazione di un prodotto software, sono effettivamente parametri di enorme importanza, ma fanno perdere di vista l’importanza per nulla secondaria di una procedura di test funzionante che, non essendo facilmente misurabile (non si può provare che un programma non abbia bug, né la percentuale di bug individuati), sembra rubare tempo al miglioramento delle performance misurabili.

In un’azienda che gestisce un’infrastruttura in crescita molto rapida, però, risultava evidente la necessità di adottare quanto prima una procedura che permetta l’utilizzo dei sistemi automatici di testing. Trovare un bug critico su un sistema già online e in produzione nel 2006 poteva essere un problema risolvibile in poche ore, mentre trovarsi in una situazione del genere oggi o tra qualche anno, con strutture molto piú complesse di allora e con una fortissima interazione tra i vari prodotti, potrebbe essere catastrofico.

Forti di questa idea e di questa convinzione, gli ingegneri del Test Mercenaries si diedero da fare per adattare all’ambiente culturale di Google la loro procedura di azione.

Come primo passo, gli ingegneri assegnati ad un certo gruppo di lavoro dovevano conoscere le dinamiche interne del gruppo stesso. Dopo una serie di incontri con il responsabile, con il responsabile tecnico e con i membri del team presi singolarmente, si svolgeva una riunione con tutto il gruppo per definire quali fossero i problemi e quali obiettivi raggiungere. Ovviamente, tra gli obiettivi doveva essere presente il raggiungimento dello status di Test Certified. Gli incontri preliminari avevano anche lo scopo di vedere se valesse la pena tentare di lavorare, o se l’idea di una consulenza fosse una causa persa in partenza.

Ogni team di Test Mercenaries era composto da due persone, scelta effettuata notando le difficoltà psicologiche nel lavorare da soli, che risiedevano nelle immediate vicinanze del team da aiutare. Inizialmente, infatti, non si pose particolare attenzione nel far lavorare fisicamente vicini i consulenti e il team, ottenendo pessimi risultati ed evidenziando ancora una volta come la tecnica da sempre utilizzata da Google di favorire il piú possibile gli incontri tra i dipendenti fosse effettivamente vincente.

Alcuni team di Test Mercenaries, in particolare quelli diretti da Mike Bland, che guidò l’iniziativa a New York City, dedicavano le prime settimane di consulenza a leggere e commentare le revisioni di codice (code reviews). La tecnica delle revisioni, molto utilizzata nell’ambito del coding di gruppo, consiste in una banca dati delle decisioni tecniche, stilistiche e di progettazione definite nel codice, e commentate dai vari membri del team per darsi consigli, per motivare le scelte fatte e per criticare ciò che sembra necessario criticare. La lettura delle revisioni è un utile strumento per capire le dinamiche interne ad un gruppo di sviluppatori, e commentarle è un buon metodo per fare consulenza, almeno inizialmente, evidenziando cosa funzioni bene e cosa invece sia rischioso, senza urtare i sentimenti di nessuno. Ricevere critiche tramite revisioni, infatti, è qualcosa a cui si è già abituatissimi prima della consulenza.

Attraverso le revisioni, inoltre, è possibile iniziare già a fare piccole e grandi modifiche alle procedure utilizzate, in modo da renderle subito un po’ piú aderenti alle linee guida del Test Certified, e guadagnarsi la fiducia del team dimostrando di collaborare attivamente e senza eccessiva invadenza per il bene del progetto.

Passata questa prima fase e guadagnata la fiducia, diventava in genere (ma non sempre) possibile suggerire cambiamenti piú radicali e importanti tanto nelle scelte di progettazione, implementazione e tecniche e strumenti di test, quanto nei regolamenti interni su come lavorare, mettendo in atto i punti due e tre del programma Test Certified, i piú difficili da raggiungere in quanto di difficile misurabilità.

Idealmente, la consulenza doveva andare avanti per circa tre mesi, che presto diventò il tempo minimo di ingaggio. Nei team dove la collaborazione funzionò meglio, riuscendo a portare dei cambiamenti davvero radicali nella mentalità e nelle procedure, si andò però avanti ben oltre il tempo previsto, sia per non interrompere il lavoro in pieno svolgimento, sia perché la consulenza veniva richiesta.

Per le consulenze, soprattutto inizialmente, vennero scelti i team piú in vista e con i progetti di maggiore importanza, concentrandosi in particolare sul Googleplex, in maniera tale da ottenere visibilità.

In seguito ad ogni collaborazione veniva effettuata una riunione di verifica, per documentare quanto era stato fatto, cosa era andato bene e cosa male. Diverse verifiche furono molto incoraggianti, diverse altre lo furono molto poco, ma questa tecnica ha comunque permesso di affinare sempre di piú le procedure.

La richiesta aumentò abbastanza rapidamente, portando il Testing Grouplet a spostare tra i Test Mercenaries diverse persone di Google e ad assumere all’uopo nuovi dipendenti.

Questo provocò di fatto una separazione tra il Testing Grouplet, i Test Mercenaries e i responsabili di Test Certified, che avevano poche o nessuna intersezione di personale. Mike Bland, notando questo, propose di trovare una missione comune che permettesse ai tre gruppi di supportarsi a vicenda per il raggiungimento di uno stesso obiettivo, e l’obiettivo individuato fu quello di portare tutti i team di Google ad essere Test Certified entro la fine del 2009 (si era nel 2007).

Il primo passo della missione fu la proposta sul numero 49 di Testing on the Toilet, nella foto sopra, che includeva anche il logo di Testing Grouplet (le lampadine), quello di Test Certified (lo scudo) e quello dei Test Mercenaries (il cavaliere).

Gli strumenti di automazione e il know-how fino ad allora creato sembravano in effetti dare grandi speranze all’idea. L’unico punto davvero complesso era il raggiungimento del terzo livello di Test Certified, che richiedeva di dedicare tempo a cose con effetti non particolarmente misurabili. Ma il tempo richiesto dai test, grazie agli standard e ai toolchain automatici messi a disposizione dei team, era ormai davvero poco.

Nel pieno di queste speranze, però, arrivò la grande crisi economica del 2008. Tra le dure decisioni prese per farvi fronte, vi fu quella di tagliare la maggior parte dei consulenti, decisione che portò necessariamente allo scioglimento dei team di Test Mercenaries. Alcuni vennero riassunti da Google come dipendenti a tempo pieno, altri lasciarono.

Questo brusco finale sembra decretare l’insuccesso sostanziale del progetto, ma non è cosí. I Test Mercenaries hanno lasciato una enorme eredità di idee e di strumenti, cambiando il modo di lavorare di moltissimi gruppi di lavoro e creando le fondamenta per una piattaforma solida e comune di testing, evitando che bug critici vadano in produzione. Nel 2012, con le infrastrutture di Google ormai davvero enormi e intrecciate, avere un sistema serio di progettazione e testing è vitale.

Gli strumenti di test ideati dal Testing Grouplet e dai Test Mercenaries sono a tutt’oggi in continuo miglioramento e sviluppo, ed è stata implementata completamente una piattaforma automatizzata di test (la TAP, Test Automation Platform), ideata e proposta dai Mercenaries. Tale piattaforma riduce i tempi di test al punto che ormai tutti i team di Google, già dal 2010, sono di fatto Test Certified di livello 3, permettendo a Google di esistere cosí come è ora, senza timore di eventuali catastrofi.

Via | Mike Bland

Leave a Reply

Lorenzo Breda Articolo scritto da

Studente di Informatica a Roma, si occupa di programmazione web sopratutto lato server, e di accessibilità del web. Utilizza e ama Debian GNU/Linux, e si interessa di fisica, fumetto, trekking e fotografia (gli ultimi due possibilmente abbinati). Collabora con Googlab da aprile 2012.

Contatta l'autore

Previous post:

Next post: