Il Collaudo del software

Transcript

1 Il Collaudo del software Principi e metodologie di lavoro Autore: G. Ceseri

2 Contenuti Fondamenti di qualità del software Principi del TQM Il modello del SEI La normativa ISO Attributi del software Prerequisiti dell attività di collaudo Tecniche di collaudo Fasi dell attività di collaudo Collaudo di regressione Strumenti per il collaudo del software Documentazione di collaudo e relativi standard Automazione delle attività di collaudo Manutenzione e SCM Raccolta e gestione di dati metrici sulla qualità del software Preventivazione, pianificazione, organizzazione e gestione delle attività di collaudo e manutenzione

3 Fondamenti di qualità del software I difetti non si ottengono gratis. Qualcuno li ha prodotti, ed è stato pagato per farli. W.E. Deming

4 Principi del Total Quality Management PROMETEO

5 L obiettivo fondamentale é la Customer Satisfaction. Essa è il fattore di traino, il giudice ultimo della qualità. Per questo motivo l imperativo fondamentale è: conoscere il proprio cliente.

6 La relazione cliente-fornitore va globalizzata, estesa ai rapporti interaziendali. Ad esempio la produzione deve essere vista dalla progettazione come un cliente. Questo atteggiamento orientato al cliente, evita che i vari settori aziendali scarichino i problemi sulla fase di lavorazione successiva.

7 La qualità riguarda tutti, non è il lavoro di un gruppo di specialisti. Per questo assumono un ruolo essenziale il coinvolgimento, la formazione e in generale la qualità del personale dell azienda. Lo specifico ruolo del management è quello di attivare e mantenere un meccanismo di quality improvement.

8 E essenziale assumere una attitudine rivolta ad agire sulle cause e non a rimediare ai sintomi. Req. Cod. Ist. Pro. Test Uso La qualità va incapsulata DENTRO i prodotti e i processi produttivi.

9 Non ha senso eseguire il controllo qualità off-process. In un certo senso è come pianificare i difetti, strutturandosi per trovarli e rimuoverli successivamente. Fra l altro, operando così, solo una parte dei difetti verrà effettivamente rimossa. La qualità deve essere ottenuta in-process : non trovare, ma prevenire i difetti (approccio zero-defect). La qualità nasce dall introduzione di un meccanismo di quality improvement continuo del processo.

10 Bisogna minimizzare il costo globale del prodotto: di acquisto e di manutenzione (ovvero il costo del ciclo di vita). Non è vero che la qualità costa (se valutata sull intero ciclo di vita). Il 25-40% dei costi delle aziende non operanti in regime di qualità, è da imputare proprio ai bassi livelli qualitativi. Tali costi scendono al 5% nelle aziende eccellenti.

11 Solo in alcuni casi la qualità deriva da innovazioni rivoluzionarie. Essa deriva più frequentemente da un processo di miglioramento continuo (Kaizen). La qualità non è un obiettivo, è un viaggio.

12 ACT PLAN TQM CHECK DO Il ciclo PDCA deve essere iterato continuamente, apportando nuove migliorie nello stadio ACT.

13 Per poter affinare continuamente il processo è essenziale instaurare un sistema di raccolta dati sul processo, da cui derivare le indicazioni su come modificarlo.

14 Classificazione del livello di maturità del processo di produzione del software Il modello SEI

15 1 Initial level 2 Repeatable level 3 Defined level 4 Managed level 5 Optimizing level

16 1 Initial level Processo sotto controllo statistico Anarchia (i programmatori si considerano artisti creativi, non soggetti a regole) In situazioni di crisi si abbandona ogni procedura e ci si butta nel sano code and testing

17 2 Repeatable level L organizzazione ha raggiunto un processo stabile (ma non formalizzato per iscritto), con un livello ripetibile di controllo statistico, attraverso un project management rigoroso dei commitments, dei costi, dello schedule e delle modifiche Prerequisiti * Esistenza di un gruppo di SW quality * SW commitments mgmt * Pianificazione SW e stima costi * Metriche su dimensioni e difetti * SCM e controllo modifiche * Procedure formali di gestione progetto * Procedure formali di SW testing TUTTO OK FINO A QUANDO NON SI SVILUPPANO NUOVI TIPI DI SISTEMI

18 3 Defined level L organizzazione ha definito il processo, per garantire realizzazioni consistenti e per fornire una base per comprendere il processo. Prerequisiti * Modello formale del processo * Standard formali e controllo del loro uso * Ispezioni * Politica formale di test e regression test * Programma di formazione specialisti * SCM più avanzato * Esiste un SW Eng. Process Group IL PROCESSO E ISTITUZIONALIZZATO

19 Solo al livello 3 (processo definito) l impiego di CASE tool può dare risultati significativi. Process People Tools

20 4 Managed Level L organizzazione ha iniziato un attività completa di raccolta dati sul processo (non solo relativi a dimensioni e difetti). Prerequisiti * Procedura formale per l adozione di nuove tecnologie * Sistema organico di metriche SW * Attività sistematica di stima e consuntivazione di dati metrici * Programma formalizzato di SW quality improvement A QUESTO PUNTO COMINCIANO GLI INCREMENTI PIU SIGNIFICATIVI DI QUALITA

21 5 Optimizing Level A questo punto l organizzazione ha una base su cui fondare miglioramenti e ottimizzazioni continui del processo. Prerequisiti * Procedura formale per identificare e rimpiazzare tecnologie obsolete * E operante un meccanismo per analizzare le cause degli errori * E operante un meccanismo per avviare azioni di prevenzione dei difetti

22 Evoluzione del processo Initial Basic mgmt control Repeatable Process definition Defined Process mgmt Managed Process control Optimizing

23 Aspetti chiave 1. Chaos 2. Project Management Produttività 3. Methods and Tools & Qualità 4. Metrics 5. Qualità

24 La situazione al % 12 % L 2 L 3 L 1 81 %

25 Quale è il risultato ottenibile? Vari studi condotti in tempi diversi Sackman-Erikson-Grant (1968) B. Boehm, COCOMO (1982) De Marco- Lister (1987) Evidenziano che esiste un rapporto di benchmarking di circa 1:10 fra la peggiore e la migliore organizzazione.

