Seminario CNIPA 2 giornata La misura della Qualità del software. Roma - 10 aprile Giovanni Pistarini (giovanni.pistarini@it.compuware.

Transcript

1 Il collaudo del software Metodologie e principi del testing, funzionale e prestazionale esempi e regole da seguire per impostare un collaudo Seminario CNIPA 2 giornata La misura della Qualità del software Roma, 10 aprile 2006 (giovanni.pistarini@it.compuware.com) 1 Argomenti di oggi Come richiedere ed ottenere la qualità pattuita e non sostenere costi aggiuntivi Le richieste formali L organizzazione interna Processi e strumenti da utilizzare Come minimizzare i rischi nel caso di qualità non sufficiente Organizzazione del pre collaudo e collaudo Gestire il rischio e le risorse Metriche 2

2 Le multidimensioni della Qualità conformità con i requisiti funzionali e prestazionali espiciti, con standard di sviluppo documenti e con le caratteristiche implicite che è lecito attendersi (R.S.Pressman, Ingegneria del software, McGraw Hill, libri Italia 200) conseguenza dell efficacia e della efficienza dei processi che li hanno generati e li supportano (UNI ISO ) assenza di difetti che potrebbero bloccare l uso sel prodotto o condurlo a fornire risultati e/o prestazioni inaccettabili (C.Jones, Applied software measurement, 2 ed. McGraw Hill, 1996) soddisfazione dell utente ed aderenza ai requisiti (W.E.Perry, Quality Assurance for information Systems, QED Publishing Company, 1991) 3 Le multidimensioni della Qualità requisiti funzionali e prestazionali standard di sviluppo documenti Strategia di Acquisizione Gestione del contratto dei processi assenza di difetti prestazioni inaccettabili Processo di QA Piano di Qualità Controlli di Qualità Prodotti / Servizi Collaudo Metriche Slide di transizione Livelli di Servizio soddisfazione dell utente soddisfazione dell utente aderenza Certificazione ai requisiti di Qualità 4

3 Le multidimensioni della Qualità dei processi requisiti funzionali e prestazionali assenza di difetti prestazioni inaccettabili aderenza ai requisiti Strategia di Acquisizione Gestione del contratto Processo di QA Piano di Qualità Controlli di Qualità Prodotti / Servizi Collaudo standard di sviluppo documenti Metriche Livelli di Servizio soddisfazione dell utente Certificazione di Qualità 5 Perchè preoccuparsi (della qualità) Robert Cringely (giornalista scientifico): se l automobile avesse seguito lo stesso sviluppo del computer, una Rolls-Royce Royce costerebbe oggi giorno 100 $, farebbe un milione di kilometri con 5 litri ed esploderebbe una volta all annoanno causando la morte di tutti i passeggeri 6

4 Perchè preoccuparsi (della qualità) non solo un discorso di eccellenza Maggiore complessità delle applicazioni e sistemi con esposizione diretta verso gli utenti finali 70% dei progetti implementati fuori tempo e budget previsto (source: Newport group study) 60-70% dei progetti falliti sono per carenza nella gestione e dei requisiti (source: META Group) Rischi e costi derivati dalla non qualità sempre più insostenibili Cost of Inadequate Testing (billions) Feasible Cost Reduction (billions) Software developers $21.2 $10.6 Software users $38.3 $11.7 Total $59.5 $22.2 Source: National Institute of Standards and Technology The Economic Impacts of Inadequate Infrastructure for Software Testing May Assicurare minor costo della Qualità per avere la Qualità richiesta Cost of NonConformance I costi delle non conformità rappresentano gli effetti negativi di malfunzionamenti e incorretti sviluppi Includono: Sviluppo di servizi/ funzioni non adeguate alle richieste dell utente le attività di correzione dei difetti e retesting; eccessivo consumo di risorse; distribuzione del fix, gestione del disservizio e dell utente; oltre ai danni all immagine, la perdita di produttività, INVESTIMENTO QUALITA Investment in Conformance I costi per la conformità rappresentano gli investimenti per ridurre i costi legati alle non Conformità. COSTI NON QUALITA Includono: attività di assicurazione e controllo qualità (test, verifiche, validazioni, revisioni, ispezioni,collaudi ) analisi e gestione delle non conformità; tutti i processi atti a garantire e controllare gli standard di qualità prefissati (processi, procedure,...) 8

5 I costi della Qualità Prevention Appraisal Cost of preventing customer dissatisfaction, including errors or weaknesses in software, design, documentation, and support. Internal Failure Cost of dealing with errors discovered during development and testing. Note that the company loses money as a user (who can t make the product work) and as a developer (who has to investigate, and possibly fix and retest it). Cost of inspection (testing, reviews, etc.). External Failure Cost of dealing with errors that affect your customers, after the product is released. Source: Cem Kaner & James Black Black Box Testing 9 Alcuni esempi dei costi della qualità Prevention Staff training Requirements analysis & early prototyping Fault-tolerant design Defensive programming Usability analysis Clear specification Accurate internal documentation Pre-purchase evaluation of the reliability of development tools Internal Failure Bug fixes Regression testing Wasted in-house user time Wasted tester time Wasted writer time Wasted marketer time Wasted advertisements Direct cost of late shipment Opportunity cost of late shipment Source: Cem Kaner & James Black Black Box Testing Appraisal Design review Code inspection Glass box testing Black box testing Training testers Beta testing Usability testing Pre-release out-of-box testing by customer service staff External Failure Lost sales and lost customer goodwill Technical support calls Writing answer books (for Support) Investigating complaints Supporting multiple versions in the field Refunds, recalls, warranty, legal costs Interim bug fix releases Shipping updated product PR to soften bad reviews Discounts to resellers 10

6 I costi per il cliente e i costi per fornitore These illustrate costs absorbed by the seller that releases a defective product. Lost sales and lost customer goodwill Technical support calls Writing answer books (for Support) Investigating complaints Refunds, recalls, warranty, legal costs Government investigations Supporting multiple versions in the field Interim bug fix releases Shipping updated product PR to soften bad reviews Discounts to resellers Seller: external costs Customer: failure costs (seller s externalized costs) These illustrate costs absorbed by the customer who buys a defective product. Wasted time Lost data Lost business Embarrassment Frustrated employees quit Failure during one-time-only tasks, e.g. demos to prospective customers Cost of replacing product Reconfiguring the system Cost of recovery software Tech support fees Injury / death Source: Cem Kaner & James Black Black Box Testing 11 Cost of Costi indotti dalle NonConformance non conformità e I costi delle non conformità difetti rilevati rappresentano gli effetti negativi di malfunzionamenti e incorretti sviluppi Includono: Sviluppo di servizi/ funzioni non adeguate alle richieste dell utente le attività di correzione dei difetti e retesting; eccessivo consumo di risorse; distribuzione del fix, gestione del disservizio e dell utente; oltre ai danni all immagine, la perdita di produttività, Costi Assicurare minor costo della Qualità per avere la Qualità richiesta INVESTIMENTO QUALITA *QUALITYPOINT : denominazione della metodologia di test Compuware Investment in Conformance Quality Point* Quality Point* Risk $$$ Investimenti I costiin per qualità, la conformità processi e controlli rappresentano gli investimenti per ridurre i costi legati alle non Conformità. COSTI NON QUALITA Investimento nella qualità Includono: attività di assicurazione e controllo qualità (test, verifiche, validazioni, revisioni, ispezioni,collaudi ) analisi e gestione delle non conformità; tutti i processi atti a garantire e controllare gli standard di qualità prefissati (processi, procedure,...) Fonte ISO

7 Perchè preoccuparsi (della qualità) situazioni nella realtà Rapporto amministrazione fornitore troppo spesso sbilanciato sul minor costo La qualità non viene richiesta con i doverosi dettagli Nuove forniture basate su nuove tecnologie che richiedono un costante investimento in aggiornamento e formazione, nuovi costi per i fornitori Di contro una situazione generale difficile di mercato Necessità di mantenere le proprie posizioni nel mercato Necessità di abbassare i costi mantenendo i profitti Minori investimenti sul personale Esperienza e preparazione professionale da costruire Perché la qualità è il prodotto di un processo che deve iniziare subito ma i cui risultati sono visibili solo molto più avanti 13 La qualità dovuta, ma non è scontata Avere la qualità richiesta significa avere quel 46% (35%-50%) dal fornitore, per garantire non la qualità eccelsa, ma: Il software corretto per soddisfare le proprie necessità Il valore corretto per quanto corrisposto Questa parte della fornitura deve esserci L amministrazione deve far capire fin da subito che 100 è richiesto e 100 è corrisposto (costo di sviluppo) Altrimenti il ribasso sui costi interni porterà il fornitore a limitare quella parte di investimento meno visibili all amministrazione nell immediato : la qualità. E infatti difficile valutare la qualità nel breve tempo, e quanto ci si accorge della sua mancanza è troppo tardi per tutti tornare indietro. L amministrazione rischia di ottenere, del 100% corrisposto, solo il 60%, con l aggravante di sostenere i costi successivi della non qualità. 14

8 Ridurre i costi della qualità significa intervenire all origine Avere la qualità richiesta significa avere quel 46% (35%-50%) dal fornitore, per garantire non la qualità eccelsa, ma: Il software corretto per soddisfare le proprie necessità Il valore corretto per quanto corrisposto Questa parte della fornitura deve esserci attraverso un adeguato processo di assicurazione della Qualità e i relativi controlli di Qualità Qualità richiesta Controlli di Qualità verifica validazione riesame accettazione (UNI CEI ISO/IEC 12207) Revisioni Ispezioni Requisiti Revisioni Disegno Revisioni Assicurazione della Qualità test precollaudo Sviluppo e test funzionale qualità prestaizonale Collaudo Erogazione Manutenzione Periodo di garanzia n.c. n.c. n.c. n.c. n.c. n.c. Rilevazione Non Conformità - BIP Base informativa di Progetto (PGE Gestione) accettazione Test Collaudo accettazione Utente finale 15 I controlli di QUALITA alla base di un processo di sviluppo a più basso costo L Assicurazione della Qualità ha come obiettivo primario digarantire che i processiproduttivi producano qualità nel prodotto realizzato: la precocità della rilevazione di anomalie e non conformità è anche alla base di un processo di sviluppo a più basso costo, data l incidenza elevata che nei costi globali assumono le rilavorazioni effettuate nelle parti finali del processo produttivo o dopo la sua conclusione (manutenzione). Il costo per la scoperta delle non conformità Metriche $10 $100 $1,000 $10,000 $100,000 Requirements Gathering Design Coding Testing Production 16

9 PAQ Assicurazione della Qualità (6.1.3) Definizione Assicurazione della Qualità (PAQ) è l insieme delle attivit à sistematiche e pianificate messe in campo dal fornitore per dare evidenza e fiducia all Amministrazione che i servizi e i prodotti contrattualmente forniti siano conformi ai requisiti. Determinare il livello di Qualità minimo... Determinare il livello di qualità minimo richiesto e le modalità di assicurazione della qualità è una attività che si deve preparare già nell analisi del rischio per essere valutata rispetto ai potenziali costi (e rischi) derivati dalla non qualità raggiunta. Parte integrante della fornitura È importante considerare il PAQ, e con esso il sistema di Controllo della Qualità (ad esempio il piano di test e il sistema realizzato per effettuarlo) e gli altri sistemi connessi (ad esempio gestione della configurazione), come parte integrante della fornitura del prodotto o servizio, e non un mezzo finalizzato alla sola consegna ed accettazione della fornitura. Questa considerazione, se applicata, permette di innescare un meccanismo di assicurazione della qualità tale da permettere un progressivo e continuo miglioramento dei livelli qualitativi. 17 Come valutare un processo di Qualità? Un PAQ deve essere misurato sulla sua capacità di rilevare le non conformità il più vicino possibile alla loro origine Tanto più questa distanza è minore, tanto minori saranno i costi di intervento per ristabilire il livello qualitativo richiesto (rimuovere la n.c.) Come misurare l efficacia del Processo di Assicurazione della Qualità? Il sistema di registrazione delle non conformità ed anomalie, oltre che essere un indispensabile processo di supporto, rappresenta un elemento di ingresso per il PAQ, fondamentale per valutare l efficacia e qualità del processo di assicurazione della qualità implementato dal fornitore e permettere dunque i necessari interventi per migliorarlo nel rispetto degli obiettivi e dei costi del progetto. (Descrizione delle attività e dei prodotti Cap 5) Metriche come la Defect Removal Effectiveness (Efficacia di rimozione delle Requisiti Disegno Sviluppo e test Collaudo Erogazione Manutenzione Utente finale non conformità). Essa misura la percentuale di non conformità rilevate e rimosse prima del rilascio della fornitura, Periodo o ad di garanzia una certa fase di sviluppo del n.c. n.c. n.c. n.c. n.c. n.c. n.c. n.c. n.c. n.c. Garanzia progetto, sul totale delle non conformità presenti sulla fornitura. (Misurare l efficacia Rilevazione della Non Conformità qualità Cap - BIP 5.2.2) Base informativa di Progetto (PGE Gestione) 18

10 Gli effetti nella non qualità Come riuscire a valutare che siano state effettivamente impegnate risorse per inserire Qualità nel processo e nel prodotto (46%) Concetto di costo della qualità È il costo da sostenere per rimuovere le non conformità inserite nelle varie fasi del progetto (analisi, disegno, codifica,...) Questo costo è tanto più alto quanto più tardi sono rilevate le non conformita Questo costo è tanto più basso quanto più minima è la distanza tra l iniezione del difetto e la sua scoperta Per questo motivo è necessario che il processo di assicurazione di qualità e le attività di validazione e verifica siano presenti fin dalle prime fasi e per tutto il progetto (revisioni, ispezioni, test,..) Inoltre la misurare l efficacia delle attività di validazione e verifica può essere fatta solo sul lungo termine, quanto si conosce la reale quantità delle non conformità presenti Per questo motivo è pericoloso misurare la qualità effettiva solo quando si arriva al collaudo 19 I costi pericolosi della (non) Qualità importanza del PAQ nello sviluppo SW Il Costo della Qualità può essere considerato come il costo per rimuovere le NON conformità presenti CeBase Software Defect Reduction Top-10 List, Basili, Victor and Boehm, Barry, Presentation, January 10, 2001, page 5 (adapted) ,000 10, ,000 Requirements Gathering Design Coding Testing Production 20

11 Ridurre i costi della qualità significa intervenire all origine Conformità presenti per fase di progetto Esempio di calcolo del costo per 100 bug Situazione ideale Tutte le non conformità sono rilevate e rimosse non appena introdotte (all interno della stessa fase di progetto) Costo 25 n.c 40 n.c. 30 n.c. 3 n.c. 2 n.c. minimo Requirements Design Coding Testing Production Gathering della Qualità 25 x x x x x = ,000 10, ,000 Requirements Gathering Design Coding Testing Production Esempio del costo della non qualità 21 Ridurre i costi della qualità significa intervenire all origine Situazione peggiore le non conformità sono rilevate e rimosse solo in fasi successive per mancanza di controlli di qualità all interno delle stesse fasi di progetto 20 n.c 10 n.c. Costo 5 n.c. massimo 25 n.c 40 n.c. 30 n.c. 3 n.c. 2 n.c. della Requirements Design Coding Testing Production Qualità Gathering = ,000 10, ,000 Requirements Gathering 35 n.c. 30 n.c. Design Coding Testing Production Esempio di calcolo del costo Esempio del costo della non qualità 22

12 Ripartizione reale dei costi della non QUALITA Esempio di calcolo del costo 35 n.c. 30 n.c. 20 n.c 10 n.c. Costo 5 n.c. massimo 25 n.c 40 n.c. 30 n.c. 3 n.c. 2 n.c. della Requirements Design Coding Testing Production Qualità Gathering = Costi interni nelprocesso di sviluppo per il fornitore Area dicompromesso (troppo tardiper rifare, si deve comunque andare in produzione) Costi aggiuntiviper l amministrazione Manutenzione Correttiva & Evolutiva 23 Argomenti di oggi Come richiedere ed ottenere la qualità pattuita e non sostenere costi aggiuntivi Le richieste formali L organizzazione interna Processi e strumenti da utilizzare Come minimizzare i rischi nel caso di qualità non sufficiente Organizzazione del pre collaudo e collaudo Gestire il rischio e le risorse Metriche 24

13 Ridurre i costi della qualità significa intervenire all origine Ottenere la qualità al momento giusto 25 n.c 40 n.c. 30 n.c. 3 n.c. 2 n.c. Requirements Gathering Design Coding Testing Production Qualità richiesta Controlli di Qualità verifica validazione riesame accettazione (UNI CEI ISO/IEC 12207) Revisioni Ispezioni Requisiti Revisioni Disegno Revisioni Assicurazione della Qualità test precollaudo Sviluppo e test funzionale qualità prestaizonale Collaudo Erogazione Manutenzione Periodo di garanzia n.c. n.c. n.c. n.c. n.c. n.c. Rilevazione Non Conformità - BIP Base informativa di Progetto (PGE Gestione) accettazione Test Collaudo accettazione Utente finale 25 Metriche come la Defect Removal Effectiveness (Efficacia di rimozione delle non conformità). permettono la misura della percentuale di non conformità rilevate e rimosse prima del rilascio della fornitura, o ad una certa fase di sviluppo del progetto, sul totale delle non conformità presenti sulla fornitura. Assicurazione della Qualità (PAQ ) Linee Guida CNIPA per la qualità nelle forniture ICT Gennaio 2005 Ma è difficile valutare le attività di V&V prima del test CeBase Software Defect Reduction Top-10 List, Basili, Victor and Boehm, Barry, Presentation, January 10, 2001, page 5 (adapted). Planning Report 02-3: The Economic Impacts of Inadequate Infrastructure for Software Testing, prepared by RTI for the National Institute of Standards & Technology, May 2002, page 6-10 (adapted). 26

14 Non impossibile controllare le attività per il test Test e collaudo (o collaudo?) Il test è la parte più costosa nelle attività di controllo qualità Ma è anche la parte visibile delle Verifiche e Validazioni costruite dal fornitore per assicurare la qualità E l ultima occasione per intervenire a costi accettabili per ridurre i rischi La Svolta: il test come parte integrante della fornitura Diventa argomento di valutazione, anche economica Si assicura la sua corretta preparazione (fin dalle prime fasi) e qualità (copertura, efficacia e riusabilità) Si quantifica, si qualifica, si dettagliano le modalità di documentazione ed esecuzione Si richiede di un asset utilizzabile a seguito di successive manutenzioni, si richiede il codice di test Si inseriscono strumenti e tecnologie di mercato a supporto, per garantire il rispetto di un certo processo Si assicura che il test, almeno il test, venga effettuato con il giusto rigore Si predispone ad un collaudo affidabile e rapido Applicazione o servizio più documentato Attenzione È una parte attiva del sistema, va mantenuta 27 Scopo del TESTING oltre la qualità il controllo e la mitigazione del rischio Il TESTING deve essere in grado di offrire La riduzione massima del rischio La garanzia (oggettiva) del rispetto dei requisiti richiesti (funzionalità e prestazioni). TEST La riduzione del rischio della messa in esercizio di applicazioni non correttamente funzionanti (core business, middleware, patch, ecc.). Un sistema organizzato e riutilizzabile che costituisce patrimonio per l amministrazione al pari dell applicazione. La portabilità del processo sia per lo sviluppo interno sia per quello esterno (fornitori). Un processo di miglioramento continuo della Qualità (accrescimento, miglioramento e automazione dei piani di test in vista del futuro riutilizzo). Metriche 28

15 Evitare che il TEST diventa COLLAUDO La qualità del sw non è immediatamente misurabile e quando è possibile farlo è troppo tardi E necessario riuscire a far sviluppare quel 46% al fornitore per le attività di verifica e validazione, incluse le attività di test. Per raggiungere questo obiettivo serve Attenzione massima al processo di assicurazione di qualità Specificare fin da subito con chiarezza le modalità richieste per il test, in termini di standard, strumenti, quantità, contenuti e modalità di progettazione ed esecuzione Gestire i test sulla base di requisiti e livello di rischio rappresentato Dare valenza economica in fase di aggiudicazione della gara Richiedere e approvare i documenti di test prima dello sviluppo e il codice di test al suo termine Implementare un processo di tracciatura dei difetti, dalle prime revisioni al collaudo e successivo periodo di garanzia, da implementare immediatamente Utilizzo metriche, ecc Creare al proprio interno una struttura competente con ruoli e poteri per seguire il progetto software in tutti i controlli di qualità richiesti. 29 Le mosse possibili delle amministrazioni Seguire le attività di V&V dal capitolato al collaudo Quantificare i test Definire gli standard per la progettazione dei test Definire i contenuti dei test, livello di dettaglio Definire le modalità di esecuzione (manuale/ automatica) Introdurre strumenti di test management e test automation Introdurre vincoli sull accettazione della documentazione di test Determinare precisi criteri di ingresso / uscita per la fase di collaudo Documentazione di test approvata Script di test dettagliati e riutilizzabili Ambiente di collaudo allestito Superamento di una prima fase di test a campione (smoke test) 30

16 Quantificare e qualificare il test Quanti test? Legare i test alle dimensioni del software Esempio 1,2 casi di test per FUNCTION POINT più 1 caso di test per ogni messaggio verso l utente Quali test Copertura funzionale, identificare e pesare la mappa delle funzioni da testare (REQUISITI FUNZIONALI DI TEST), dalla macro funzione e requisito di business fino alla funzione elementare. Copertura delle condizioni di test, identificare e pesare i singoli requisiti di test per le diverse condizioni di test da implementare per ogni singola funzione Attenzione Definire univocamente la dimensione e confine del caso di test Definire formati e contenuti minimi e comuni da utilizzare Definire ruoli all interno dell amministrazione e i tempi di consegna 31 Le mosse possibili delle amministrazioni (recenti capitolati) Quantificare i test [ ] Un test di funzione o di applicazione si compone di una sequenza di test elementari (casi di test, ad ognuno dei quali tipicamente corrisponde una segnalazione di ok, di warning o di errore), che si possono distinguerein: casi di test informatici (es. controllo di validità di un valorein un campo); casi di test applicativi (es. controllo di quadratura dopo un elaborazione di altri dati in input o presenti sulla base dati). I test di funzionedevono essere prodotti in modo da assicurarela seguente copertura: almeno 1 test per ogni funzione e almeno 0,5 casi di test per Punto Funzione; almeno 1 caso di test per ogni segnalazione intrafunzionale (di ok, di warning o di errore). 32

17 Le mosse possibili delle amministrazioni (recenti capitolati) i test come parte integrante della fornitura [ ] il codice di test (casi di test, script, set up dati di prova ecc.) relativo agli Obiettivi realizzativi, dovrà essere consegnato come parte integrante della fornitura, per essere catalogato e riusato nell ambito delle attività di manutenzione e di certificazione. Nel caso di manutenzione su applicazioni per le quali sia stato già prodotto il codice di test e collaudo, questo dovrà essereriutilizzato, aggiornato e riconsegnato a fronte dell intervento di manutenzione effettuato. Il codice di test e collaudo deve essere realizzato in forma autoconsistente. Il test perciò sarà composto di una prima parte di cleaning o set up della porzione di base dati che sarà utilizzata e di una seconda parte composta dall insieme dei casi di test di cui il test si compone. La parte set up potrà essererealizzata in forma autonoma e comuneper essere usata da più di un test. [ ] Richiedere test riutilizzabili implica cura nella loro preparazione e soprattutto implica che si tratta di test realmente utilizzati. Aumenta la confidenza che i test forniti siano test il cui utilizzo nel collaudo può essere limitato ad un campione. L amministrazione potrà selezionare i test per il collaudi e costruire un processo di certificazione Si introduce il concetto di codice di test, sia esso manuale o automatico (script di test). 33 Le mosse possibili delle amministrazioni (recenti capitolati) Attenzione al processo [ ]... per l attività di test funzionale : Va assicurato che i casi e le procedure di test siano completi e accurati. I risultati di queste attività vanno registrati e vanno aggiornati i casi di test e le procedure, se necessario. Vanno registrati e analizzati i risultati del test e le anomalie eventualmente riscontrate.... per l attività di Assicurazione della Qualità : Vanno effettuate, in modo continuativo, verifiche sulle attività di sviluppo software e sui prodotti risultanti da queste, al fine di: 1. assicurare che ogni attività sia stata eseguita in conformità con il contratto e con le procedure previste nel Piano della qualità 2. assicurare che ogni prodotto software sia stato sottoposto a verifiche, test e azioni correttive necessarie I piani e gli script di test realizzati sono considerati parte integrante del software fornito e devono essere rilasciati all Amministrazione per futuri collaudi di non regressione. 34

18 Le mosse possibili delle amministrazioni (recenti capitolati) Attenzione ai contenuti, alla copertura e alla modalità di verifica [ ] Test Funzionali e di integrazione : Vanno predisposti opportuni casi di test (in termini di output, risultati attesi e criteri di valutazione), procedure e dati per l effettuazione di test funzionali e di integrazione. I casi di test devono coprire tutti gli aspetti funzionali e qualitativi considerati nella progettazione del software. [ ] L analisi dell esito del test viene intesa come verifica, mediante strumenti automatici, dei dati elaborati sia a livello interfaccia sia a livello di dati presenti nel database dell applicazione (comparazione). Introduzione di strumenti per il test [ ] Strumenti per il test e il controllo di qualità : Il test del software dovrà essere effettuato impiegando strumenti specifici. Per quanto sopra, oltre alla realizzazione dei sistemi richiesti, la fornitura dovrà comprendere specifici prodotti software di mercato atti a consentire l automazione dei processi di test e la documentazione dei risultati, oltre che la verifica della qualità dei prodotti, della correttezza dei dati ed il test delle performance del sistema in condizioni di carico simulate. 35 Le mosse possibili delle amministrazioni (recenti capitolati) Non dare discrezionalità a priori [ ] Il criterio di determinazione dei casi di prova deve prevedere : descrizione dell'esito test, intesa come verifica oggettiva dei dati attesi, sia a livello interfaccia grafica, sia a livello dei dati presenti nel data-base dell'applicazione ; più casidi prova per ogni funzione ritenuta critica, secondo i criteri concordati tra il Fornitore e l'amministrazione ; per ogni funzione, per cui possano essere significativi, i casi che simulino operazioni errate da parte dell'utente ; per ogni funzione, per cui possano essere significativi, i casi di prova che simulino tentativi di accessi illegali da parte dell'utente ; le funzioni del sistema sottoposte al collaudo, con evidenziazione di quelle che, eventualmente, sostituiscono funzioni già esistenti nelsistema informatico attualmente in uso; Introdurre un criterio di rischio, ma definire le regole in anticipo il metodo adottato per valutare la criticità delle funzioni del sistema(es. funzioni di uso frequente, funzioni il cui ipotetico malfunzionamento potrebbe causare un grave danno pecuniario o d'immagine, ecc.); 36

