Codice sorgente QA: non è più solo per gli sviluppatori

Vent'anni fa, quando lavoravo nell'industria automobilistica, il direttore di una fabbrica diceva spesso: "Abbiamo un giorno per costruire un'auto, ma il nostro cliente ha una vita per ispezionarla". La qualità era della massima importanza. Infatti, in settori più maturi come l'industria automobilistica e delle costruzioni, la garanzia della qualità è una considerazione fondamentale che viene sistematicamente integrata nel processo di sviluppo del prodotto. Sebbene ciò sia certamente determinato dalla pressione delle compagnie assicurative, è anche dettato, come ha notato il direttore della fabbrica, dalla durata della vita del prodotto risultante.

Quando si tratta di software, tuttavia, cicli di vita più brevi e aggiornamenti continui significano che l'integrità del codice sorgente viene spesso trascurata a favore di nuove funzionalità, funzionalità sofisticate e velocità di immissione sul mercato. I product manager spesso deprioritizzano la garanzia della qualità del codice sorgente o lasciano che siano gli sviluppatori a occuparsene, nonostante sia uno dei fattori più critici nel determinare il destino di un prodotto. Per i product manager preoccupati di costruire una solida base per lo sviluppo del prodotto e di eliminare i rischi, è essenziale definire e implementare una valutazione sistematica della qualità del codice sorgente.

Definizione di “qualità”

Prima di esplorare i modi per valutare e attuare correttamente un processo di QA del codice sorgente, è importante determinare cosa significa "qualità" nel contesto dello sviluppo del software. Questa è una questione complessa e sfaccettata, ma per semplicità, possiamo dire che la qualità si riferisce al codice sorgente che supporta la proposta di valore di un prodotto senza compromettere la soddisfazione del consumatore o mettere in pericolo il modello di business della società di sviluppo.

In altre parole, il codice sorgente di qualità implementa accuratamente le specifiche funzionali del prodotto, soddisfa i requisiti non funzionali, garantisce la soddisfazione dei consumatori, riduce al minimo i rischi legali e di sicurezza e può essere mantenuto ed esteso in modo conveniente.

Data la diffusione e la rapidità con cui il software viene distribuito, l'impatto dei difetti del software può essere significativo. Problemi come bug e complessità del codice possono danneggiare i profitti di un'azienda ostacolando l'adozione del prodotto e aumentando i costi di gestione delle risorse software (SAM), mentre le violazioni della sicurezza e della conformità delle licenze possono influire sulla reputazione dell'azienda e sollevare problemi legali. Anche quando i difetti del software non hanno risultati catastrofici, hanno un costo innegabile. In un rapporto del 2018, la società di software Tricentis ha rilevato che 606 errori software di 314 aziende hanno rappresentato $ 1,7 trilioni di entrate perse l'anno precedente. In un rapporto del 2020 appena pubblicato, CISQ ha valutato il costo del software di scarsa qualità negli Stati Uniti a $ 2,08 trilioni, con altri $ 1,31 trilioni stimati di costi futuri sostenuti a causa del debito tecnico. Questi numeri potrebbero essere mitigati con interventi precedenti; il costo medio della risoluzione di un problema durante la progettazione del prodotto è significativamente inferiore rispetto alla risoluzione dello stesso problema durante il test, che a sua volta è esponenzialmente inferiore rispetto alla risoluzione del problema dopo l'implementazione.

Manipolazione della patata bollente

Nonostante i rischi, la garanzia della qualità nello sviluppo del software è trattata in modo frammentario ed è caratterizzata da un approccio reattivo piuttosto che da quello proattivo adottato in altri settori. La titolarità della qualità del codice sorgente è contestata, quando va vista come responsabilità collettiva di diverse funzioni. I product manager devono considerare la qualità come una caratteristica di impatto piuttosto che un sovraccarico, i dirigenti dovrebbero prestare attenzione allo stato della qualità e investire in esso e le funzioni di progettazione dovrebbero evitare di trattare la pulizia del codice come una "patatina bollente".

Ad aggravare queste sfide di delega c'è il fatto che le metodologie e gli strumenti esistenti non riescono ad affrontare il problema della qualità del codice nel suo insieme. L'uso di metodologie di integrazione continua/fornitura continua riduce l'impatto del codice di bassa qualità, ma a meno che CI/CD non sia basato su un'analisi della qualità completa e olistica, non può anticipare e affrontare efficacemente la maggior parte dei rischi. I team responsabili del test del controllo qualità, della sicurezza delle applicazioni e della conformità delle licenze lavorano in silos utilizzando strumenti progettati per risolvere solo una parte del problema e valutare solo alcuni dei requisiti non funzionali o funzionali.

Considerando il ruolo del Product Manager