26 ISO Guida per l applicazione di ISO 9001 allo sviluppo, alla fornitura e alla manutenzione del software

27 ISO 9001 Sistema di qualità- Modello per la garanzia di qualità nel progetto/sviluppo, produzione, istallazione e servizio

28 Responsabilità del management Deve essere definita la responsabilità e autorità delle persone che eseguono e verificano attività che influenzano la qualità. Design review e audit del sistema di qualità, dei processi e/o dei prodotti devono essere svolti da personale indipendente. Deve esistere un rappresentane del management responsabile del controllo della applicazione dei requisiti ISO Deve avvenire una review periodica del sistema di qualità. L acquirente è responsabile della nomina di un rappresentante per la gestione cooperativa del rapporto contrattuale.

29 Sistema di qualità Deve essere stabilito un sistema di qualità documentato che copra tutto il ciclo di vita, tendente a prevenire i difetti e soggetto ad un affinamento continuo. Per ogni sviluppo software deve essere prodotto un Quality Plan. Deve essere eseguito un insieme organico di attività di quality audit pianificate e documentate. Devono esistere procedure documentate per le azioni correttive.

30 Attività nel ciclo di vita Aspetti generali Il contratto deve essere soggetto a procedura formale di reviewing, con particolare riguardo a criteri di accettazione, cambiamenti di requisiti, criteri per la gestione di problemi rilevati dopo l accettazione, responsabilità dell acquirente, elementi forniti dall acquirente, standard e procedure da usare. L acquirente deve fornire o comunque firmare per accettazione un documento dettagliato di specifica dei requisiti. Deve essere definito un accurato piano di sviluppo, integrato con i piani di qualità, di configuration management, di integrazione e di test. Bisogna definire con esattezza gli strumenti e le metodologie da adottare. Ogni fase di attività deve essere accompagnata da un appropriata fase di verifica.

31 Contenuti del Quality Plan Obiettivi di qualità, espressi in termini quantitativi quando possibile. Input e Output di ogni fase di attività. Identificazione dei tipi di attività di test, verifica (stiamo facendo il prodotto nel modo corretto?) e validazione (stiamo facendo il prodotto giusto?). Piano delle attività di test, verifica e validazione. Definizione delle responsabilità organizzative per le attività legate alla qualità.

32 Collaudo e validazione Il Test Plan Document deve includere: - piano di collaudo, - test case - ambiente, strumenti e software di collaudo - criteri per la valutazione dei test - definizione del personale richiesto e del relativo training. I risultati dei test debbono essere documentati e vanno valutati tutti i possibili impatti che il loro esito può avere, anche su aree di sistema diverse da quella sotto test. Il software deve essere sottoposto a validazione completa nelle condizioni operative finali dell applicazione, prima di procedere alla esecuzione del collaudo di accettazione col commitente.

33 Consegna Bisogna provvedere ad una adeguata duplicazione e archiviazione della software release consegnata. E essenziale predisporre anche un opportuno disaster recovery plan. La consegna e la installazione debbono poi essere soggette ad una accurata attività di pianificazione.

34 Manutenzione Le esigenze e quindi le modalità del servizio di manutenzione debbono essere definite in fase di stipulazione del contratto. La durata del contratto e l area delle attività di manutenzione (correttiva, adattiva e perfettiva) debbono essere definite. Deve essere definita l organizzazione di supporto, con identificazione dei rappresentanti sia lato fornitore, sia lato commitente. Devono essere predisposti: una procedura di gestione della documentazione di manutenzione e uno standard per la redazione dei documenti. Devono essere tenuti dati statistici su failure e interventi. Deve esistere una procedura definita per la emissione delle software release.

35 Configuration Management Devono esistere regole per identificare in modo univoco la versione di ogni componente e delle release complete di prodotto. Deve esistere un Configuration Management Plan che identifichi le responsabilità organizzative, gli strumenti, le metodologie e lo stadio in cui i componenti debbono essere messi sotto controllo di configurazione. Le modifiche debbono essere eseguite nel rispetto di una procedura definita e documentata. Deve essere mantenuto aggiornato un rapporto sullo stato della configurazione (stato dei componenti, richieste di modifiche, ecc.).

36 Documentazione Tutta la documentazione (sia tecnica, sia gestionale) deve essere gestita in base ad una procedura rigorosa e documentata. E necessario inoltre mantenere, in modo accurato, un archivio di documenti che attestino lo stato del sistema di qualità adottato dall organizzazione.

37 Misure E necessario eseguire un rilievo metrico su ogni prodotto, che permetta di mantenere il prodotto sotto controllo di qualità. Debbono essere mantenuti dati metrici anche sul processo di sviluppo, in modo da poterlo tenere sotto controllo e migliorarlo.

38 Acquisti I prodotti o i servizi software acquisiti dall esterno devono essere ordinati sulla base di documenti che descrivono in dettaglio l oggetto di fornitura. Devono esistere: una procedura organica per la selezione dei fornitori esterni (qualificazione della qualità) e una procedura per mantenere un archivio di dati su di essi. Il fornitore è responsabile della validazione delle attività decentrate all esterno.

39 Attributi del software Io non mi preoccupo che una cosa sia economica o costosa. Mi preoccupo che sia buona. Se sarà buona abbastanza, il pubblico pagherà per essa. W. Disney

40 Alcune definizioni Requirement funzione o proprietà richiesta al sistema Error eseguito in progetto o codifica, implica la non soddisfazione di uno o piu requirement Fault Failure evento in cui uno stimolo (input) porta a manifestare un error non rilevato precedentemente evento per cui il sistema perde la capacità di compiere la sua missione, come conseguenza di uno o più fault

41 Affidabilità Qualità dell analisi funzionale + Qualità del progetto + Qualità del codice + Qualità del collaudo + Qualità della manutenzione e del SCM = Affidabilità L AFFIDABILITA SI MANIFESTA CON UN BASSO TASSO DI FAULT

42 Manutenibilità Astrazione + Struttura + Leggibilità + Tracciabilità + Bassa complessità dei componenti + Buona documentazione + Buon SCM = Manutenibilità