19 La documentazione del TEST Piano di test Esplicita le strategie di test indicate nel piano di qualità Specifico per il tipo di test (es. funzionale) Obiettivi, standard, modalità, criteri, tecniche, strumenti Definizione dei cicli di test Definizione check list di test Requisiti funzioni di test scomposizione funzionale del progetto in requisiti funzionali di test (fino alla funzione elementare) visione completa dell applicazione e matrice con i requisiti di business punto di partenza per sviluppare i casi di test applicare fattori di rischio (complessita, impatto, maturità,..) Requisiti di test (casi di test) Ad ogni funzione elementare viene applicata la tecnica di test prescelta (es. BlackBox) Sono identificati i requisiti di test (casi di test) applicare fattori di rischio (complessita, impatto, maturità,..) Piano di Qualità Script di test (codice di test) Viene sviluppato ogni requisito di test secondo standard e tecniche previste dettaglio azioni / data input e output (risultato atteso) script manuale (inzialmente) / automatico piano di qualità Macro funzione Requisito Funzionale di test specifiche di test Funzione elementare Requisito Funzionale di test piano di test Caso di test Requisito di test Script di test Azioni / in / out 37 Il piano di test E un documento che finalizza quanto definito come linea strategica del test nel Piano della Qualità o di procedura generale del test Indica gli obiettivi e i risultati da produrre (deliverable) Tipicamente un piano per ogni tipo di test (test funzionale, integrazione, prestazionale, ecc) Contiene informazioni : Ruoli e responsabilità Definizione dei cicli di test e per ogni ciclo i criteri di ingresso e di uscita del test ( cosa serve per iniziare, e quanto posso fermarmi) Oggetti del test (ese. Requisiti funzionali di test ) Misure e metriche da rilevare Ambiente e risorse per il test (esempio strumenti) Naming convention, standard riferimento, processi associati (come QA, gestione difetti e gestione configurazione), 38