La qualità del codice sorgente gioca in numerosi dilemmi che un product manager deve affrontare durante la progettazione del prodotto e durante tutto il ciclo di vita dello sviluppo del software. Il debito tecnico è pesante. È più difficile e costoso aggiungere e modificare funzionalità su una base di codice di bassa qualità e supportare la complessità del codice esistente richiede investimenti significativi di tempo e risorse che potrebbero altrimenti essere spesi per lo sviluppo di nuovi prodotti. Poiché i product manager bilanciano continuamente il rischio con la velocità di immissione sul mercato, devono considerare domande come:

• Devo usare una libreria OSS (software open source) o creare funzionalità da zero? Quali licenze e potenziali responsabilità sono associate alle biblioteche selezionate?
• Quale stack tecnologico è più sicuro? Che garantisce un ciclo di sviluppo veloce ed economico?
• Devo dare priorità alla configurabilità dell'app (costo/tempo di ritardo elevato) o implementare versioni personalizzate (costo di manutenzione elevato/mancanza di scalabilità)?
• Quanto sarà fattibile integrare i prodotti digitali di nuova acquisizione mantenendo un'elevata qualità del codice, riducendo al minimo i rischi e mantenendo bassi i costi di progettazione?

Le risposte a queste domande possono avere un serio impatto sui risultati aziendali e sulla reputazione del product manager, tuttavia le decisioni vengono spesso prese sulla base dell'intuizione o dell'esperienza passata piuttosto che su indagini rigorose e solide metriche. Un accurato processo di valutazione della qualità del software non solo fornisce i dati necessari per il processo decisionale, ma allinea anche le parti interessate, crea fiducia e contribuisce a una cultura della trasparenza, in cui le priorità sono chiare e concordate.

Implementazione di un processo in 7 fasi

Un processo completo di valutazione della qualità del codice sorgente si traduce in una diagnosi che considera l'insieme completo delle determinazioni della qualità piuttosto che alcuni sintomi isolati di un problema più ampio. Il metodo in sette fasi presentato di seguito è in linea con le raccomandazioni del CISQ per il miglioramento dei processi e ha lo scopo di facilitare i seguenti obiettivi:

• Trova, misura e risolvi il problema vicino alla sua causa principale.
• Investi in modo intelligente nel miglioramento della qualità del software basato su misurazioni della qualità complessiva.
• Affronta il problema analizzando l'insieme completo di misurazioni e identificando i miglioramenti migliori e più convenienti.
• Considerare il costo completo di un prodotto software, inclusi i costi di proprietà, manutenzione e allineamento tra licenza e regolamentazione della sicurezza.
• Monitora la qualità del codice in tutto l'SDLC per evitare spiacevoli sorprese.

1. Mappatura da prodotto a codice: rintracciare le caratteristiche del prodotto nella loro base di codice può sembrare un primo passo ovvio, ma data la velocità con cui aumenta la complessità dello sviluppo, non è necessariamente semplice. In alcune situazioni, il codice di un prodotto è diviso tra più repository, mentre in altre più prodotti condividono lo stesso repository. L'identificazione delle varie posizioni che ospitano parti specifiche del codice di un prodotto è necessaria prima che possa aver luogo un'ulteriore valutazione.

2. Analisi dello stack tecnologico: questo passaggio prende in considerazione i vari linguaggi di programmazione e strumenti di sviluppo utilizzati, la percentuale di commenti per file, la percentuale di codice generato automaticamente, il costo medio di sviluppo e altro ancora.

Strumenti consigliati: cloc

Alternative: Tokei, scc, sloccount

3. Analisi delle versioni: sulla base dei risultati di questa parte dell'audit, che prevede l'identificazione di tutte le versioni di una base di codice e il calcolo delle somiglianze, è possibile unire le versioni ed eliminare le duplicazioni. Questo passaggio può essere combinato con un'analisi dei bugspot (hot spot), che identifica le parti delicate del codice che vengono riviste più frequentemente e che tendono a generare costi di manutenzione più elevati.

Strumenti consigliati: cloc, scc, sloccount

4. Revisione automatizzata del codice: questa ispezione esamina il codice alla ricerca di difetti, violazioni delle pratiche di programmazione ed elementi rischiosi come token hardcoded, metodi lunghi e duplicazioni. Gli strumenti selezionati per questo processo dipenderanno dai risultati dello stack tecnologico e dalle analisi delle versioni di cui sopra.

Strumenti consigliati: SonarQube, Codacy

Alternative: RIPS, Veracode, Micro Focus, Parasoft e molti altri. Un'altra opzione è Sourcegraph, una soluzione di ricerca di codice universale.

5. Analisi della sicurezza statica: questo passaggio, noto anche come test di sicurezza delle applicazioni statiche (SAST), esplora e identifica potenziali vulnerabilità della sicurezza delle applicazioni. La maggior parte degli strumenti disponibili esegue la scansione del codice rispetto ai problemi di sicurezza che si verificano frequentemente identificati da organizzazioni come OWASP e SANS.