43 Tracciabilità quale modulo software quale elemento della struttura dati Difetto quale sottosistema dell architettura quale funzionalità

44 Tracciabilità quale modulo software quale elemento della struttura dati nuova esigenza funzionale quale sottosistema dell architettura quale funzionalità

45 Tracciabilità E pesantemente influenzata dalla complessità delle interfacce software. Esse debbono essere: - poche - a basso throughput - assoggettabili a monitoring

46 Robustezza Capacità di assorbire input anomali + Capacità di operare in un ambiente hardware degradato + Capacità di operare in un ambiente di software di sistema degradato + Capacità di operare in un ambiente applicativo degradato + Capacità di sopportare carichi superiori a quelli nominali + Capacità di autocorrezione di situazioni anomale = Robustezza

47 Processo di gestione del software Affidabilità, manutenibilità, robustezza e tracciabilità permettono al software di beneficiare di un lungo ciclo di vita, con conseguente aumento del ritorno dell investimento. Tali attributi debbono essere mantenuti e possibilmente migliorati nel ciclo di vita, attraverso procedure corrette di manutenzione e SCM e attraverso rilievi metrici che consentano di identificare i punti deboli.

48 Regola di Pareto L 80% dei problemi deriva dal 20% dei sottosistemi.

49 Preparazione dell attività di collaudo Gestisci le cose difficili quando sono ancora facili. Risolvi i grandi problemi quando sono ancora piccoli. Prevenire grandi problemi con piccole azioni è più facile che risolverli. Attraverso piccole azioni possono essere conseguite grandi cose. Lao Tzu

50 Premesse 1) Il collaudo del software è l attività di progetto più costosa. 2) La rimozione degli errori è tanto più costosa quanto più avanti avviene nel ciclo di sviluppo. 3) La dimostrazione formale di correttezza è inattuabile allo stato dell arte. Ne segue che: a) ogni prodotto software incorpora un certo numero di errori b) il quality assurance mira a ottenere prodotti dotati del voluto livello di affidabilità.

51 Prerequisiti dell attività di collaudo 1) Documentazione di Requirement 2) Documentazione di Progetto Software 3) Piano di progetto 4) Software Quality Assurance Plan (SQAP) 5) Software Configuration Management Plan (SCMP)

52 Software Quality Assurance Plan Definisce il piano di qualità adottato per uno specifico sviluppo software.

53 Struttura del SQAP 1. Scopo 2. Documenti di riferimento 3. Management 4. Documentazione di progetto 5. Standard, norme e convenzioni 6. Review e audit 7. Configuration management 8. Reporting dei problemi e azioni correttive 9. Strumenti, tecniche e metodologie 10. Controllo del codice 11. Controllo dei media 12. Controllo dei fornitori IEEE STD / ESA PSS-05-0

54 Preparazione delle attività di collaudo (fase 1) 1. Identificazione dei requisiti Req. Doc Matrice di verifica 2. Associazione dei requisiti alle unità di software SW Design Doc. Matrice di tracciabilità 3. Definizione dei test e delle catene/sequenze di test Test case e catene di test

55 Matrice di verifica Numero di Req. Paragrafo Descrizione Metodo I A T Livell M S I Metodo Livello I = ispezione del codice A = esecuzione di calcoli (i.e., calcolo di occupazione di memoria) T = esecuzione M = modulo/sottosistema S = sistema I = installazione (hw + sw)

56 Matrice di tracciabilità Aggiunge alla matrice di verifica una colonna, per identificare le unita di software coinvolte nel conseguimento del requisito.

57 Diagramma di sequenza di test Req. 3 Req. 1 Req. 4 Req. 2 Hardware speciale

58 Catena di test E una unita di lancio che raggruppa un certo insieme di test, correlati da: 1) esigenza delle stesse condizioni di attrezzaggio iniziale, 2) appartenenza alla stessa area funzionale (opzionale).

59 Preparazione delle attività di collaudo (fase2) 4. Definizione del materiale di supporto 5. Definizione di date e durate Lista materiale Project Plan 6. Predisposizione di un piano di integrazione SQAP 7. Scrittura del STP SCMP Test case e catene di test Matrice di tracciabilità STP

60 Materiale di supporto Software di collaudo Strumenti di collaudo Simulatori

61 Tecniche di integrazione 1) Big - Bang 2) Top - Down 3) Bottom - Up 4) SW Layers

62 Ovviamente la stesura di un STP è, di norma, ottenuta mediante un processo di affinamento successivo.

63 Procedura ESA PSS-05-0 Fase Documento UR SR AD DD SQAP Initial SQAP Detailed SQAP SCMP SCMP STP STP1 List of acceptance test STP2 Design of test STP3 Implementatio n of tests

64 Tecniche di collaudo Non esistono proiettili d argento. Frederik Brooks

65 Ispezione Analisi Utile per collaudare situazioni difficilmente riproducibili (i.e., condizioni di errore di system services). Verifiche eseguite per calcolo (i.e., occupazione di memoria calcolata dai dati contenuti nelle link map). Dimostrazione e Test Esecuzione di test case. Certificazione Pura consegna di documentazione dei test eseguiti. Implicazione Verifica di requisiti attraverso la verifica di requisiti implicanti.

66 Tecniche di test Black-Box testing STIMOLO SISTEMA OUTPUT? OUTPUT ATTESO E la tecnica di test fondamentale. L unica valida per i test formali di accettazione.

67 Tecniche di test White-Box testing (Glass-Box testing) TEST 1 TEST 2 OUT OK? Di solito è usato informalmente (istintivamente) a livello di test di modulo.

68 La copertura funzionale E in sostanza la percentuale di funzionalità elementari coperte dal collaudo. E perseguita dal black-box testing.

69 La copertura topologica C 0 = N. istruzioni esercitate almeno una volta / N. totale di istruzioni eseguibili (copertura istruzioni) C 1 = copertura dei segmenti di programma C 2 = copertura del richiamo di moduli e sottoprogrammi C 3 = copertura dei cammini dall ingresso all uscita del programma. E perseguita dal white-box testing. La copertura topologica media di un prodotto immesso sul mercato con una qualificazione non sistematica è in genere del %.