20 I requisiti funzionali di test scomposizione del progetto Matrice con i requisiti di Business Requisiti Funzionali di test Mappa delle funzioni da testare Funzionalita e matrice Piano di test criteri di ingresso e uscita Modalita Individuare le funzionalità da sottoporre a test Per ciascuna funzionalità valutare se funzionalità elementare, altrimenti decomporre Macro Funzionalità Gestione Anagrafica Gestione Contabile Gestione Documenti Gestione Personale Funzionalità principali Profilo Cittadino Profilo Aziende Gestione Spese Gestione Contributi Gestione Speciale Funzionalità elementare Aggiunta dati Cancellazione dati Modifica dati Visualizzazione dati Comunicazione Interazione Interrogazione Ricerca Produzione output Controllo stato Esempio standard COMPUWARE : Tabella requisiti funzionali di test Esempio standard CONSIP : Tabella di scomposizione funzionale del progetto 39 Determinare la tempistica per il test PIANO DI QUALITA Il test deve sviluppato secondo un ciclo parallelo allo sviluppo software Il piano di test dovrà essere pronto prima ancora dell inizio della fase di codifica e sottoposto a verifica e approvazione Si utilizzano diverse risorse specializzate che collaborano Le Specifiche di test (casi e script di test) dovranno essere consegnate prima della consegna del codice, e sottoposte a verifica e approvazione Le modalità e i tempi sono indicati nel piano di qualità. 40