Strumenti consigliati: WhiteSource, Snyk, Coverity

Alternative: SonarQube, Reshift, Kiuwan, Veracode

6. Analisi dei componenti software (SCA)/Analisi della conformità delle licenze: questa revisione implica l'identificazione delle librerie open source collegate direttamente o indirettamente al codice, le licenze che proteggono ciascuna di queste librerie e le autorizzazioni associate a ciascuna di queste licenze.

Strumenti consigliati: Snyk, WhiteSource, Black Duck

Alternative: FOSSA, Sonatype e altri

7. Analisi del rischio aziendale: questa misura finale prevede il consolidamento delle informazioni raccolte dai passaggi precedenti al fine di comprendere l'impatto completo dello stato di qualità del codice sorgente sull'azienda. L'analisi dovrebbe sfociare in un report completo che fornisce alle parti interessate, inclusi product manager, project manager, team di ingegneri e dirigenti della C-suite, i dettagli di cui hanno bisogno per valutare i rischi e prendere decisioni informate sui prodotti.

Sebbene i passaggi precedenti di questo processo di valutazione possano essere automatizzati e facilitati tramite un'ampia gamma di prodotti open source e commerciali, non esistono strumenti esistenti che supportino l'intero processo in sette fasi o l'aggregazione dei suoi risultati. Poiché la compilazione di questi dati è un'attività noiosa e dispendiosa in termini di tempo, viene eseguita a caso o saltata del tutto, mettendo potenzialmente a rischio il processo di sviluppo. Questo è il punto in cui un accurato processo di ispezione del software spesso va in pezzi, rendendo questo ultimo passaggio probabilmente il più critico nel processo di valutazione.

Selezione degli strumenti giusti

Sebbene la qualità del software influisca sul prodotto e quindi sui risultati di business, la selezione degli strumenti è generalmente delegata ai dipartimenti di sviluppo ei risultati possono essere difficili da interpretare per i non sviluppatori. I product manager dovrebbero essere coinvolti attivamente nella selezione di strumenti che garantiscano un processo di QA trasparente e accessibile. Sebbene siano stati suggeriti strumenti specifici per le varie fasi della valutazione, vi sono una serie di considerazioni generali che dovrebbero essere prese in considerazione in qualsiasi processo di selezione degli strumenti:

• Stack tecnologico supportato: tieni presente che la maggior parte delle offerte disponibili supporta solo un piccolo insieme di strumenti di sviluppo e può generare report parziali o fuorvianti.
• Semplicità di installazione: gli strumenti i cui processi di installazione sono basati su script complessi possono richiedere un investimento ingegneristico significativo.
• Rapporti: è necessario dare la preferenza agli strumenti che esportano rapporti dettagliati e ben strutturati che identificano i problemi principali e forniscono consigli per correzioni.
• Integrazione: gli strumenti devono essere selezionati per una facile integrazione con gli altri strumenti di sviluppo e gestione utilizzati.
• Prezzi: gli strumenti raramente vengono forniti con un listino prezzi completo, quindi è importante considerare attentamente l'investimento necessario. I vari modelli di prezzo in genere tengono conto di aspetti come l'organico del team, la dimensione del codice e gli strumenti di sviluppo coinvolti.
• Distribuzione: quando si valuta la distribuzione on-premise rispetto a quella cloud, considerare fattori come la sicurezza. Ad esempio, se il prodotto da valutare gestisce dati riservati o sensibili, potrebbero essere preferibili strumenti in loco e strumenti che utilizzino l'approccio blind-audit (FOSSID).

Continuando così

Una volta che i rischi sono stati identificati e analizzati metodicamente, i product manager possono prendere decisioni ponderate sulla definizione delle priorità e sulla valutazione dei difetti in modo più accurato. I team potrebbero essere ristrutturati e le risorse allocate per affrontare le questioni più emergenti o prevalenti. Gli "spettacoli" come le violazioni delle licenze ad alto rischio avrebbero la precedenza sui difetti di gravità inferiore e verrebbe posta maggiore enfasi sulle attività che contribuiscono alla riduzione delle dimensioni e della complessità della base di codice.

Questo non è un processo una tantum, tuttavia. La misurazione e il monitoraggio della qualità del software dovrebbero avvenire continuamente in tutto l'SDLC. La valutazione completa in sette fasi dovrebbe essere condotta periodicamente, con sforzi di miglioramento della qualità che iniziano immediatamente dopo ogni analisi. Più velocemente viene identificato un nuovo punto di rischio, più economico sarà il rimedio e più limitate saranno le ricadute. Rendere la valutazione della qualità del codice sorgente al centro del processo di sviluppo del prodotto concentra i team, allinea le parti interessate, riduce i rischi e offre a un prodotto le migliori possibilità di successo, e questo è il business di ogni product manager.