70 Tipologia dei test TEST POSITIVI funziona! TEST NEGATIVI è robusto!

71 Fasi dell attività di collaudo La montagna c è e ci sarà finchè esiste la coscienza. Robert Pirsing

72 Test di modulo Test di integrazione Test funzionale Test di sistema Test di accettazione

73 Test di modulo E noto anche come unit test. La unità soggetta a test può cambiare da progetto a progetto (tipicamente è una task in sistemi a task concorrenti). E condotto prevalentemente con tecnica glassbox.

74 Test di integrazione Ha come scopo principale il collaudo delle interfacce software, oppure la verifica della corretta interazione fra hardware e software.

75 Test funzionale Ha lo scopo di validare funzionalmente il sistema. E condotto con tecnica black-box.

76 Test di sistema Il sistema funziona ma: 1) regge le varie condizioni di carico? 2) gestisce adeguatamente i picchi? 3) come reagisce alle anomalie hardware? 4) come reagisce ad un uso improprio? 5) quale è il suo MTBF?

77 Test di sistema E condotto essenzialmente con tecnica black-box e porta ad eseguire prevalentemente test negativi. L esito del test non è semplicemente affermativo o negativo, ma porta spesso al rilievo di dati quantitativi.

78 Test di accettazione E il collaudo formale condotto prima del rilascio del prodotto al committente. E eseguito secondo procedure concordate fra committente e fornitore.

79 Documentazione di collaudo Standard per STP Come questa tazza, disse Nan-in, tu sei ricolmo delle tue opinioni e congetture. Come posso spiegarti lo Zen, se prima non vuoti la tua tazza. 101 Storie Zen

80 IEEE IEEE DOD-STD-2167A MIL-STD-498 ESA PSS-05-0 ECCS STD

81 IEEE PROMETEO

82 Section 1 - Test Plan Identifier Si limita a fornire un identificatore univoco del STP. Esso può essere relativo ad un intero sistema, a parte di esso o ad una specifica attività di test (i.e., performance test). Section 2 - Introduction Contiene una sintetica descrizione del sistema e fornisce i riferimenti alla documentazione di progetto esistente in area gestionale (i.e., SQAP, SCMP).

83 Section 3 - Test Items Elenca gli oggetti da sottoporre a test, la loro versione/revisione, i media impiegati per trasferirli alla struttura di collaudo. Fornisce i riferimenti alla documentazione tecnica di progetto, rilevante per il test da eseguire. Definisce cosa non deve essere sottoposto a collaudo (i.e., unità di acquisizione dati, ma non la connessione verso host system). Section 4 - Feature to be tested Per ogni test item elencato in Sezione 3 identifica tutte le feature o le combinazioni di feature da sottoporre a test. Identifica le specifiche di progettazione di test per ogni feature o combinazione di feature. Per feature si intende una caratteristica del software (i.e., funzionalità, prestazioni, ecc.). La scrittura di questa sezione è enormemente semplificata dalla definizione di una matrice di verifica nella fase di attività che prepara la stesura del STP.

84 Section 5 - Features not to be tested Strutturalmente molto simile alla precedente, questa sezione ha uno scopo diverso. Essa serve a illustrare al committente, cui il STP è sottoposto per approvazione, quali feature non verranno collaudate, in modo da evitare malintesi. E ovviamente buona norma indicare perchè tali feature non verranno collaudate e quando esse verranno collaudate (presumibilmente nell ambito di un altro STP). Section 6 - Approach E la sezione più corposa del STP, normalmente divisa in varie sottosezioni. Per ogni feature o combinazione di feature vengono specificate le attività, le tecniche e gli strumenti usati per il collaudo. In sostanza per ogni gruppo di feature elencato in Sezione 4, viene definito in dettaglio il test run da eseguire. Il livello di dettaglio deve essere sufficiente almeno per identificare con cura le attività di test da eseguire e per poterle pianificare dettagliatamente.

85 Section 7 - Item Pass/Fail Criteria Specifica, per ogni test item identificato in Sezione 3, i criteri per stabilire se il collaudo ha avuto esito positivo o meno. Se non esiste una documentazione separata di Specifica di dettaglio del collaudo, può essere necessario specificare in questa Sezione quali input verranno applicati al sistema e quali sono gli output attesi. In ogni caso deve essere chiaramente definito il criterio adottato per giudicare il risultato del collaudo (i.e., il test dell item sarà positivo se alla fine della sessione di collaudo si saranno verificati meno di 3 fault che non compromettono la funzionalità generale del sistema). In caso di eventuali fault è necessario specificare i criteri di ricollaudo successivi (i.e., tutto il collaudo previsto dal STP o una sua parte).

86 Section 8 - Suspension/Resumption Criteria Specifica i criteri di interruzione del collaudo e le attività da eseguire quando si riprende l attività di collaudo. La sospensione può ovviamente essere normale (i.e. alla fine di una giornata di lavoro) o anomala (i.e., in caso di guasto hardware). Per le sospensioni normali la cosa migliore, se possibile, è indicare nel STP i punti di possibile sospensione del collaudo. In questo caso potrebbe essere automaticamente definito anche il criterio di ripresa del collaudo a seguito di una sospensione anomala (i.e. l ultimo punto di sospensione normale raggiunto prima dell insorgere dell anomalia).

87 Section 9 - Test Deliverables Questa Sezione elenca cosa deve essere consegnato al cliente alla fine del collaudo. Lo standard IEEE , raccomanda il seguente elenco: Test Plan (STP) Test design specifications Test case specifications Test procedure specification Test item transmittal reports Test logs Test incident reports Test summary reports Test input and output data Test tools (i.e., stubs) Ovviamente questo elenco può non adattarsi a tutte le situazioni.

88 Section 10 - Testing Tasks Identifica tutte le attività necessarie per preparare ed eseguire il collaudo. Identifica tutte le dipendenze fra attività e le specifiche competenze necessarie per eseguirle. Section 11 - Environmental Needs Definisce come deve essere predisposto l ambiente di collaudo (hardware, software, strumenti). Specifica gli eventuali strumenti di test che debbono essere sviluppati per eseguire il collaudo (i.e., software stub, simulatori, ecc.).

