Come viene gestito il processo di Quality Assurance di LibreOffice ?

Prima di tutto, dopo dieci anni di grande manualità parliamo finalmente di un processo automatizzato che viene integrato solo alla fine dall’intervento manuale degli esperti di Quality Assurance, all’interno di un progetto che ha già introdotto centinaia di nuove funzionalità – nella maggior parte dei casi di piccola entità, ma abbiamo già spiegato il perché – e quindi centinaia di rischi di instabilità, di bug e di regressioni (e quindi ha bisogno di un’attività di QA molto più massiccia di un progetto che introduce un numero molto più ridotto di funzionalità).

La Quality Assurance comincia da Gerrit, un sistema web based di revisione del codice che semplifica il processo per tutti i progetti che utilizzano GIT, consente a tutti gli sviluppatori autorizzati di introdurre le modifiche su Master, ed evita che questa operazione venga eseguita manualmente.

Una volta che le patch sono state introdotte su Master, intervengono i TinderBox – oggi sono una ventina, sparsi in ogni parte del mondo (alcune macchine sono state acquistate da The Document Foundation, altre sono state donate da enti e aziende) – che permettono agli sviluppatori di gestire le build e di mettere in relazione gli errori di compilazione sulle diverse piattaforme con l’introduzione di specifici cambiamenti.

Qualcuno ha definito i TinderBox come “detective per lo sviluppo del software”, e la loro presenza viene considerata fondamentale da moltissimi esperti di sviluppo e di ingegneria del software.

E infatti, se la compilazione non va a buon fine, il sistema di gestione dei TinderBox avverte con un email gli sviluppatori delle circa 20 patch inserite su Master dopo l’ultimo risultato positivo, e gli chiede di fare un controllo un po’ più approfondito del proprio codice per verificare che non sia quello responsabile dell’errore.

In questo modo, molti problemi vengono intercettati prima dell’arrivo sui build utilizzati per i test automatizzati, che sono circa 120 e simulano diverse condizioni d’uso di LibreOffice, da quelle più semplici come l’apertura e la chiusura di un file a quelle più complesse come l’esecuzione di calcoli complessi su un foglio elettronico di grandi dimensioni.

Superati anche i test automatizzati, LibreOffice è pronto per l’intervento manuale del gruppo dei volontari che si occupano di Quality Assurance, che eseguono una serie aggiuntiva di test che riproducono un ambiente reale di utilizzo della suite (i test automatizzati sono sempre un po’ asettici, anche se sono molto utili).

Prima delle Major Release, è ormai consuetudine la Bug Hunting Week (la settimana di caccia ai bug), durante la quale vengono rilevati – e auspicabilmente chiusi – i bug più significativi che affliggono la nuova versione, quando la suite è ancora a livello di beta o di release candidate.

Naturalmente, l’intervento dei volontari di Quality Assurance non si limita alle fasi di rilascio delle nuove versioni, che sono fondamentali, ma continua durante tutto il periodo di disponibilità del prodotto. In particolare, i volontari verificano i bug riproducendoli, e cercano anche di individuare lo sviluppatore più adatto per la soluzione del problema.

Nel caso delle regressioni, ovvero quelle funzionalità che si comportavano in modo corretto in una versione precedente di LibreOffice, gli sviluppatori hanno creato uno strumento che permette di rendere più veloce l’identificazione del momento in cui è stato introdotto il codice responsabile del problema, utilizzando la tecnologia BiBisect (Binary Bisection).

L’idea è stata di Bjoern Michaelsen, che è riuscito a “comprimere” tutte le compilazioni che portano a una Major Release dentro a un unico file, di grandi dimensioni (circa 4 gigabyte), navigabile con i comandi GIT. In questo modo, si riescono a isolare con una certa facilità la compilazione precedente e quella successiva alla regressione, in modo tale da lavorare su un insieme circoscritto di patch (e individuare quella responsabile del problema).

Purtroppo, il sistema di gestione dei bug – Bugzilla – è ancora un po’ troppo complesso per un progetto che coinvolge la massa degli utenti, nonostante siano stati fatti dei tentativi di semplificazione che hanno prodotto un’interfaccia “facile” per gli sviluppatori ma ancora troppo complessa per i comuni mortali (io stesso non ho ancora capito fino in fondo come funziona).

Gli utenti, però, non devono scoraggiarsi di fronte a questa difficoltà, e se hanno individuato un bug di cui sono assolutamente certi devono segnalarlo almeno sulla lista utenti, dove sono presenti volontari in grado di tradurre le indicazioni – anche sommarie – in un nuovo record su Bugzilla (che consentirà agli sviluppatori di intervenire e risolvere il problema).