Modelli riepilogativi

Colonna Colonna corrispondente nel rapporto riassuntivo

Nr. Famiglie Indicazione del territorio geografico (nome regione, nome provincia, nome comune, numero sezione)

Persone abitualmente dimoranti Maschi Nr. totale di righe nello stato ‘Inserita lista’.

Persone abitualmente dimoranti Femmine Nr. totale di individui di sesso maschile abitualmente dimoranti. Persone abitualmente dimoranti Totale Nr. totale di individui di sesso femminile abitualmente dimoranti . Persone abitualmente dimoranti Di cui stranieri

maschi ^{Nr. totale di individui abitualmente dimoranti .} Persone abitualmente dimoranti Di cui stranieri

femmine

Nr. totale di individui stranieri abitualmente dimoranti maschi

Totale stranieri Nr. totale di individui stranieri abitualmente dimoranti femmine

5.7 Test

Il test ha come principale obiettivo la verifica della correttezza funzionale di una applicazione rispetto ai requisiti del committente (test funzionali), ma sempre più spesso viene usato come tecnica di base per la realizzazione di controlli mirati alla valutazione di altri fattori di qualità come ad esempio affidabilità, usabilità (si vuole valutare la facilità d’uso dell’applicazione da parte dell’utente finale), efficienza, sicurezza, interoperabilità, prestazioni (test di carico: l’applicazione è sottoposta al carico di lavoro massimo previsto dai requisiti e le sue funzionalità sono controllate in

queste condizioni), robustezza (stress test: l’applicazione è sottoposta a carichi di lavoro superiori a quelli previsti dai requisiti o è portata in condizioni operative eccezionali – in genere sottraendogli risorse di memoria e di calcolo per controllare la capacità di “recovery” (recupero) del sistema dopo un fallimento) in modo da garantire un prefissato livello di qualità del prodotto.

Strategia generale di test

La metodologia di progettazione dei test utilizzata per il progetto SGRPES si riassume brevemente nei seguenti punti:

1. Analisi dei documenti delle specifiche funzionali e dei requisiti e dei documenti di progetto; 2. Individuazione delle criticità per ogni funzionalità prevista;

3. Definizione dei test case tesi alla valutazione delle singole funzionalità dell’applicazione. Per ogni test case, in base alle specifiche di progetto, occorre identificare le pre-condizioni che devono essere soddisfatte prima dell’esecuzione del test, l’insieme di azioni (actions) da intraprendere per effettuare il test e il comportamento atteso dall’applicazione in seguito a tali azioni (expected outcome);

4. Aggregazione di più test case in modo da formare un test plan specifico per ciascuna funzionalità completa;

5. Avvio della fase iterativa di testing e tracciamento dei test effettuati (test run): occorre tracciare l’identificativo del test case in esame, e il risultato (positivo o negativo) corredato da alcune informazioni aggiuntive (data, versione del prodotto);

6. Implementazione di procedure semiautomatiche, quando è possibile, per la ripetibilità dei test e la validazione di casi limite;

7. In caso di riscontro di una anomalia (un discostamento fra il comportamento desiderato per l’applicazione e quello effettivo, cioè quello previsto dalle specifiche) occorre inviare una segnalazione (in breve bug), corredata da tutte le informazioni, ricavabili dal test case e utili allo sviluppatore per ripetere l’anomalia (pre-condizioni, azioni, expected outcome, browser utilizzato, versione del software), insieme alla descrizione del comportamento errato (actual outcome). Il bug viene inoltrato, per e-mail, sia allo sviluppatore che ha implementato la funzionalità per la correzione, sia agli analisti che ne hanno redatto i documenti di analisi per una loro supervisione. Il raffronto con gli analisti infatti è una assicurazione contro una non corretta interpretazione delle specifiche da parte dei tester o degli sviluppatori;

8. I test, in presenza di eventuali variazioni delle specifiche, vanno rivisti sin dalla definizione dei test case e vanno ripetuti una volta corretta l’anomalia e in generale ad ogni nuovo rilascio parziale o definitivo, in modo da verificare la correzione di errori già segnalati o l’introduzione di nuovi errori (test di regressione);

9. Individuazione degli stakeholder (sedi territoriali Istat, comuni, provincie, rete di rilevazione ecc.) per effettuare il beta testing59: una volta che i moduli che compongono l’applicazione sono stabilizzati, il “cliente”, cioè un campione degli utenti finali comincia a prendere visione del prodotto. In questa fase infatti può dare dei suggerimenti utili per migliorare ulteriormente la qualità dell’applicazione in termini di usabilità;

10. Rilascio della documentazione relativa ai risultati delle campagne di test.

59 Una terminologia molto diffusa divide i controlli finali in alfa-test e beta-test. I due termini distinguono i controlli rispetto al soggetto che li esegue. Il primo stadio di testing (alfa) sarà svolto dal gruppo di testing con il supporto dei coordinatori dei progetti di sviluppo. Seguirà il beta testing in cui verranno coinvolti attivamente i rappresentanti degli stakeholder.