89 Section 12 - Responsabilities Identifica i gruppi responsabili di gestire, progettare, preparare, eseguire, presenziare, controllare e risolvere problemi nella implementazione del STP. In particolare identifica i gruppi responsabili per la fornitura dei test items (Sezione 3) e per la realizzazione dell ambiente di collaudo (Sezione 11). Section 13 - Staffing and Training Specifica le esigenze di personale di collaudo per livello di skill (competenze e livello di esperienza professionale). Definisce come eseguire il training per fornire l appropriato livello di skill. La valutazione deve essere eseguita per ogni attività di collaudo pianificata in Sezione 10.

90 Section 14 - Schedule Include il Gantt delle attività di collaudo. Ovviamente deve essere appropriatamente coordinato col piano complessivo di progetto. Section 15 - Risks and Contingencies Identifica i rischi associati alla esecuzione del piano (i.e., un ritardo nella consegna di test items ) e definisce le tattiche di gestione (che comunque dovranno essere approvate dal project manager e dal commitente). Questa Sezione può essere la più importante del piano. Ovviamente è essenziale focalizzarsi solo sulle cose che potrebbero accadere con più alta probabilità e/o che potrebbero avere il più alto impatto sull esecuzione del piano. Il punto di partenza per elaborare questa sezione può essere un riesame di tutti i test items necessari (Sezione 3) e di tutte le esigenze relative all ambiente di collaudo (Sezione 11).

91 Section 16 - Approvals Include l elenco di tutte le persone che debbono approvare il piano, lasciando lo spazio per la loro firma.

92 IEEE PROMETEO

93 Lo standard IEEE è stato emendato nell anno Non sono state introdotte sostanziali modifiche nei contenuti, tuttavia l architettura descritta nella nuova release dello standard IEEE risulta leggermente modificata. Section 1 Identifier Identifica in modo univoco il test tramite un codice. Unitamente al codice identificativo (i.e. codice prodotto) sono riportati tutti gli identificativi di Versione/Revisione (i.e. V2.1a) nonché la Revision History (elenco di tutte le revisioni effettuate sul documento comprensivo di data ed autore della revisione e causa della revisione).

94 Section 2 References Contiene i riferimenti univoci a tutta la documentazione inerente al test plan (ad esempio: specifiche di design, documentazione su metodologie di test, guide di installazione di SW commerciale di supporto, report di anomalie riscontrate sul SW di supporto, documentazione relativa alla configurazione del SW, riferimenti al codice, etc). Section 3 Introduction In questa sezione sono riportate tutte le informazioni di corredo ai test (i.e. scopo delle attività di test, enti coinvolti nei test, budget delle attività di test, breve sunto delle attività di test, descrizione della filosofia di test applicata, etc). Questa sezione contiene anche una indicazione di massima della documentazione che verrà prodotta al termine dell esecuzione del test plan (Test Report).

95 Section 4 - Test configurations Elenca gli oggetti (item) da sottoporre a test, la loro versione/revisione, i media impiegati per trasferirli alla struttura di collaudo. Fornisce i riferimenti alla documentazione tecnica di progetto, rilevante per il test da eseguire. Definisce cosa non deve essere sottoposto a collaudo (i.e., unità di acquisizione dati, ma non la connessione verso host system). Section 5 - Product risk issues Identifica le aspettative essenziali e gli eventuali rischi connessi al test. Questa sezione deve dare un breve cenno alle aspettative (i.e. funzionalità, sicurezza, privacy) che si desidera raggiungere nel test ed evidenziare, ove possibile, gli impatti aziendali di possibili failure (i.e. feedback sulla progettazione, ritardi nelle linee di produzione, etc).

96 Section 6 - Features to be tested Per ogni test configuration item elencato in Sezione 4 identifica tutte le feature o le combinazioni di feature da sottoporre a test. Identifica le specifiche di progettazione di test per ogni feature o combinazione di feature. Unitamente alle feature da testare, occorre elencare tutte le feature escluse dal test. La scrittura di questa sezione è enormemente semplificata dalla definizione di una matrice di verifica nella fase di attività che prepara la stesura del STP. Nella matrice occorre spiegare, in caso di presenza di feature non testate, la ragione che ne impedisce il test (i.e., mancanza di specifiche, mancanza di componentistica) Section 7 - Approach E la sezione più corposa del STP, normalmente divisa in varie sottosezioni. Per ogni feature o combinazione di feature vengono specificate le attività, le tecniche e gli strumenti usati per il collaudo. In sostanza per ogni

97 gruppo di feature elencato in Sezione 6, viene definito in dettaglio il test run da eseguire. Il livello di dettaglio deve essere sufficiente almeno per identificare con cura le attività di test da eseguire e per poterle pianificare dettagliatamente. Section 8 - Termination criteria and resumption requirements Identifica i seguenti punti: Requisiti di Recovery dopo un test fallito (devono essere specificati i requisiti necessari a definire una nuova condizione sicura di partenza dei test) Politica di Test Regression (modalità di ripetizione di test già eseguiti con esito positivo. Tal volta si rende necessario rieseguire alcuni test; tipicamente a seguito di failure su altri test, o per attività di retesting dovute all introduzione di nuove feature) Criterio di determinazione del completamento dei singoli test e del test plan (indicazione di test eseguito, fine attività di test)

98 Criteri di sospensione di una porzione o dell intero test plan (possono essere presenti sospensioni normali o sospensioni anomale) Criterio di determinazione dell esito Positivo o Negativo del singolo test Non è sempre possibile identificare tutti i criteri e le politiche in oggetto, in ogni caso deve essere sempre chiaramente definito il criterio adottato per giudicare il risultato del collaudo. In caso di eventuali fault è necessario specificare i criteri necessari a ricollaudi successivi (i.e., tutto il collaudo previsto dal STP o una sua parte).

99 Section 9 - Test deliverables Questa Sezione elenca cosa deve essere consegnato al cliente alla fine del collaudo. Lo standard IEEE , raccomanda il seguente elenco: Test Plan (STP) Test design specifications Test case specifications Test procedure specification Test item transmittal reports Test logs Test incident reports Test summary reports Test input and output data Test tools & user manual (i.e., stubs) Ovviamente questo elenco può non adattarsi a tutte le situazioni.

