A Roma, in questi giorni si sta verificando una situazione che merita attenzione: l’Anagrafe sta riscontrando numerosi problemi bloccanti durante l’esecuzione del nuovo gestionale che si è scelto di adottare.
In un articolo del Corriere, a firma di Ester Palma, si apprende che il nuovo sistema gestionale messo in esecuzione all’interno degli uffici dell’anagrafe, produce anomalie, penuria di dati certi, mancata integrazione tra i sistemi e continui errori di comunicazione. La scelta di implementare un software in una realtà complessa come una pubblica amministrazione (sia essa centrale o locale), richiederebbe un collaudo passante per un periodo di test-bed al fine di saggiare la funzionalità del software in modo concreto ma, al contempo, sicuro.
Nel 2020, su questo sito, si era ampiamente scritto della fase di collaudo nei progetti della P.A., che dovrebbe precedere il rilascio e garantire una messa in esercizio sicura ed efficiente. Viene quindi da domandarsi come sia possibile l’insorgenza di tali errori. Bisogna inoltre tenere presente che la stessa Anagrafe, prima di queste problematiche, era stata vittima di nove giorni di blocco totale a causa di malfunzionamenti applicativi.
Mentre i dipendenti dell’Anagrafe fanno fronte comune e chiedono il supporto dei sindacati con un’assemblea prevista per l’8 aprile, è bene ricordare che la storia dell’Anagrafe va ad inserirsi in un contesto più ampio come il caso dello scudo anti pirateria (Piracy Shield), voluto da AgCom e di cui si sta parlando da molto tempo. La realizzazione di soluzioni tecnologiche non opportunamente “calate nella realtà operativa”, genera problematiche di misura severa e può arrivare a causare errori bloccanti. Per approfondire l’argomento si raccomanda la lettura di questo articolo pubblicato da Wired. Nel caso dello scudo anti pirateria si palesa il rischio di possibili danni economici alle vittime del blocco, qualora il sito in questione svolga attività di commercio elettronico e si ritrovi ingiustamente bloccato con conseguenze sui propri profitti.
Si potrebbe anche parlare dell’interruzione dei servizi del Comune di Roma, di cui ha parlato Roma Today nell’articolo “Perchè il sistema informatico del Comune è andato in tilt paralizzando uffici e servizi“, del 28 marzo 2024 a firma di Sara Mechelli. Il disservizio è stato causato da un malfunzionamento che è durato giorni.
Abbiamo iniziato a ravvisare stranezze già da lunedì, così da subito ci siamo interfacciati con il dipartimento di trasformazione digitale che ci ha informati dell’intervento legato alla cybersecurity. Un’operazione che però ha impattato su tutto quello che dialoga con il sistema”. Si sono bloccati così pagamenti, anagrafe, protocollo e applicazioni minori come le scannerizzazioni. Una paralisi totale tanto che alcuni certificati ed estratti particolarmente urgenti, come nascite e decessi, sono stati fatti a mano.
Andrea Catarci, Assessore al Personale, Roma Capitale
Quando la tecnica viene penalizzata a monte o a valle
I due episodi sono diversi ma uniti da alcuni punti in comune. La progettazione di soluzioni informatiche non può essere fatta “sulla carta”; deve, invece, essere attentamente studiata in base alla “realtà” che, successivamente, la ospiterà. Non è possibile realizzare soluzioni informatiche che superano il vaglio dei collaudi intermedi di sviluppo e che, in fase di implementazione collassano o creano problemi bloccanti.
Nel caso dell’Anagrafe, dove si parla di nuovo sistema gestionale, è possibile immaginare che la soluzione sia stata sviluppata in modalità Agile, con rilasci graduali tutti oggetto di collaudo formale. Per sapere di più su questa metodologia è possibile consultare il manifesto ufficiale e ricavarne quindi i dodici principi.
Il test è una procedura essenziale, delicata, che può (e dovrebbe) vedere il coinvolgimento anche di “non tecnici” come giustamente ha spiegato più volte l’Ing.Davide Messia (Test Coordinator in Sisal. Fondatore dell’ Oracolo del Test la prima community italiana dedicata al testing). È bene tenere presente una cosa: il costo di un’applicazione mal realizzata rappresenta una vera e propria emorragia per l’organizzazione che si ritrova a dove sanare la situazione.
Lo stesso Davide Messia, durante il video “Alla scoperta del Software Testing” di Code & Converse, ha presentato i dati del Consorzio per l’Informazione e la Qualità (CISQ) in merito ai costi derivanti dal codice mal scritto. Il Consorzio avrebbe stimato che, negli Stati Uniti, nel 2020 il costo è stato di 2.08 trilioni di dollari, mentre nel 2022 è stato di 2.41 trilioni di dollari. I dati a cui fa riferimento Messia sono corretti: provengono infatti dal report “The Cost of Poor Software Quality in the US: A 2022 Report“.
Ma cosa c’è dentro questi 2.41 trilioni di dollari? Quali sono i problemi principali?
Il grafico riportato proviene proprio dal report e mostra un’interessante molteplicità di aspetti in cui è possibile notare non solo gli ormai noti problemi di cybersecurity ma, soprattutto, la persistenza di sistemi vetusti ed inadatti ad accogliere software di ultima generazione, unitamente a progetti abbandonati.
Ludovico Besana, QA Engineer @AideXa, spiega molto bene a cosa serve l’attività di testing, ossia a “trovare problemi nelle applicazioni che la gente usa ogni giorno, in modo che possano essere risolti prima che gli utenti li incontrino durante l’utilizzo di un sito o app.”
Come funziona un test in modalità Agile?
Bisogna tenere presente che nella metodologia Agile è previsto che ogni componente software auto-consistente venga sottoposta a collaudo prima del rilascio. Di conseguenza non vi è un singolo collaudo finale, come avveniva nelle tradizionali metodologie di sviluppo, bensì una serie numerosa di test mirati proprio a collaudare la singola funzione rilasciata. Ogni componente viene sviluppato in un arco di tempo definito sprint e poi sottoposto alla valutazione del cliente. Il collaudo deve basarsi su specifici criteri:
- Coinvolgimento precoce del team di QA: i tester sono coinvolti fin dalle fasi iniziali del progetto, collaborando con gli sviluppatori e gli stakeholder per comprendere i requisiti e le funzionalità del software.
- Definizione degli scenari di test: vengono identificati gli scenari di test basati sui requisiti e sulle esigenze espresse dagli utenti (user stories); questi scenari descrivono i comportamenti attesi del software.
- Pianificazione dei test: i test vengono pianificati all’inizio di ogni sprint, insieme alle altre attività di sviluppo; vengono anche stabilite le priorità e le risorse necessarie per eseguire i test in modo efficace.
- Automazione dei test: quando possibile, i test vengono automatizzati per ridurre i tempi di esecuzione e garantire una copertura più ampia del codice. Gli strumenti di automazione vengono utilizzati per creare e eseguire i test in modo efficiente ma non sono l’unico mezzo adoperato nei test.
- Esecuzione dei test: i test vengono eseguiti durante l’intero ciclo di sviluppo e sono di diversa tipologia: test di unità, test di integrazione, test di accettazione e test di regressione.
- Feedback rapido: i risultati dei test vengono valutati rapidamente e condivisi con il team di sviluppo. In base ai risultati, vengono apportate modifiche al codice o ai requisiti, se necessario.
- Retrospettiva: alla fine di ogni iterazione, il team si riunisce per una retrospettiva e per valutare cosa ha funzionato bene e cosa può essere migliorato nei processi di sviluppo e nei test. Questo feedback viene utilizzato per iterare e migliorare continuamente il processo.
In sintesi, i test software nella modalità Agile sono integrati nell’intero ciclo di sviluppo, consentendo un rilascio più rapido e affidabile del software, con un focus sulla collaborazione, sulla comunicazione e sull’adattamento continuo. Ne consegue che se la metodologia Agile viene adottata adeguatamente e se i test vengono eseguiti correttamente, non si possono verificare fenomeni così macroscopici come quelli descritti in precedenza.
Giova ricordare che il collaudo è un’attività che richiede anche una commissione che valuti e approvi il test eseguito; l’attività, inoltre, è propedeutica alla fatturazione. Se tali aziende sono state pagate, pertanto, è perché qualcuno ha sottoscritto il successo dei collaudi e questo riporta il problema alle modalità con cui vengono eseguiti i test.
Come è composta la Commissione di Collaudo?
Non c’è chiaramente una regola predefinita ma ci sono una serie di considerazioni che si possono fare in merito. La commissione di collaudo è un gruppo di persone incaricato di valutare la conformità e la qualità del software rispetto ai requisiti specificati e la sua formazione è cruciale per garantire un processo di valutazione efficace ed imparziale. Tipicamente, la commissione è composta da membri esperti, inclusi rappresentanti degli utenti finali (stakeholders), gli sviluppatori, i tester ed il personale dell’organizzazione interessato dalle varie funzioni dell’applicativo. Questi membri portano competenze diverse che consentono una valutazione completa e accurata del software.
Prima del collaudo, è essenziale definire criteri di valutazione chiari e obiettivi di test, assicurando che tutti i membri della commissione li comprendano pienamente. Durante il collaudo, la commissione esegue una serie di test, valutando il software in base ai criteri stabiliti e registrando eventuali difetti o problemi riscontrati, ovviamente il risultato del collaudo influenza le decisioni sul rilascio del software.
Conclusioni
Nei casi sopra descritti è quindi logico (e lecito) domandarsi in che modo si siano svolte le attività di collaudo intermedio e quelle subito precedenti al rilascio del software che, una volta messo in esercizio, rivela problematiche così numerose, bloccanti e consistenti, da causare la paralisi dell’applicativo se non addirittura conseguenze e economiche a terze parti. È comunque evidente ciò che in più occasioni ha avuto modo di ribadire l’Ing. Messia: c’è decisamente poca cultura in ambito di test, collaudo e più in generale in quella che definiamo la quality assurance.