Chi si occupa dei test oltre alle verifiche nell’ambito degli scenari previsti dall’analisi, deve saper prevedere il comportamento di utenti maliziosi, che possono sfruttare eventuali punti deboli della sicurezza per fini non corretti, e il comportamento di utenti distratti, che possono compiere azioni completamente avulse dagli scenari previsti in fase di analisi, che magari non hanno senso dal punto di vista logico, ma che l’applicazione permette (e se l’applicazione permette una determinata azione, prima o poi qualcuno la compie) con delle conseguenze che possono manifestarsi quando il software è in pieno regime d’uso, danneggiando l’utente e squalificando l’immagine del fornitore (difetti quiescienti).

Bisogna tener presente infine che il test può indicare la presenza di errori, ma non ne può garantire l'assenza, il software error-free non esiste o non è certificabile.

La Base Strumenti a supporto dei test:

Bugzilla è un programma di gestione dei ticket. L’esperienza mostra come questo programma, in unione ad un suo add-on Testopia, sia di fondamentale importanza, in quanto soddisfa molto validamente parecchie esigenze:

 la definizione dei test plan e dei test case (pre-condizioni, actions ed expected outcome);

 il tracciamento dei test run e la redazione assistita delle segnalazioni in caso di anomalie: il ticket che descrive l’anomalia infatti è pre-compilato a partire dal relativo test case;

 la gestione in modo agile e puntuale delle comunicazioni fra tester, analisti e sviluppatori: Bugzilla permette infatti, tramite una interfaccia di amministrazione, di mappare ogni singola funzionalità dell’applicazione da testare con lo sviluppatore che l’ha implementata e l’analista che ne ha redatto le specifiche, in modo tale che in modo automatico ogni singola segnalazione venga inoltrata, tramite e-mail, solo alle persone direttamente interessate. Ad ogni segnalazione inoltre viene associato un livello di priorità (critica, normale, minore, suggerimento, ecc.). tutti i soggetti interessati infine possono aggiungere le loro osservazioni e i loro commenti;

 la possibilità di far tesoro delle esperienze di ogni operatore: una volta che il bug è risolto lo sviluppatore può aggiungere un suo commento con la descrizione della soluzione adottata. Queste informazioni possono essere utili ad altri soggetti che prendono parte al progetto o ad altri progetti simili;

 la gestione condivisa online del workflow del bug.

Bugzilla offre inoltre ai tester un’ interfaccia di amministrazione molto flessibile, per gestire, fra l’altro, utenze e relativi permessi, configurare il workflow dei bug, configurare alcuni servizi di ricerca, ecc.

Selenium è un add-on del browser Firefox. Quando si lavora con il browser, Selenium offre la possibilità di registrare delle macro, cioè di registrare una sequenza di azioni che da tastiera o da mouse si fanno lavorando con il browser sull’applicazione. La macro può in seguito esser riavviata in modo da rieseguire in automatico tutta la sequenza di azioni.

Le macro inoltre sono modificabili e configurabili anche attraverso il codice script ad esse associato, permettendo di ripetere un determinato test con l’introduzione di alcune varianti (per es. con diversi profili utente, o lavorando su questionari di province diverse).

Le macro di Selenium quindi, con un intervento minimo dell’operatore umano, si prestano bene a ripetere periodicamente alcuni tipi di test run, consentendo un notevole risparmio di tempo e risultando particolarmente utili per i test di regressione. Infine sono cross-browser, cioè possono essere utilizzate con i vari browser (Firefox, Internet explore, Chrome, ecc) nelle varie versioni. Tamper data è un add-on del browser Firefox. Esso è utile nei test di sicurezza in quanto mette in evidenza eventuali punti deboli nelle comunicazioni fra il client (il browser) e il server

(l’applicazione), consentendo ai tester di simulare attacchi da parte di utenti maliziosi. Tamper data permette inoltre di verificare se informazioni che dovrebbero essere criptate sono invece inviate al server in chiaro.

IETester , Windows virtual PC e Oracle virtual box. Il cross-browser.

Quando si sviluppa un’applicazione web accessibile tramite un browser, un problema che non va sottovalutato è quello del cosiddetto cross-browser: il comportamento dell’applicazione deve essere lo stesso al variare del browser che si utilizza fra quelli di uso comune (Firefox, Internet explorer, Chrome, nel caso del Censimento).

Il cross-browser è quindi un problema che va affrontato in modo sistematico anche dal gruppo di testing.

Fra gli strumenti utili si segnalano IETester, un programma che simula il comportamento di varie versioni del browser Internet explorer (dalla IE10 preview, IE9, IE8, IE7 IE6 e IE5.5) e soprattutto Windows virtual PC ed Oracle virtual box, che simulano rispettivamente gli ambienti Windows XP e Ubuntu, su cui installare una determinata versione del browser.

5.8 Utilizzo del sistema

La rete di rilevazione era formata da 1.667 operatori, come ci si attendeva, il numero maggiore di operatori è da identificarsi tra i Rilevatori, che hanno rappresentato il 73 per cento del totale, mentre gli UCC salvo pochi casi sono rimasti con un solo responsabile per comune. La tabella sottostante mostra in dettaglio il numero di operatori suddivisi per ruoli.