100 Section 10 - Testing tasks Identifica tutte le attività necessarie per preparare ed eseguire il collaudo. Identifica tutte le dipendenze fra attività e le specifiche competenze necessarie per eseguirle. Identifica le responsabilità associate ad ogni attività. Section 11 - Environmental needs Definisce come deve essere predisposto l ambiente di collaudo (hardware, software, network, strumenti). Specifica gli eventuali strumenti di test che debbono essere sviluppati per eseguire il collaudo (i.e., software stub, simulatori, ecc.).

101 Section 12 - Staffing & training needs Specifica le esigenze di personale di collaudo per livello di skill (competenze e livello di esperienza professionale). Definisce come eseguire il training per fornire l appropriato livello di skill. La valutazione deve essere eseguita per ogni attività di collaudo pianificata in Sezione 10. Section 13 - Summary of responsibilities Identifica i gruppi responsabili di gestire, progettare, preparare, eseguire, presenziare, controllare e risolvere problemi nella implementazione del STP. In particolare identifica i gruppi responsabili per la fornitura dei test configuration items (Sezione 4) e per la realizzazione dell ambiente di collaudo (Sezione 11).

102 Section 14 Schedule Contiene il Gantt delle attività di collaudo, identifica e specifica le principali attività da svolgere (key activities) e le principali scadenze tecniche/commerciali (milestones) relative agli item sotto test. Section 15 - Planning risks & contingencies Identifica i rischi associati alla esecuzione del piano (i.e., un ritardo nella consegna di test configuration items ) e definisce le tattiche di gestione (che comunque dovranno essere approvate dal project manager e dal commitente). Questa Sezione può essere la più importante del piano. Ovviamente è essenziale focalizzarsi solo sulle cose che potrebbero accadere con più alta probabilità e/o che potrebbero avere il più alto impatto sull esecuzione del piano. Il punto di partenza per elaborare questa sezione può essere un riesame di tutti i test

103 configuration item necessari (Sezione 4) e di tutte le esigenze relative all ambiente di collaudo (Sezione 11). Ove possibile vengono elencate alternative plausibili per risolvere situazioni di rischio. Section 16 - Approvals Include l elenco di tutte le persone che debbono approvare il piano, lasciando lo spazio per la loro firma. Section 17 Glossary Elenca tutti i termini essenziali per la comprensione del documento.

104 DOD-STD-2167A PROMETEO

105 Section 1 - Scope Definisce lo scopo del Test Plan. Va tenuto presente che lo standard DOD è orientato alla definizione di collaudi di tipo formale (i.e., acceptance test). Paragraph Identification Riporta il numero di identificazione, il nome e la sigla del sistema o del sottosistema da sottoporre a collaudo. Può includere un diagramma di struttura di alto livello del sistema. Paragraph System Overview Contiene una sintetica descrizione del sistema da collaudare.

106 Paragraph Document Overview Descrive la struttura del documento, evidenziando eventuali difformità rispetto allo standard DOD. Paragraph Relationship to other plans Descrive le relazioni con le attività di test definite in altri piani di progetto (i.e., collaudi di tipo non formale). Section 2 - Referenced Documents Indica tutta la documentazione di progetto rilevante allo scopo della implementazione del Test Plan.

107 Section 3 - Software Test Environment Questa sezione è dedicata alla descrizione di tutte le risorse (software, firmware e hardware) necessarie per la esecuzione del collaudo. Si tenga presente che le risorse software possono includere anche software di test o software commerciale necessario per il test (i.e, debugger, librerie di utilità). Paragraph Software Items Lista tutti i software item (sistemi operativi, compilatori, code auditor, dynamic path analyzer, test driver, preprocessori, generatori di dati di test e postprocessori) necessari per l esecuzione del test e ne definisce lo scopo.

108 Paragraph Hardware and firmware items Come per il paragrafo precedente ma riferito a oggetti hardware (i.e., computer, oscilloscopio, ecc.) o a firmware. Paragraph Proprietary nature and government rights Definisce aspetti legati a fattori come licenze di software. Lo scopo è anche quello di definire come certi strumenti di collaudo possono essere approvvigionati da parte del committente, per la gestione post-progettuale del prodotto.

109 Paragraph Installation, testing and control Definisce il piano per la installazione, il collaudo (i.e, uso di diagnostici hardware) e il controllo (i.e., controllo delle release di hardware e software) dell ambiente di collaudo.

110 Section 4 - Formal Qualification and Test Identification Questa sezione descrive in dettaglio tutti i collaudi da eseguire. Paragraph 4.X - (CSCI name and project-unique identifier) Il Test Plan può includere il collaudo di più CSCI (Computer Software Configuration Item).

111 Subparagraph 4.X.1 - General Test Requirements Definisce i requisiti generali del collaudo del CSCI (i.e., misure di dimensione e di tempi di risposta, requisiti di error recovery, ecc.). Subparagraph 4.X.2 - Test Classes Definisce le categorie di test cui il CSCI deve essere sottoposto. Lo standard elenca le seguenti categorie: Stress (ambiente operativo non più conforme a quello delle specifiche di progetto), Timing, Erroneous input, Maximum Capacity (carico di elaborazione massimo tollerabile). Esso non cita un altra categoria essenziale: il collaudo funzionale.

112 Subparagraph 4.X.3 - Test Levels Indica i livelli a cui il collaudo va condotto: a livello CSCI, a livello di integrazione fra CSCI (controllo della soddisfazione dei requisiti delle interfacce esterne), a livello di integrazione col target hardware, a livello sistema. Subparagraph 4.X.4 - Test Definitions Elenca tutti i collaudi da eseguire per il CSCI X.

