Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
PROMETEO
Il Collaudo del software
Principi e metodologie di lavoro Autore: G. Ceseri
PROMETEO
Contenuti Fondamenti di qualità del software Principi del TQM Il modello del SEI La normativa ISO 9000-3 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
PROMETEO
Fondamenti di qualità del software I difetti non si ottengono gratis. Qualcuno li ha prodotti, ed è stato pagato per farli. W.E. Deming
PROMETEO
Principi del Total Quality Management
PROMETEO
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.
PROMETEO
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.
PROMETEO
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’.
PROMETEO
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.
PROMETEO
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.
PROMETEO
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.
PROMETEO
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.
PROMETEO
ACT PLAN
CHECK DO
Il ciclo PDCA deve essere iterato continuamente, apportando nuove migliorie nello stadio ACT.
TQM
PROMETEO
Per poter affinare continuamente il processo è essenziale instaurare un sistema di raccolta dati sul processo, da cui derivare le indicazioni su come modificarlo.
PROMETEO
Classificazione del livello di maturità del processo di produzione del
software
Il modello SEI
PROMETEO
1 Initial level 2 Repeatable level 3 Defined level 4 Managed level 5 Optimizing level
PROMETEO
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’
PROMETEO
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
PROMETEO
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
PROMETEO
Solo al livello 3 (processo definito) l’impiego di CASE tool può dare risultati significativi.
Process
People Tools
PROMETEO
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’
PROMETEO
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
PROMETEO
Evoluzione del processo
Basic mgmt control Process definition Process mgmt Process control
Initial
Repeatable
Defined
Managed
Optimizing
PROMETEO
Aspetti chiave 1. Chaos 2. Project Management Produttività 3. Methods and Tools & Qualità 4. Metrics 5. Qualità
PROMETEO
La situazione al 1991
7 % 12 % L 3 L 2 L 1 81 %
PROMETEO
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.
PROMETEO
ISO 9000 - 3 Guida per l’applicazione di ISO 9001
allo sviluppo, alla fornitura e alla manutenzione del software
PROMETEO
ISO 9001
Sistema di qualità- Modello per la garanzia di qualità nel progetto/sviluppo, produzione, istallazione e servizio
PROMETEO
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 9001.
Deve avvenire una review periodica del sistema di qualità.
L’acquirente è responsabile della nomina di un rappresentante per la gestione cooperativa del rapporto contrattuale.
PROMETEO
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.
PROMETEO
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.
PROMETEO
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à.
PROMETEO
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.
PROMETEO
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.
PROMETEO
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.
PROMETEO
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.).
PROMETEO
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.
PROMETEO
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.
PROMETEO
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.
PROMETEO
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
PROMETEO
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 evento in cui uno stimolo
(input) porta a manifestare un “error” non rilevato precedentemente
Failure evento per cui il sistema perde
la capacità di compiere la sua missione, come conseguenza di uno o più “fault”
PROMETEO
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
PROMETEO
Manutenibilità
Astrazione + Struttura + Leggibilità + Tracciabilità + Bassa complessità dei componenti + Buona documentazione + Buon SCM = Manutenibilità
PROMETEO
Tracciabilità
quale modulo software
quale funzionalità
quale elemento della struttura dati
quale sottosistema dell’architettura
Difetto
PROMETEO
Tracciabilità
quale modulo software
quale funzionalità
quale elemento della struttura dati
quale sottosistema dell’architettura
nuova esigenza funzionale
PROMETEO
Tracciabilità
E’ pesantemente influenzata dalla complessità
delle interfacce software. Esse debbono essere:
- poche
- a basso throughput
- assoggettabili a monitoring
PROMETEO
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
PROMETEO
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”.
PROMETEO
Regola di Pareto
L’ 80% dei problemi deriva dal 20% dei sottosistemi.
PROMETEO
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
PROMETEO
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à.
PROMETEO
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)
PROMETEO
Software Quality Assurance Plan
Definisce il piano di qualità adottato
per uno specifico sviluppo software.
PROMETEO
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 730-1984 / ESA PSS-05-0
PROMETEO
Preparazione delle attività di collaudo (fase 1)
1. Identificazione dei requisiti
2. Associazione dei requisiti alle unità di software
3. Definizione dei test e delle catene/sequenze di test
Req. Doc
Matrice di verifica
SW Design Doc.
Matrice di tracciabilità
Test case e catene di test
PROMETEO
Matrice di verifica Metodo I = ispezione del codice
A = esecuzione di calcoli (i.e., calcolo di occupazione di memoria)
T = esecuzione Livello M = modulo/sottosistema
S = sistema
I = installazione (hw + sw)
Numero di Req. Paragrafo Descrizione
LivellMetodo
M S I I A T
0340101 3.4.1.1
PROMETEO
Matrice di tracciabilità
Aggiunge alla matrice di verifica una
colonna, per identificare le unita’ di
software coinvolte nel conseguimento del
requisito.
PROMETEO
Diagramma di sequenza di test
Req. 4 Req. 1 Req. 3
Req. 2
Hardware speciale
PROMETEO
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).
PROMETEO
Preparazione delle attività di collaudo (fase2)
4. Definizione del materiale di supporto
5. Definizione di date e durate
6. Predisposizione di un piano di integrazione
7. Scrittura del STP
Lista materiale
Project Plan
SQAP
SCMP
STP
Test case e catene di test
Matrice di tracciabilità
PROMETEO
Materiale di supporto
Software di collaudo Strumenti di collaudo Simulatori
PROMETEO
Tecniche di integrazione
1) Big - Bang 2) Top - Down 3) Bottom - Up 4) SW Layers
PROMETEO
Ovviamente la stesura di un
STP è, di norma, ottenuta
mediante un processo di
affinamento successivo.
PROMETEO
Procedura ESA PSS-05-0
Implementation of tests
List of acceptance test
Documento UR SR AD DD
SQAP
SCMP
STP
Fase
Detailed SQAP
Initial SQAP
STP3 STP1 STP2
SCMP
Design of test
PROMETEO
Tecniche di collaudo Non esistono proiettili d’argento. Frederik Brooks
PROMETEO
Ispezione
Utile per collaudare situazioni difficilmente riproducibili (i.e., condizioni di errore di system services).
Analisi
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.
PROMETEO
Tecniche di test
Black-Box testing
E’ la tecnica di test fondamentale. L’unica valida per i test formali di accettazione.
SISTEMA
OUTPUT
OUTPUT ATTESO
STIMOLO
?
PROMETEO
Tecniche di test
White-Box testing (Glass-Box testing)
Di solito è usato informalmente (istintivamente) a livello di test di modulo.
TEST 2
TEST 1
OUT OK?
PROMETEO
La copertura funzionale
E’ in sostanza la percentuale di funzionalità elementari coperte dal collaudo.
E’ perseguita dal black-box testing.
PROMETEO
La copertura topologica
C0 = N. istruzioni esercitate almeno una volta / N. totale di istruzioni eseguibili
(copertura istruzioni)
C1 = copertura dei ‘segmenti’ di programma
C2 = copertura del richiamo di moduli e sottoprogrammi
C3 = 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 20-25 %.
PROMETEO
Tipologia dei test
TEST POSITIVI funziona!
TEST NEGATIVI è robusto!
PROMETEO
Fasi dell’attività di collaudo
La montagna c’è e ci sarà finchè esiste la coscienza. Robert Pirsing
PROMETEO
Test di modulo
Test di integrazione
Test funzionale
Test di sistema
Test di accettazione
PROMETEO
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 glass-box.
PROMETEO
Test di integrazione
Ha come scopo principale il collaudo delle interfacce software, oppure la verifica della corretta interazione fra hardware e software.
PROMETEO
Test funzionale
Ha lo scopo di validare funzionalmente il sistema.
E’ condotto con tecnica black-box.
PROMETEO
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?
PROMETEO
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.
PROMETEO
Test di accettazione
E’ il collaudo formale condotto prima del rilascio del prodotto al committente. E’ eseguito secondo procedure concordate fra committente e fornitore.
PROMETEO
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
PROMETEO
IEEE 829-1983
IEEE 829-1998
DOD-STD-2167A
MIL-STD-498
ESA PSS-05-0
ECCS STD
PROMETEO
IEEE 829-1983
PROMETEO
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).
PROMETEO
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.
PROMETEO
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.
PROMETEO
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).
PROMETEO
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).
PROMETEO
Section 9 - Test Deliverables Questa Sezione elenca cosa deve essere consegnato al cliente alla fine del collaudo. Lo standard IEEE 829-1983, 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.
PROMETEO
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.).
PROMETEO
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.
PROMETEO
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).
PROMETEO
Section 16 - Approvals Include l’elenco di tutte le persone che debbono approvare il piano, lasciando lo spazio per la loro firma.
PROMETEO
IEEE 829-1998
PROMETEO
Lo standard IEEE 829-1983 è stato emendato nell’anno 1998. Non sono state introdotte sostanziali modifiche nei contenuti, tuttavia l’architettura descritta nella nuova release dello standard IEEE 829-1998 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).
PROMETEO
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).
PROMETEO
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).
PROMETEO
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
PROMETEO
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)
PROMETEO
• 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).
PROMETEO
Section 9 - Test deliverables Questa Sezione elenca cosa deve essere consegnato al cliente alla fine del collaudo. Lo standard IEEE 829-1998, 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.
PROMETEO
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.).
PROMETEO
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).
PROMETEO
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
PROMETEO
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.
PROMETEO
DOD-STD-2167A
PROMETEO
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 1.1 - 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 1.2 - System Overview
Contiene una sintetica descrizione del sistema da collaudare.
PROMETEO
Paragraph 1.3 - Document Overview
Descrive la struttura del documento, evidenziando eventuali difformità rispetto allo standard DOD.
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 della implementazione del Test Plan.
PROMETEO
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 3.1 - 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.
PROMETEO
Paragraph 3.2 - Hardware and firmware items Come per il paragrafo precedente ma riferito a oggetti hardware (i.e., computer, oscilloscopio, ecc.) o a firmware.
Paragraph 3.3 - 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.
PROMETEO
Paragraph 3.4 - 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.
PROMETEO
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).
PROMETEO
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.
PROMETEO
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.
PROMETEO
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.
PROMETEO
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.
PROMETEO
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).
PROMETEO
MIL-STD-498
PROMETEO
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).
PROMETEO
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.
PROMETEO
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à).
PROMETEO
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.
PROMETEO
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 post-progettuale del prodotto.
PROMETEO
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.
PROMETEO
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.
PROMETEO
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 4.1.1 – 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 4.1.2 – Test classes Identifica la tipologia delle attività di test (i.e. performance test, overload test, negative test). Sono previste casistiche di test negativi.
PROMETEO
Paragraph 4.1.3 – 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 4.1.4 – 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.
PROMETEO
Paragraph 4.1.5 – 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 +,-,*,/.).
PROMETEO
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 4.1.1 � Test class: una di quelle definite in 4.1.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 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, …)
PROMETEO
� 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)
PROMETEO
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
PROMETEO
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.
PROMETEO
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)
PROMETEO
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.
PROMETEO
ESA PSS-05-0
PROMETEO
STP, Part 1 Sviluppato nella fase SR, definisce l’elenco degli acceptance test
STP, Part 2 Sviluppato nella fase AD, include il progetto di ogni test e la specifica degli archivi dati e del software di test necessari al collaudo
STP, Part 3 Sviluppato nella fase DD, definisce le procedure di esecuzione dei test.
PROMETEO
Struttura tipica del STP 1. Scopo del Test Plan (descrizione dell’approccio e dei principi su cui basare l’acceptance test) 2. STP, Part 1. Lista dei test. 3. STP, Part 2. Progetto dei test e archivi dati necessari 3.1 Definizione dell’hardware e dell’ambiente di esecuzione del collaudo 3.2 Archivi dati di collaudo 4. STP, Part3. Lista dei test e relative procedure 5. Riferimenti alla documentazione rilevante
PROMETEO
ECCS STD
PROMETEO
Lo standard ECSS STD si deve considerare una revisione dello standard ESA-PSS-05. Al momento esistono solo draft parziali del nuovo standard. Si prevedono ancora alcuni anni prima di poter usufruire della documentazione definita del nuovo stantard.
PROMETEO
Conclusioni Lo standard ESA è un po' povero, però può essere utile per progetti con budget di collaudo limitato. Lo standard IEEE (in entrambe le release) è il più organico, ma richiede la realizzazione di un numero notevole di documenti (l’STP è un documento puramente gestionale), lo standard MIL (DOD) presenta invece una complessità intermedia.
PROMETEO
Collaudo di regressione Al momento della Qualità pura soggetto e oggetto sono identici. Robert Pirsing
PROMETEO
Quando si esegue una modifica alla
Software Configuration (correttiva,
perfettiva o adattativa) devono essere
eseguiti collaudi che mirano a verificare che
non siano insorti ‘effetti collaterali’ inattesi.
Questo tipo di collaudi sono chiamati
regression test.
PROMETEO
Gli ‘effetti collaterali’ su parti di codice non modificato possono derivare da: 1) connessioni sui dati,
2) interdipendenze temporali,
3) interdipendenze fra requisiti di sistema (cambiare R1 porta a non soddisfare R2)
PROMETEO
In teoria, dopo ogni modifica, si dovrebbe quindi rieseguire per intero il testing del prodotto software. Questo è però molto oneroso e quindi si deve ricorrere ad approcci diversi.
PROMETEO
Approcci al regression testing
1) Identificazione di tutte le interconnessioni ‘potenziali’ e ricollaudo, oltre che del modulo modificato, di tutti i moduli influenzabili.
2) Esecuzione del regression testing
mediante il lancio di un ‘caso prova’ che copra il sistema in modo significativo.
3) Esecuzione automatica del regression
testing. 4) Procedure di SCM che accorpano le
modifiche nella emissione di una nuova ‘release’, sottoposta ad un collaudo severo.
5) Combinazione delle tecniche precedenti.
PROMETEO
La non corretta gestione delle modifiche e del regression testing portano a fenomeni di ‘entropizzazione’ del software.
PROMETEO
Andamento dei fault
MODIFICHE
CURVA IDEAL E
ENTROPIZZAZIONE
HARDWARE
SOFTWARE
TEMPO
TEMPO
MORTALITA’ INFANTILE
USURA
(R. S. Pressman, 1987)
PROMETEO
L’incremento di fault rate conseguente a modifiche dipende da:
1) qualità dell’architettura (struttura intellettuale) del sistema,
2) conoscenza del sistema da parte del
manutentore software, 3) coerenza delle modifiche con la
struttura intellettuale del sistema, 4) qualità del regression testing.
PROMETEO
Strumenti per il collaudo del software Tutto deve essere fatto il più semplice possibile, ma non più semplice. Attribuito ad A. Einstein
PROMETEO
Poichè l’attività di collaudo è estremamente costosa, è necessario eseguirla con gli strumenti opportuni. Tutti gli strumenti necessari debbono essere identificati nel STP.
PROMETEO
Strumenti per l’analisi e la simulazione dell’I/O
• Multimetri, oscilloscopi
• Logic state analyzer
• Monitor di linee seriali
• Analizzatori di protocollo
• Generatori e simulatori di segnali
• Generatori di protocolli
PROMETEO
Strumenti orientati al codice
• Analizzatori statici di codice
• Analizzatori di complessità del codice
• Debugger simbolici
PROMETEO
Strumenti orientati al sistema
• System level debugger
• Performance profiler
• Gestori di versioni e generatori di • software release
• Generatori di dati di test
• Analizzatori di interdipendenze per • regression testing
• Logger di dati di test
PROMETEO
Strumenti orientati all’applicazione
• Software stub
• Simulatori completi per il test automatico
• Tracciatori
Normalmente vengono sviluppati ‘ad hoc’ per il collaudo di un prodotto software e vanno posti sotto SCM.
PROMETEO
Strumentazione del codice
Un codice ‘strumentato’ include parti espressamente dedicate al supporto della attività di collaudo, ad esempio:
1) istruzioni di stampa,
2) istruzioni di asserzione,
3) variabili per la memorizzazione di risultati intermedi.
Va tenuto presente che il codice di ‘strumentazione’ non può essere rimosso a fine collaudo, in quanto la rimozione altera l’immagine eseguibile e quindi il comportamento (specie quello dinamico) del prodotto.
PROMETEO
Strumenti per la gestione della documentazione
• Gestori di documentazione per la
specificazione e il progetto dei test. • Generatori di test report • Gestori di dati su modifiche e di ‘history’
del codice.
PROMETEO
Strumenti di gestione di dati metrici
Si tratta essenzialmente di gestori di basi di dati metrici legati alla qualità del software: - numero di fault,
- ripartizione per classe,
- fault rate trending,
- tempo medio di correzione, . . .
PROMETEO
Automazione delle
attivita’ di collaudo
Io ho sei onesti servitori (essi mi hanno insegnato tutto quello che so). I loro nomi sono Cosa e Perche’ e Quando e Come e Dove e Chi. Rudyard Kipling
PROMETEO
Gestori di dati di collaudo
Esecutori automatici
Generatori di dati di prova
Generatori di casi di prova
Automazione del collaudo
PROMETEO
Gestori di dati di collaudo - data base di casi prova - data base di esiti del collaudo - generatori di ‘test report’ - generatori di statistiche su campagne di collaudo.
PROMETEO
Generatori di dati di prova Possono essere di tipo ‘custom’ (realizzati per uno specifico progetto o prodotto) o di tipo ‘general purpose’ (operanti su descrizioni della struttura dati in ingresso).
misure
Generatore file
Generatore segnali
Sistema sotto
collaudo
PROMETEO
Generatori di casi di prova Si tratta di sistemi capaci di generare un elenco di casi di prova a partire da una dettagliata descrizione formale del sistema sotto collaudo.
PROMETEO
Esecutori automatici Si tratta normalmente di monitor di lancio capaci di mandare in esecuzione automatica i casi di prova. Sono normalmente ‘custom’, ma possono basarsi su prodotti ‘general purpose’ (i.e., generatori di applicazioni di controllo).
PROMETEO
Esempio 1 Monitor di lancio per ‘unit test’.
Monitor di lancio
Sw Stub
Software unit
stimoli reazioni
Sw Stub
PROMETEO
Esempio 2
‘Regression test’ da I/O archiviato. Applico l’input da ‘file A’ e controllo la congruenza fra output ridiretti su ‘file B e C’ e ‘file B e C’ campioni.
Sistema
out video (file B)
Input (file A)
out printer (file C)
PROMETEO
Esempio 3 ‘Regression test’ automatico. Monitor di lancio e analizzatore esiti
Sistema RT
Test report
Test description
I
O
PROMETEO
Ovviamente devo avere delle descrizioni di correlazioni fra casi di prova, in modo da stabilire quali casi si possono eseguire in presenza di esiti anomali.
tc1
tc2
tc3
tc4
tc5
PROMETEO
Manutenzione e
Software Configuration Management Tutto si deve fare con equilibrio, tenendo conto dei deboli. La Regola di S. Benedetto
PROMETEO
L’essenza del problema di SCM
Frequentemente i SW engineer considerano il
software da loro sviluppato come un loro effetto
personale (il famigerato SW mio) e non come
un componente da inserire e gestire nell’ambito
di un sistema complessivo.
PROMETEO
L’essenza del problema di SCM
Alcuni effetti di questo tipo di attitudine sono i seguenti:
I l codice è scarsamente leggibile.
Conseguentemente la documentazione è scarsa e poco aggiornata.
Conseguentemente un SW engineer può difficilmente modificare il SW scritto da altri.
A lla domanda “questo sistema funziona?” si risponde spesso “il mio SW si”.
A lla domanda “è stato eseguito il back-up dei sorgenti?” si risponde spesso “per il mio SW si”.
Normalmente il materiale di progetto è malamente classificato e mantenuto in un disordine estremo.
PROMETEO
Definizioni di SCM
PROGRAMMI (SORGENTI ED ESEGUIBILI)
PROCEDURE DI COMANDO
DOCUMENTI
AMBIENTI DI COLLAUDO
STRUTTURE DATI
REPORT (i.e. ,TEST REPORT)
SOFTWARE ENGINEERING
SOFTWARE CONFIGURATION
SOFTWARE CONFIGURATION SOFTWARE CONFIGURATION ITEM
PROMETEO
Definizioni di SCM Il SCM ha come area di intervento primaria il
controllo dei “change”. Esso si occupa anche
della identificazione dei SCI e delle varie
versioni del software, dell’audit della
configurazione software per assicurare che sia
stata sviluppata in modo appropriato, e del
reporting di tutte le modifiche eseguite.
PROMETEO
Le attività del SCM
• Identificazione dei SCI • Controllo dei “change” • Audit della configurazione (*) • Report sullo stato della
configurazione
(*) controllo del rispetto degli standard di SCM
PROMETEO
Lo standard ESA PSS-05-0
Software Configuration Management
AD/R
SR/R
SR
UR/R
AD
UR
SCMP
PROMETEO
Lo standard ESA PSS-05-0
Il flusso dei configuration item (CI)
LIBRERIA DI INTEGRAZ.
LIBRERIA DI SVILUPPO
DA VERIFICARE VERIFICATE DA CORREGGERE COLLAUDATI
MASTER LIBRARY
MODULI COLLAUDATI
VERSIONI VERIFICATE
RELEASE ESTERNE
PROMETEO
Lo standarad ESA PSS-05-0
Procedura di gestione dei change
1. Generazione del Software Problem Report (SPR).
2. Il Software Review Board passa il SPR
al tecnico competente per l’analisi. 3. Il Software Review Board esamina le
conclusioni dell’analisi e decide se autorizzare uno o più change.
4. Ogni change è specificata da un
Software Change Request (SCR). 5. Ogni change eseguita va documentata
con un Software Modification Report (SMR), a cui fa seguito l’aggiornamento della Master Library.
PROMETEO
Struttura del Software Configuration Management Plan
∗ Introduzione
- Scopo - Area di intervento - Definizioni e Acronimi - Riferimenti
∗ Gestione
- Organizzazione - Responsabilità di SCM - Controllo delle interfaccie (HW/SW) - Realizzazione del SCMP - Politiche, direttive e procedure
* Attività di SCM
- Identificazione della configurazione - Controllo della configurazione - Accounting dello stato della configurazione - Audit e review
∗ Tools, tecniche e metodologie
∗ Controllo dei fornitori
∗ Raccolta e classificazione delle registrazioni (gestione della documentazione di SCM) (IEEE STD 828/1983)
PROMETEO
Quando mettere gli SCI sotto controllo di configurazione può dipendere dalle esigenze specifiche di ogni singolo progetto. E’ tuttavia evidente che tutti gli SCI debbono essere sotto controllo di configurazione alla data di rilascio del prodotto al cliente, in quanto l’efficacia e l’efficienza delle attività di manutenzione sono fortemente influenzate dalla qualità del SCM.
PROMETEO
L’attività di manutenzione deve essere fortemente finalizzata a non ‘entropizzare’ il prodotto software. D’altra parte ciò è fortemente influenzato dai seguenti fattori:
a) qualità dell’architettura del sistema,
b) conoscenza del sistema da parte del manutentore software,
c) coerenza delle modifiche con la struttura intellettuale del sistema,
d) qualità del regression testing
e) efficace raccolta di dati metrici sulla qualità e di dati sui change eseguiti (SCM),
f) norme per la esecuzione dei change (SCM),
g) norme per la gestione delle release (SCM),
h) norme per la catalogazione e gestione dei SCI (SCM).
PROMETEO
Raccolta e gestione di dati metrici
sulla qualità del software Conta cosa può essere contato, misura cosa può essere misurato, e cosa non è misurabile rendilo misurabile. Galileo Galilei
PROMETEO
Modello USAF per la previsione della affidabilità del software
PROMETEO
F = A x D x S1 x S2
F : fault density per numero di LOC A : base fault density da precedenti esperienze (i. e., 0.0018 per applicazioni di controllo processi dell’USAF) D : moltiplicatore per ambiente di sviluppo S1 : moltiplicatore per metodologia
di sviluppo S2 : moltiplicatore per tecniche di codifica
PROMETEO
D : moltiplicatore per ambiente di sviluppo
viene usata una classificazione di Boehm
Ambiente D Note
Organic
Semi-detached
Embedded
.76
1
1.3
Piccoli gruppi che conoscono l’applicazione
Intermedio
SW contracted con vincoli stringenti
PROMETEO
S1 : moltiplicatore per metodologie di sviluppo S1 = SA x ST x SQ
PROMETEO
.9 < SA < 1.1 Sulla base del rigore di definizione input e di preprocessing e correzione automatica di errori sull’input Più del 90% dei requirement
ST di progetto sono esplicita- mente coperti dal SW design Discrepanze fra requirement SQ e design su numero di requirement inferiore al 50%
1
1.1
1
1.1
PROMETEO
S2 : moltiplicatore per tecniche di codifica S2 = SL x SM x SX x SR
PROMETEO
SL = SM = NM = u + w + x ; numero moduli u numero moduli con < 200 LOC w numero moduli con 200-3000 LOC x numero moduli con > 3000 LOC
+ 1.4
ALOC
SLOC
HLOC
SLOC H : high-level
S : source A : assembler
0.9u + w + 2x
NM
PROMETEO
SX = NM = a + b + c ; numero moduli a numero moduli con complessità ciclomatica > 20 b numero moduli con 7 < C.C. < 20 c numero moduli con C.C. < 7 SR
1.4a + b + .8c
NM
1.5
.75
1
più del 50% di moduli fuori coding standard
meno del 25% di moduli fuori standard
intermedio
PROMETEO
Conclusioni da modello USAF
I fattori esaminati sembrano avere un impatto rilevante. Ad esempio, su un’ applicazione di controllo processo di 50 KLOC i due casi estremi risultano i seguenti:
OTTIMO : 33 fault PESSIMO : 915 fault
PROMETEO
Ovviamente il modello USAF non dovrebbe
essere utilizzato ‘as is’, ma andrebbe
ritarato statisticamente sullo specifico
‘software lab’ cui si vuole applicarlo. Da
qui l’importanza del rilievo sistematico di
dati metrici.
PROMETEO
In ogni caso il modello USAF può fornire una indicazione qualitativa dell’impatto sulla ‘fault density’ dei vari fattori esaminati 1. Ambiente di sviluppo fino a +71% 2. Metodologie di sviluppo 2.1 Controllo input fino a +22% 2.2 Copertura requirement fino a +10% 2.3 Discrepanze requirement fino a +10% 3. Tecniche di codifica 3.1 Linguaggi h-l fino a +40% 3.2 Dimensione moduli fino a +122% 3.3 Complessità moduli fino a +75% 3.4 Standard di codifica fino a +100%
PROMETEO
Alcune esperienze HP
PROMETEO
Esempio 1 Rilievo dell’andamento mensile dei seguenti fattori:
- numero di difetti segnalati ma non diagnosticati - tempo medio di diagnosi - numero di difetti seri non risolti - tempo medio di ‘fix’ di un difetto serio ripartito per divisione della società.
PROMETEO
Il problema più complesso è la
interpretazione dei dati raccolti.
PROMETEO
Ad esempio in HP il numero di difetti seri non risolti è risultato sempre crescente nel tempo, ma ciò è dovuto al fatto che il volume dell’attività software è cresciuto più rapidamente dell’incremento di qualità del processo di produzione. Esigenza di normalizzazione dei dati.
PROMETEO
Un ulteriore esempio è il seguente: un
buon prodotto software installato in
molti siti può avere un tasso di difetti
segnalati più alto di un prodotto meno
buono ma installato in pochi siti.
PROMETEO
Un ulteriore fattore da considerare è
che le metriche di difetti sono molto
influenzate dalla classificazione dei
difetti e dalle modalità adottate per la
loro registrazione.
Inoltre per avere dati sufficienti è
necessaria una raccolta di almeno 3
anni.
PROMETEO
Classificazione degli errori Priorità 1 : errore che impedisce l’ottenimento di una funzione essenziale Priorità 2 : errore che influenza negativamente l’ottenimento di una funzione essenziale e per il quale non esistono soluzioni alternative Priorità 3 : errore che influenza negativamente l’ottenimento di una funzione essenziale ma per il quale esiste una ragionevole soluzione alternativa Priorità 4 : errore che crea solo un disturbo all’operatore Priorità 5 : altri errori. DOD - STD - 1679A
PROMETEO
Esempio 2
- Raccolta di dati di ‘fault’ classificati per categorie - Analisi di Pareto per identificare la/le categoria/e di maggior impatto - Analisi delle cause per migliorare il processo.
PROMETEO
Esempio 3
Una divisione HP aveva sviluppato un modello sul tempo necessario, in ore di collaudo, per rilevare e correggere gli errori. Sulla base di questo modello erano in grado di tracciare una previsione di ‘defect rate’ per una campagna di collaudo.
Difetti su 1000 ore di collaudo
WKn WK1 WK2 tempo
PROMETEO
In questo modo, fissando una condizione di ‘stop’ (i.e., 50 difetti su 1000 ore, ovvero 20 ore di collaudo senza difetti), era possibile determinare la durata prevista per la campagna di collaudo.
50
Difetti su 1000 ore di collaudo
WK10 tempo
PROMETEO
Ovviamente la campagna di collaudo era interrotta sulla base del ‘defect rate’ effettivo e non sulla base di quello previsto.
50
tempo
Difetti su 1000 ore di collaudo
WK12
PROMETEO
La scelta della condizione di arresto della campagna di collaudo è basata su considerazioni di questo tipo: Costo orario di collaudo x 20 > Costo di ‘fix’ post-release
PROMETEO
Preventivazione, pianificazione,
organizzazione e gestione delle attivita’ di collaudo
e manutenzione
E debbasi considerare, come non e’ cosa piu’ difficile a trattare, ne’ piu’ dubia a riuscire, ne’ piu’ pericolosa a maneggiare, che farsi capo ad introdurre nuovi ordini. Niccolo’ Machiavelli
PROMETEO
Preventivazione Il costo di collaudo normalmente e’ pari al 40% del costo di sviluppo. Un prodotto con alta esigenza di affidabilita’ puo’ pero’ avere costi di collaudo superiori. Il collaudo pero’ intercetta normalmente il 70% degli errori presenti, l’ispezione puo’ rimuoverne l’80-90% prima del collaudo, un buon processo invece previene gli errori.
PROMETEO
Preventivazione Il costo di manutenzione, nel ciclo di vita del prodotto, e’ normalmente molto piu’ alto del costo di sviluppo.
PROMETEO
Pianificazione L’attivita’ di collaudo va’ opportunamente pianificata mediante un SQAP e uno o piu’ STP correlati fra loro e con i piani delle attivita’ di sviluppo.
PROMETEO
Pianificazione E’ necessario eseguire un rilievo sistematico di metriche su ‘fault’ e attivita’ di manutenzione, per dimensionare correttamente, nelle varie fasi del ciclo di vita, le risorse di manutenzione.
PROMETEO
Pianificazione e Gestione I rilievi metrici costituiscono la base per le decisioni sui prodotti software, che debbono essere gestiti come cespiti patrimoniali.
analisi
mantengo
re-ingegnerizzo
muovo su altre piattaforme
sostituisco
dati metrici
PROMETEO
Organizzazione Gli assertori del TQM sono assolutamente contrari all’esistenza di gruppi di collaudo separati dai gruppi di progetto. I difetti vanno rimossi ‘in process’. Ogni sw engineer deve essere responsabile della qualita’ del suo prodotto, il management deve essere responsabile del ‘process improvement’. Si stima infatti che l’85% dei difetti siano derivanti dalla bassa qualita’ dei processi di produzione attuali.
PROMETEO
Organizzazione Una posizione piu’ consona allo stato corrente dei processi di produzione, puo’ essere la seguente:
a) lo stadio finale di ‘formal testing’ e’ eseguito da una unita’ organizzativa separata,
b) la maggioranza delle attivita’ di
collaudo sono demandate al gruppo di sviluppo, ma con ‘accounting’ delle ore lavorative su ‘budget’ separato e rigorosa documentazione dell’attivita’ di collaudo eseguita.
PROMETEO
Organizzazione E’ di vitale importanza dimensionare correttamente lo ‘staff’ di manutenzione, selezionando con cura le persone sulla base delle competenze richieste e fornendo un adeguato livello di ‘training’.
PROMETEO
Organizzazione L’esecuzione della manutenzione da parte dei gruppi di R & D, priva rapidamente l’azienda di una organizzazione di R & D.
2º
livello
1º
livello
campo
R & D Manutenzione
PROMETEO
Gestione Responsabilita’ gestionali, preventivi, consuntivi dovrebbero inquadrare il problema esaminando l’intero ciclo di vita del prodotto e non solo la fase di sviluppo.