Voglio diventare... QA Expert
Oggi portiamo sul palco un grande nome del settore, che di vite ne ha vissute almeno 7: Paolo Caressa ci racconta cosa vuol dire lavorare nell’ambito della QA, ossia uno dei valori fondamentali che dovrebbe guidare lo sviluppo del software… la qualità.
Descriviti in 100 parole.
Sono nato dopo il Basic ma prima del C: ho iniziato a programmare a 12 anni su uno ZX Spectrum 16K e da allora non ho più smesso di scrivere codice; nel mio terzo decennio di vita ho preso laurea e dottorato in matematica pura e fatto il ricercatore universitario; poi sono stato consulente e dipendente di aziende (finanza, software, energy) con varie label: dev, quant, pm, account, r&d, qa. Sul mio contratto attuale c’è scritto che sono un IT Expert: e chi sono io per affermare il contrario? C’è chi legge quel che scrivo e ascolta quel che dico.
In cosa consiste il ruolo di QA (Quality Assurance);
Parafrasando un bellissimo film, potremmo intitolare questo mestiere: Il software degli altri. Assicurare la qualità di un software non si riduce (solo) a farne l’analisi statica o dei collaudi, per quanto approfonditi: vuol dire che un prodotto, sia di mercato che custom, commissionato per svolgere un compito deve svolgere esattamente quel compito; volendo essere tolleranti, deve svolgere almeno quel compito.
L’attività di QA fa parte di un processo parallelo alle varie fasi del ciclo di vita di un progetto o di un prodotto, per esempio con dei check al termine delle singole fasi di questo ciclo di vita, etc. La svolgono normalmente i PM, in teoria i progetti dovrebbero avere dei quality manager allo scopo.
Tuttavia, così come esistono i PMO e i SOC, in molte realtà esiste anche un QA Team, un gruppo che offre servizi di verifica della qualità a chi ne ha la necessità o, meno idealisticamente, a chi deve sottoporsi a queste forche caudine perché i processi aziendali lo prevedono.
Un progetto è una impresa cooperativa fra soggetti competitivi: dev, analisti, PM. In tutto questo c’è un codice da sviluppare, testare e rilasciare spesso con dei tempi ristretti e change request che possono piombare in qualsiasi momento. La qualità del prodotto ai fini della manutenibilità, le pratiche di codifica e controllo versione del codice, la documentazione che poi finirà in mano al cliente finale e molto altro sono ai lati della strada lungo la quale bisogna correre perché toccava arrivare a destinazione ieri.
La prima regola con i sistemi di qualità è che, se sono codificati, vanno socraticamente accettati: se non ci stanno bene dobbiamo lottare per modificarli in modo che al prossimo giro vada meglio (forse) ma nel frattempo rispettarli. Il QA deve quindi conoscere il processo, non necessariamente amarlo o condividerlo, e deve tendere al bene e non all’ottimo: la sua azione ha sempre un impatto malvisto da chi vive all’interno del progetto, quindi deve incidere il meno possibile e, a seconda delle circostanze, guardare al concreto e all’indispensabile.
La documentazione continua a essere lo strumento principale dei sistemi di qualità: in fondo documentare quel che si fa mentre lo si sta facendo è una prassi che aiuta a farlo meglio, pensiamo ai commenti nel codice. Tutti ci crediamo in grado di scrivere commenti nel codice e conosco persone che li ritengono superflui (“basta conoscere il linguaggio e dare nomi parlanti alle variabili”). Poi, facendo una analisi a campione, vediamo codice involuto e non idiomatico privo di commento, commenti del tutto scorrelati dal codice limitrofo (rimasti lì orfani di un copia-incolla frettoloso) o commenti obsoleti rispetto al codice, o codice commentato (nell’epoca dei sistemi di controllo versione!). Lo stesso si applica alla documentazione tecnica (di progettazione, di descrizione dei casi d’uso e di test, alla manualistica, etc.) e amministrativa (il project charter o un documento equivalente, etc.).
La documentazione spesso è realizzata su sistemi di collaborazione: bellissimo. Ma anche in questo caso può essere fatta male: lo strumento aiuta a essere efficienti ma è la nostra testa che ci rende efficaci.
Quindi chi e cosa fa il QA? Verifica la conformità nell’uso degli strumenti aziendali? Ovvio. Entra nel merito del ciclo di vita di un requisito per verificarne la tracciabilità? Certamente. Verifica che la documentazione pallosa non sia una sequela di “lore ipsum”? Anche. Prova a mettersi nei panni di chi farà manutenzione del sistema dopo qualche tempo o anche di un auditor assetato di sangue che chiederà conto di qualcosa mesi dopo? Pure e soprattutto.
Insomma, si fa un po’ tutto e un po’ niente, si corre come l’arbitro durante una partita ma non si fa mai goal e si fischia un rigore col sorriso sulle labbra quando metà dello stadio vorrebbe farti la pelle. Ma è l’IT, baby!
Qual è la soft skill più importante che deve possedere QA?
Ne direi due secondo me molto correlate: empatia e comunicativa. Si ha a che fare col lavoro, e quindi con la fatica, degli altri, si deve capire il punto di vista di ogni attore della filiera sottoposta al processo di qualità, ci vuole comprensione della diversità dei punti di vista e del contesto. Occorre saper interagire nel team e fuori di esso usando i giusti registri con gli interlocutori giusti e minimizzando comunicazioni inutili e dannose che risulterebbero solo entropiche.
La maggior parte di noi utilizza i social per parlare dei propri successi, ma la realtà è che siamo quel che siamo grazie al 90% dei nostri errori. Racconta il tuo più grande fallimento da quando lavori nel settore, che però ti ha reso ciò che sei.
Ho imparato molto da una situazione nella quale, sperando di ottimizzare il processo, ho introdotto una maggiore flessibilità e deroghe parziali al sistema di qualità per riuscire a sbloccare situazioni critiche. Ma, esattamente come aggiungere persone in corsa a un progetto che sta in ritardo lo fa ritardare ulteriormente, una particolare attenzione e tolleranza nei confronti di un prodotto di bassa qualità la possono far abbassare ancora di più. Nel dubbio meglio seguire le regole: è sempre bello essere flessibili ma anche rispettare le regole che ci sono date o che ci siamo dati.
Come fare per diventare QA? (Esempio: servono/sono utili certificazioni, esperienze precedenti particolari, competenze necessarie, tecnologie, tips&tricks ecc.);
Io mi sono ritrovato a fare questo mestiere dopo averlo subito da altri e direi che questa è la strada migliore per farlo non dico bene ma almeno in modo sensato.
Parlando di successi, qual è il tuo prossimo obiettivo? Quale ruolo vorresti ricoprire entro i prossimi 3 anni?
Non ho mai avuto aspettative rispetto ai ruoli ma rispetto ai contenuti: al momento sono un po’ lontano dalla parte più tecnica dell’attività ma questo mi consente di imparare ed estendere le mie competenze, esperienze e perplessità. E poi, come si dice a Roma, e come ormai si dovrebbe dire alla mia età: “fra tre anni beato chi c’ha un occhio!”.
Conosci il tema gender gap in ambito STEM? Se sì, secondo te, come fare per superarlo? (Fai anche riferimenti a situazioni reali in cui hai avuto modo di fare la tua parte!)
Non solo in ambito STEM: è vero che la vulgata vuole che in ambiti non tecnici ci sia più proporzionalità fra uomini e donne ma questa non è equidistribuita per livelli di responsabilità: quando pensiamo a un segretario lo pensiamo ancora femmina, quando pensiamo a un CEO lo pensiamo ancora maschio. Nel settore IT trovo ci sia una penalizzazione a priori incomprensibile: ho avuto modo nella mia carriera di lavorare molto in team con ragazze e donne e devo dire che sembrano avere una marcia in più proprio per questo tipo di mestiere e settore; che ce ne siano così poche, che so nel ruolo di PM o di CTO per non parlare delle dev, si spiega soltanto con una maggiore difficoltà sistemica nell’accedere alle posizioni che meritano.
Per superare questo stato di cose occorre un salto culturale che riguarda necessariamente anche la società nel suo complesso ma, per non essere astratti e fumosi, direi che un primo sano esercizio di consapevolezza per noi maschietti è imparare ad ascoltare di più le nostre colleghe e a riflettere su quanto spesso sarebbero più adatte a ricoprire una posizione che ricopriamo noi. Acquisire consapevolezza da parte degli uomini è secondo me il primo passo per far cadere le barriere che magari inconsapevolmente contribuiamo a costruire o a mantenere.