113 Subparagraph 4.X.4.Y - (Test name and project-unique identifier) Contiene la definizione del test Y da eseguire sul CSCI X. Oltre al nome e all identificatore (un numero), deve essere definito quanto segue: - obiettivo del test - requisiti particolari (i.e., attrezzaggi particolari) - test level: uno di quelli definiti in 4.X.3 - test class: una di quelle definite in 4.X.2 - metodo di qualificazione: ispezione, analisi (calcolo) o dimostrazione (esecuzione); in caso di collaudo simultaneo di più requisiti è meglio includere una matrice requisito-metodo - riferimenti alla documentazione di Software Requirement Specification per i requisiti da collaudare - come sopra ma riferito alla documentazione di Interface Requirements Specification - tipo di dati da registrare: risultato globale del test, misure di tempo di risposta, ecc. - assunzioni e vincoli che debbono essere tenuti in considerazione nella esecuzione del test.

114 Subparagraph 4.X.5 - Test Schedule Contiene ovviamente il piano di collaudo per il CSCI X. Section 5 - Data Recording, Reduction and Analysis Questa sezione riporta tutti gli algoritmi necessari per valutare la correttezza del software. In sostanza indica come manipolare i dati raccolti durante il collaudo, in accordo a quanto specificato in 4.X.4.Y. Section 6 - Notes Questa sezione può essere usata per riportare informazioni aggiuntive e complementari utili per la esecuzione del collaudo. Le informazioni contenute qui non vengono considerate vincolanti da un punto di vista contrattuale.

115 Appendici Contengono informazioni aggiuntive come le note incluse in Section 6. Le differenze sono però due: a) i contenuti delle appendici sono considerati contrattualmente vincolanti, b) le appendici possono essere staccate dal corpo base del Test Plan e pubblicate/ trasmesse separatamente; per questo possono essere utilmente usate per includere informazioni considerate particolarmente critiche (i.e., in applicazioni militari).

116 MIL-STD-498 PROMETEO

117 Lo standard MIL-STD-498, definito nell anno 1994 dal Departement of Defense (USA) come sviluppo del precedente DOD-STD-2167A, si basa su documenti identificabili con l acronimo DID (Data Item Description). Tali documenti descritti utilizzando sezioni e paragrafi, riassumono le specifiche da rispettare per sottostare allo standard medesimo. Analizzeremo ora la documentazione specifica per realizzare un test plan di progetto (Software Test Plan DOD o STP-DID).

118 Section 1 Scope Definisce lo scopo del Test Plan. Va tenuto presente che lo standard MIL è orientato alla definizione di collaudi di tipo formale (i.e. acceptance test). Paragraph 1.1 Identification Riporta il numero di identificazione, il nome e la sigla del sistema o del sottosistema e del softaware da sottoporre a collaudo. Paragraph 1.2 System Overview Contiene una sintetica descrizione del sistema da collaudare. Identifica gli enti (Customer, Developer, Tester, ) coinvolti nel progetto. Paragraph 1.3 Document Overview Descrive la struttura del documento, evidenziando eventuali difformità rispetto allo standard MIL.

119 Paragraph 1.4 Relationship to other plans Descrive le relazioni con le attività di test definite in altri piani di progetto (i.e. collaudi di tipo non formale). Section 2 Referenced Documents Indica tutta la documentazione di progetto rilevante allo scopo dell esecuzione del test plan. Ove questa documentazione non sia comunemente disponibile, ne indica le fonti d approvvigionamento. Section 3 Software Test Environment Questa sezione è dedicata alla descrizione di tutte le risorse (software, hardware, firmware, etc ) necessarie per l esecuzione del collaudo. Si tenga presente che le risorse software possono includere anche software di test o software commerciale necessario al test (i.e. debugger, librerie di utilità).

120 Paragraph 3.x (Name of test site(s)) Identifica la sede ove avvengono le attività di test. Sono individuati tutti gli item (i.e. apparecchiature, software, personale, etc ) necessari al test plan per la specifica sede di test. Nel caso più sedi siano presenti (i.e. test remoti) più paragrafi di questo tipo saranno presenti. Paragraph 3.x.1 Software Items Lista tutti i software item (sistemi operativi, compilatori, code auditor, database, dynamic path analyzer, test driver, preprocessori, generatori di dati di test e postprocessori) necessari per l esecuzione del test e ne definisce lo scopo. Paragraph 3.x.2 Hardware and firmware Items Come per il paragrafo precedente, ma riferito a oggetti hardware (i.e. computer, oscilloscopio, multimetri, etc ) o a firmware.

121 Paragraph 3.x.3 Other materials Come per il paragrafo precedente, ma riferito tutti i materiali di supporto (manuali, listati, tape, unità magnetiche, ). Ogni elemento presente in questo paragrafo deve essere identificato mediante un codice ed una tipologia esclusiva (formato del media, template del documento, etc). Paragraph 3.x.4 Proprietary nature, acquirer s right and licensing. Identifica la natura della proprietà (i.e. copyright) ed i diritti dell acquirente (i.e. facoltà di distribuzione). In oltre definisce aspetti legati a fattori legali come licenze del software. Lo scopo è di definire come certi strumenti di collaudo possono essere approvvigionati da parte del committente per la gestione postprogettuale del prodotto.

122 Paragraph 3.x.5 Installation, testing and control Definisce il piano per l installazione, il collaudo (i.e. uso di diagnostici hardware) ed il controllo (i.e. controllo delle release hardware e software) dell ambiente di collaudo. Paragraph 3.x.6 Partecipating organizations Identifica gli enti organizzativi partecipanti, il loro ruolo e responsabilità. Paragraph 3.x.7 Personnel Identifica la tipologia di personale (skill, numero di elementi, rotazione e turni, ) necessaria all esecuzione dei test. Se presenti, sono evidenziati gli skill essenziali per assicurare la continuità dei test prolungati.

123 Paragraph 3.x.8 Orientation Plan Descrive tutte le attività preliminari di addestramento specifico necessarie al personale prima di intraprendere l attività di test. Se le attività di addestramento specifico sono numerose, occorre evidenziare un planing opportuno delle medesime. Paragraph 3.x.9 Test to be performed Identifica i test da svolgere referenziando, ove opportuno la successiva sezione 4. I test elencati in un paragrafo 3.x, sono intesi relativi alla sola sede di test x.

124 Section 4 Test Identification Questa sezione descrive in dettaglio tutte le attività di test previste nel test plan da eseguire. Paragraph 4.1 General information Questo paragrafo specifica informazioni generali applicabili alle attività di test. Paragraph Test levels Indica i livelli a cui il collaudo va condotto: livello CSCI (Computer Software Configuration Item), livello d integrazione fra CSCI (controllo della soddisfazione dei requisiti delle intrefacce esterne), livello d integrazione del target hardware e livello di sistema. Paragraph Test classes Identifica la tipologia delle attività di test (i.e. performance test, overload test, negative test). Sono previste casistiche di test negativi.

125 Paragraph General test conditions Questo paragrafo elenca le condizioni applicabili alla totalità dei test e quelle applicabili a ciascun sottogruppo di test. Per ogni test occorre: indicare un tempo approssimativo d esecuzione dare un riferimento del peso relativo del singolo test sul totale dei test da effettuare (i.e. percentuale di completamento dell intero test plan) fornire indicazioni sulle attività di re-test e sui test di regressione. Paragraph Test progression In caso di test cumulativi (i.e. test su sotto-unità e test sulla unità complessiva) o progressivi (i.e. test a catena) questo paragrafo identifica le corrette sequenze d esecuzione dei singoli test.

126 Paragraph Data recording, reduction and analysis Questo paragrafo riporta tutti gli algoritmi necessari per valutare la correttezza del software. In sostanza indica come manipolare i dati grezzi raccolti durante i test. Paragraph 4.2 Planned tests Questo paragrafo raggruppa la totalità delle attività di test da svolgere. Paragraph 4.2.x (Item(s) to be tested) Questi paragrafi identificano ogni CSCI, sottosistema, sistema o entità tramite una sigla univoca all interno del progetto definendo tutti i test alla quale sono sottoposti durante il test plan. I test in questo paragrafo sono da intendersi come insiemi di test elementari (test case); non è scopo di questo documento descrivere ogni singolo test elementare (i.e. Nel caso di test su una calcolatrice, nel presente documento troveremo solo la definizione del test sulle operazioni aritmetiche di base, non 4 test dettagliati sulle singole operazioni +,-,*,/.).

127 Paragraph 4.2.x.y (Project-unique identifier of a test) Contiene la definizione del test y da eseguire sull item (CSCI, sottosistema, sistema ) x. Oltre all identificativo deve essere definito quanto segue: Obiettivo del test Test level: uno di quelli definiti in Test class: una di quelle definite in Metodo di qualificazione: ispezione, analisi (calcolo) o dimostrazione (esecuzione); in caso di collaudo simultaneo di più requisiti è meglio includere una matrice requisitometodo Riferimenti ai requisiti del CSCI da validare Riferimenti alla documentazione di Software Requirement Specification per i requisiti da collaudare Requisiti particolari (i.e. strumentazione particolare) Tipologia di dati da registrare: risultato globale del test, misure di tempo di risposta, etc Metodologia di registrazione dei dati (i.e. annotazioni, plot, )

128 Assunzioni e vincoli che debbono essere tenuti in considerazione nell esecuzione del test Considerazioni sull incolumità, sulla sicurezza e sulla privacy associate al test Section 5 Test schedules Questa sezione contiene il piano di collaudo (tutti i test) cosi raggruppato: Descrizione delle sedi di test e delle sessioni di test Schedule delle attività per ogni sede di test (durata, attività, principali requisiti testati, etc)

129 Section 6 Requirements traceability Questa sezione contiene: Descrizione della copertura d ogni test sui requisiti dei CSCI e sui requisiti applicabili presenti nel Software Requirements Specifications (eventualmente richiamando quanto descritto nei vari paragrafi 4.2.x.y) Tracciabilità di ogni requisito CSCI coperto dal test plan (si noti che alcuni requisiti specificati potrebbero essere lasciati intenzionalmente scoperti dal test plan, di qui la necessità di evidenziare l effettiva copertura; tale nota vale anche per i punti successivi) Tracciabilità di ogni requisito applicabile descritto nel Software Requirements Specifications coperto dal test plan Tracciabilità di ogni requisito applicabile descritto nel Interface Requirements Specifications coperto dal test plan Tracciabilità di ogni requisito applicabile descritto nel System/Subsystem Specification coperto dal test plan

130 Lo standard non specifica in modo diretto il mezzo da utilizzare per rappresentare la tracciabilità dei requisiti. Una sperimentata metodologia di lavoro risulta quella di definire una o più matrici requisiti test, eventualmente focalizzate su specifiche aree funzionali del test plan (i.e. funzioni di acquisizione, funzioni di conversione, funzioni di archiviazione, etc). Ad esempio una possibile matrice, senza nessuna validità di standard: Test_D1 Test_ID2 Test_ID3 Acquisizione Si No In parte Conversione In parte Si In parte Archiviazione No No Si Tramite tali matrici è possibile mappare l effettiva copertura dei requisiti ed identificare agevolmente il test da eseguire per un dato requisito.

131 Section 7 Notes Questa sezione può essere usata per riportare informazioni aggiuntive e complementari utili all esecuzione del collaudo (i.e. acronimi, glossario, etc). Le informazioni contenute qui non sono considerate vincolanti da un punto di vista contrattuale. Section 8 Appendixes Contengono informazioni aggiuntive come nel caso della sezione 7. Le differenze sono però due: i contenuti delle appendici sono applicabili e quindi considerati contrattualmente vincolanti le appendici possono essere staccate dal corpo base del Test Plan e pubblicate/trasmesse separatamente. Per questo possono essere utilmente usate per includere informazioni considerate particolarmente critiche (i.e. in applicazioni militari)

132 NOTE: Sempre nel medesimo standard sono specificati ulteriori documenti validi nelle procedure di test: documento per la preparazione dei singoli test, per la realizzazione di test case e procedure per la validazione dei singoli elementi software (CSCI, sottositemi, etc). Il DID di riferimento in questo caso si identifica con SOFTWARE TEST DESCRIPTION DID o STD- DID. documento per l archiviazione delle operazioni svolte e dei risultati ottenuti durante l esecuzione dei singoli test (test report). Il DID di riferimento in questo caso si identifica con SOFTWARE TEST REPORT o STR-DID.