ITAlian Software Testing Qualifications Board Syllabus Foundation. Versione 2011

Transcript

1 ITAlian Software Testing Qualifications Board Syllabus Foundation Versione 2011 DATI IDENTIFICATIVI CODICE DOCUMENTO DATA DI EMISSIONE STATO ITASTQB-FLSY /05/2011 REDATTA APPROVATA REDATTORI DATA M. SOGLIANI 10/04/2011 APPROVATORI DATA G. BAZZANA 01/05/2011 Associazione ITA-STQB Sede Legale e Amministrativa: Brescia Via Brozzoni 9 C.F P.I info@ita-stqb-org

2 STORIA DELLE MODIFICHE CHI DATA VERSIONE CONTENUTO Alessandro Collino, Marco Sogliani Marco Sogliani Gualtiero Bazzana Marco Sogliani 01 Giugno Mag Ott Mag Non applicabile in quanto si tratta della prima versione del documento 02 Il sillabo è stato allineato alla nuova versione ufficiale emessa da ISTQB 03 Apportate alcune modifiche minori per migliorare alcuni aspetti di traduzione 04 Il Sillabo è stato allineato alla nuova versione 2011 emessa da ISTQB Nota Copyright International Software Testing Qualifications Board (in seguito chiamato ISTQB ) ISTQB è un marchio registrato dell' International Software Testing Qualifications Board, Copyright 2011 gli autori per le modifiche 2011 (Thomas Müller (chair), Debra Friedenberg, and the ISTQB WG Foundation Level). Copyright 2010 gli autori per le modifiche 2010 (Thomas Müller (chair), Armin Beer, Martin Klonk, Rahul Verma). Copyright 2007 gli autori per le modifiche 2007 (Thomas Müller (chair), Dorothy Graham, Debra Friedenberg e Erik van Veendendal) Copyright 2005, gli autori (Thomas Müller (chair), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson e Erik van Veendendal). Tutti i diritti riservati. Gli autori stanno trasferendo il copyright alla International Software Testing Qualifications Board (ISTQB ). Gli autori (come attuali possessori del copyright) e ISTQB (come futuro possessore del copyright) si sono accordati con riferimento alle seguenti condizioni d uso: 1) Ogni persona o azienda di formazione può usare questo syllabus come base per un corso di formazione se gli autori e ISTQB sono riconosciuti come la fonte e i detentori del copyright del syllabus e a condizione che ogni annuncio di corso di formazione possa menzionare il syllabus solo dopo la presentazione per l accreditamento ufficiale del materiale formativo ad una National Board riconosciuta da ISTQB. 2) Ogni persona o gruppo di persone possono usare questo syllabus come base per articoli, libri, o altre pubblicazioni derivate se gli autori e ISTQB sono riconosciuti come la fonte e i detentori del copyright del syllabus. 3) Ogni National Board riconosciuta da ISTQB può tradurre questo syllabus e può autorizzare l utilizzo del syllabus (o della traduzione) a terzi. Pagina 2 di 77

3 INDICE DEI CONTENUTI Storico delle modifiche del SILLABO Originale in Lingua Inglese... 9 Prefazione Ringraziamenti Introduzione a questo syllabus Scopo del presente documento Il Certified Tester Foundation Level nel Software Testing Obiettivi dell apprendimento/livello di conoscenza L esame Accreditamento Livello di dettaglio Come è organizzato questo syllabus Fondamenti del testing (K2) Obiettivi di apprendimento per i fondamenti del testing Perché il testing è necessario (K2) Termini Contesto dei sistemi software (K1) Cause dei difetti del software (K2) Ruolo del testing nello sviluppo, manutenzione e funzionamento del software (K2) Testing e qualità (K2) Quando il testing può essere considerato sufficiente? (K2) Che cos è il testing? (K2) Termini Contesto Principi generali del testing (K2) Termini Principi Fondamenti del processo di test (K1) Termini Contesto Pianificazione e controllo del test (K1) Analisi e progettazione del test (K1) Implementazione ed esecuzione del test (K1) Pagina 3 di 77

4 Valutazione dei criteri di uscita e report dei risultati (K1) Attività di chiusura del test (K1) La psicologia del testing (K2) Termini Contesto Codice Etico (K2) Riferimenti Il testing durante il ciclo di vita del software (K2) Obiettivi di apprendimento per il testing durante il ciclo di vita del software Modelli di sviluppo del software (K2) Termini Contesto Modello a V (modello di sviluppo sequenziale) (K2) Modelli di sviluppo iterativo-incrementale (K2) Il testing in un modello di ciclo di vita (K2) Livelli di test (K2) Termini Contesto Testing di componente (K2) Testing di integrazione (K2) Testing di sistema (K2) Testing di accettazione (K2) Tipi di test (K2) Termini Contesto Testing di funzioni (testing funzionale) (K2) Testing di caratteristiche software non funzionali (testing non funzionale) (K2) Testing dell architettura/struttura del software (testing strutturale) (K2) Testing legato a modifiche (retesting e regression testing) (K2) Testing di manutenzione (K2) Termini Contesto Riferimenti Tecniche statiche (K2) Pagina 4 di 77

5 Obiettivi di apprendimento per tecniche statiche Tecniche statiche ed il processo di testing (K2) Termini Contesto Processo di revisione (K2) Termini Contesto Fasi di una revisione formale (K1) Ruoli e responsabilità (K1) Tipi di revisioni (K2) Fattori di successo delle revisioni (K2) Analisi statica con strumenti (K2) Termini Contesto Riferimenti Tecniche di test design (K3) Obiettivi di apprendimento per le tecniche di test design (Progettazione dei Test) Il processo di sviluppo di test (K2) Termini Contesto Categorie delle tecniche di test design (K2) Termini Contesto Tecniche basate sulle specifiche o black-box (K3) Termini Partizionamento in classi di equivalenza (K3) Analisi ai valori limite (K3) Testing basato su tabelle delle decisioni (K3) Testing basato su diagrammi di transizioni tra stati (K3) Testing basato su use cases (K2) Tecniche basate sulla struttura o white-box (K3) Termini Contesto Testing delle istruzioni e copertura delle istruzioni (K3) Pagina 5 di 77

6 Testing delle decisioni e copertura delle decisioni (K3) Altre tecniche basata sulla struttura (K1) Tecniche basate sull esperienza (K2) Termini Contesto Scelta delle tecniche di testing (K2) Riferimenti Gestione del testing (K3) Obiettivi di apprendimento per la gestione del testing Organizzazione del testing (K2) Termini Organizzazione ed indipendenza del testing (K2) Compiti del test leader e del tester (K1) Stima e pianificazione del testing (K2) Termini Pianificazione del testing (K2) Attività di pianificazione del testing (K2) Criteri di ingresso (K2) Criteri di uscita (K2) Stima del testing (K2) Strategie di testing, approcci di testing (K2) Controllo e monitoraggio nell avanzamento del testing (K2) Termini Monitoraggio nell avanzamento del testing (K1) Reportistica del testing (K2) Controllo del testing (K2) Gestione della configurazione (K2) Termini Contesto Rischio e testing (K2) Termini Contesto Rischi di progetto (K2) Rischi di prodotto (K2) Pagina 6 di 77

7 5.6. Gestione degli incidenti (K3) Riferimenti Supporto di strumenti per il testing (K2) Obiettivi di apprendimento per il supporto di strumenti per il testing Tipi di strumenti di testing (K2) Termini Capire il significato e lo scopo di uno strumento di aiuto al testing (K2) Classificazione degli strumenti di testing (K2) Strumenti di supporto per la gestione del testing e dei test (K1) Strumenti di supporto per il testing statico (K1) Strumenti di supporto per la specifica dei test (K1) Strumenti di supporto per l esecuzione ed il logging dei test (K1) Strumenti di supporto per prestazioni e monitoraggio (K1) Strumenti di supporto per specifiche esigenze di testing (K1) Uso efficace degli strumenti: benefici e rischi potenziali (K2) Potenziali benefici e rischi di strumenti di supporto per il testing (K2) Considerazioni speciali per alcuni tipi di strumenti (K1) Introduzione di uno strumento all interno di un organizzazione (K1) Termini Contesto Riferimenti Riferimenti Standard Libri Appendice A Informazioni relative al syllabus Storia di questo documento Obiettivi del Certificato di qualifica Foundation Obiettivi della qualifica internazionale Requisiti di ingresso per la qualifica ISTQB Contesto e storia del Certificato Foundation nel Software Testing Appendice B Obiettivi di apprendimento / livello di conoscenza Livello 1: Ricordare (K1) Livello 2: Comprendere (K2) Livello 3: Applicare (K3) Pagina 7 di 77

8 Livello 4: Analizzare (K4) Appendice C Regole applicate a ISTQB Syllabus Foundation Regole generali Contenuto attuale Obiettivi di apprendimento Struttura complessiva Appendice D Note ai fornitori della formazione Appendice E - Release Notes Syllabus Appendice F - Release Notes Syllabus Appendice G - Release Notes Syllabus Indice Dei termini Pagina 8 di 77

9 STORICO DELLE MODIFICHE DEL SILLABO ORIGINALE IN LINGUA INGLESE Versione Data Note ISTQB 2011 ISTQB 2010 ISTQB 2007 ISTQB 2005 ASQF V2.2 ISEB V Aprile Marzo Maggio Luglio-2005 Luglio Febbraio-1999 Certified Tester Foundation Level Syllabus Maintenance Release see Appendix E Release Notes Syllabus 2011 Certified Tester Foundation Level Syllabus Maintenance Release see Appendix E Release Notes Syllabus 2010 Certified Tester Foundation Level Syllabus Maintenance Release vedi Appendice E - Release Notes Syllabus 2007 Certified Tester Foundation Level Syllabus ASQF Syllabus Foundation Level Version 2.2 Lehrplan Grundlagen des Softwaretestens ISEB Software Testing Foundation Syllabus V Febbraio 1999 Pagina 9 di 77

10 PREFAZIONE Nel compilare questo glossario il gruppo di lavoro ha cercato le idee e i commenti di uno spettro di opinioni il più largo possibile nei settori e nelle organizzazioni in campo industriale e del commercio e nelle agenzie governative, con l'obiettivo di produrre uno standard internazionale per il testing che potesse essere accettato nel campo più ampio possibile. Sarà raro, se non impossibile, trovare un accordo unanime nella compilazione di un documento di questa natura. I contributi ricevuti per questo glossario Definizioni RINGRAZIAMENTI International Software Testing Qualifications Board Working Group Foundation Level (Edition 2011): Thomas Müller (chair), Debra Friedenberg. Il core team ringrazia il gruppo di revisori (Dan Almog, Armin Beer, Rex Black, Julie Gardiner, Judy McKay, Tuula Pääkkönen, Eric Riou du Cosquier Hans Schaefer, Stephanie Ulrich, Erik van Veenendaal) e tutti i Board nazionali per i suggerimenti alla versione attuale del syllabus. International Software Testing Qualifications Board Working Group Foundation Level (Edition 2010): Thomas Müller (chair), Rahul Verma, Martin Klonk and Armin Beer. Il core team rinfgrazia il gruppo di revisori (Rex Black, Mette Bruhn-Pederson, Debra Friedenberg, Klaus Olsen, Tuula Pääkkönen, Meile Posthuma, Hans Schaefer, Stephanie Ulrich, Pete Williams, Erik van Veendendaal) e tutti Board nazionali per i suggerimenti alla versione attuale del syllabus. International Software Testing Qualifications Board Working Group Foundation Level (Edition 2007): Thomas Müller (chair), Dorothy Graham, Debra Friedenberg, ed Erik van Veendendal. Il core team ringrazia il review team (Hans Schaefer, Stephanie Ulrich, Meile Posthuma, Anders Pettersson, and Wonil Kwon) e tutte le boards nazionali per tutti i suggerimenti alla versione attuale del syllabus. International Software Testing Qualifications Board Working Group Foundation Level (Edition 2005): Thomas Müller (chair), Rex Black, Sigrid Eldh, Dorothy Graham, Klaus Olsen, Maaret Pyhäjärvi, Geoff Thompson and Erik van Veendendal. Il core team ringrazia il review team e tutte le board nazionali per i suggerimenti all attuale syllabus. Pagina 10 di 77

11 INTRODUZIONE A QUESTO SYLLABUS SCOPO DEL PRESENTE DOCUMENTO Questo syllabus costituisce la base per International Software Testing Qualification al livello Foundation. International Software Testing Qualifications Board (ISTQB ) fornisce questo syllabus agli enti di certificazione nazionali per accreditare i fornitori della formazione e per derivare da esso delle domande d esame nella lingua locale. I fornitori della formazione produrranno i corsi e determineranno i metodi di insegnamento più appropriati per l accreditamento: il syllabus aiuterà i candidati nella loro preparazione agli esami. Informazioni sulla storia e su informazioni relative al syllabus sono riportate in Appendice A. IL CERTIFIED TESTER FOUNDATION LEVEL NEL SOFTWARE TESTING Il livello di qualificazione Foundation è rivolto a chiunque sia coinvolto nel software testing. Questo include persone che ricoprono ruoli di testers, analisti di testing, ingegneri del testing, managers di testing, testers a livello di accettazione utente e sviluppatori software. Questo livello di qualifica denominato appunto Foundation è anche appropriato per chiunque voglia avere una comprensione dei fondamenti del software testing, come managers di progetto, di sviluppo software, analisti e direttori di aziende IT. I possessori del Foundation Certificate saranno in grado di conseguire un livello di qualifica superiore nelle competenze di software testing. OBIETTIVI DELL APPRENDIMENTO/LIVELLO DI CONOSCENZA Per ogni sezione di questo syllabus sono identificati i livelli cognitivi come segue: o K1: ricordare termini, riconoscere, richiamare definizioni; o K2: comprendere; o K3: applicare; o K4: analizzare Ulteriori dettagli ed esempi di obiettivi di apprendimento sono descritti nell Appendice B. Tutti i termini elencati sotto Termini immediatamente sotto il titolo del capitolo devono essere ricordati (K1), anche se non sono menzionati esplicitamente negli obiettivi di apprendimento. L ESAME L esame per il conseguimento del Foundation Certificate sarà basato su questo syllabus. Le risposte alle domande degli esami possono richiedere l utilizzo di materiale basato su più di una sezione di questo syllabus. Tutte le sezioni del syllabus sono oggetto d esame. Il formato dell esame è a scelta multipla. Gli esami possono essere presi come parte di un corso di formazione accreditato o in modo indipendente (ad esempio, presso un centro d esame). Pagina 11 di 77

12 ACCREDITAMENTO I fornitori della formazione il cui materiale del corso segue questo syllabus possono essere accreditati da un national board riconosciuto da ISTQB. Le linee guida per l accreditamento devono essere ottenute dal board o dall ente che effettua l accreditamento. Un corso accreditato viene riconosciuto come conforme a questo syllabus ed è consentito avere un esame ISTQB come parte del corso. Ulteriori informazioni sono descritte nell Appendice D. LIVELLO DI DETTAGLIO Il livello di dettaglio di questo syllabus consente una formazione ed un esame coerente a livello internazionale. Per raggiungere questo obiettivo, questo syllabus consiste di: o Un indicazione di obiettivi generali che descrivono i propositi del livello Foundation. o Un elenco di informazioni per l insegnamento, che ne include una descrizione, e riferimenti a fonti aggiuntive se necessario. o Un apprendimento di obiettivi per ogni area di conoscenza, che descriva il risultato cognitivo e l atteggiamento mentale che si intendono ottenere. o Una lista di termini che lo studente deve ricordare ed avere compreso. o Una descrizione dei concetti chiave per l insegnamento, che comprenda fonti come letteratura universalmente accettata o standards. Il contenuto del syllabus non è una descrizione dell intera area di conoscenza del software testing; riflette il livello di dettaglio che deve essere coperto dai corsi per il livello Foundation. COME È ORGANIZZATO QUESTO SYLLABUS Il syllabus è articolato in sei capitoli principali. L intestazione di livello più alto mostra i livelli degli obiettivi di apprendimento che sono coperti dal capitolo e specifica il tempo per capitolo. Per esempio: 2. Il testing durante il ciclo di vita del software (K2) 115 minuti mostra che il capitolo 2 ha gli obiettivi di apprendimento di K1 (assunto sempre in quanto viene associato al capitolo un livello più alto) e K2 (ma non K3), ed è organizzato per occupare 115 minuti nell insegnamento del materiale di quel capitolo. In ogni singolo capitolo ci sono un certo numero di sezioni. Per ogni sezione sono specificati anche gli obiettivi di apprendimento e la quantità di tempo richiesta. Le sottosezioni che non hanno un tempo assegnato sono incluse nel tempo di quella sezione. Pagina 12 di 77

13 1. FONDAMENTI DEL TESTING (K2) 155 minuti OBIETTIVI DI APPRENDIMENTO PER I FONDAMENTI DEL TESTING Gli obiettivi identificano le competenze che vengono acquisite seguendo il completamento di ogni singolo modulo. 1.1 Perché il testing è necessario? (K2) LO Descrivere, con esempi, il modo nel quale un difetto nel software può causare danni a persone, all ambiente o ad un azienda.(k2) LO Distinguere tra la causa scatenante di un difetto ed i suoi effetti. (K2) LO Fornire delle ragioni del perché il testing è necessario attraverso esempi. (K2) LO Descrivere perché il testing è parte del processo di garanzia di qualità e fornire esempi di come il testing contribuisce ad ottenere una più alta qualità. (K2) LO Ricordare i termini errore, difetto, fault (guasto), failure (fallimento) e i corrispondenti termini mistake (sbaglio) e bug (baco), utilizzando esempi. (K2) 1.2 Che cos è il testing? (K2) LO Ricordare gli obiettivi comuni del testing. (K1) LO Fornire esempi degli obiettivi del testing nelle diverse fasi del Ciclo di Vita del Software (K2) LO Differenziare il testing dal debugging (K2) 1.3 Principi generali del testing (K2) LO Spiegare i fondamentali principi del testing. (K2) 1.4 Fondamenti del processo di test (K1) LO Ricordare le attività di test fondamentali, dalla pianificazione alla chiusura delle attività di test e i principali compiti di ogni singola attività di test. (K1) 1.5 La psicologia del testing (K2) LO Richiamare i fattori psicologici che influenzano il successo del testing (K1) LO Confrontare i punti di vista di un tester e di uno sviluppatore. (K2) Pagina 13 di 77

14 1.1. PERCHÉ IL TESTING È NECESSARIO (K2) 20 minuti Termini Bug (baco), difetto, errore, failure (fallimento), fault (guasto), sbaglio, qualità, rischio Contesto dei sistemi software (K1) L interazione con Sistemi Software occupa una parte sempre crescente della nostra vita, dalle applicazioni orientate al business (ad esempio, i sistemi bancari), ai prodotti di consumo (ad esempio, le automobili). Molte persone hanno avuto a che fare direttamente con esperienze nelle quali il software non si è comportato come esse si attendevano. Software che non opera correttamente può provocare molti problemi, compresi la perdita di denaro, di tempo, di reputazione negli affari e può anche causare infortuni o morte Cause dei difetti del software (K2) Un essere umano può commettere un errore (sbaglio), il quale produce un difetto (fault, bug) nel codice del programma oppure in un documento. Se il codice difettoso viene eseguito, il sistema può fallire nel fare quello che deve fare (o può fare qualcosa che non deve), causando un esito negativo ( failure ). Difetti nel software, nei sistemi, nei documenti possono provocare failures, ma non tutti i difetti li possono provocare. I difetti nascono perché l essere umano non è infallibile e diventa maggiormente incline agli errori nelle condizioni in cui può essere costretto ad operare: mancanza di tempo, complessità del codice, complessità dell infrastruttura, cambiamento delle tecnologie e/o a causa delle molte interazioni nel sistema. Esiti negativi possono essere causati anche da condizioni ambientali: ad esempio radiazioni, magnetismo, campi elettrici e inquinamento possono causare guasti nel firmware o influenzare l esecuzione del software andando a modificare condizioni hardware Ruolo del testing nello sviluppo, manutenzione e funzionamento del software (K2) Un rigoroso testing dei sistemi e della documentazione di qualità può aiutare a ridurre il rischio di problemi che si possono verificare durante il funzionamento e a contribuire alla qualità del sistema software, se i difetti trovati vengono corretti, prima che il sistema venga rilasciato per il suo utilizzo operativo. Al testing del software può anche essere richiesto di rispettare requisiti legali, contrattuali, oppure standard industriali specifici del settore Testing e qualità (K2) Con l aiuto del testing, è possibile misurare la qualità del software in termini di difetti trovati, sia per requisiti funzionali che non funzionali e caratteristiche (ad esempio, affidabilità, usabilità, efficienza, manutenibilità e portabilità). Per maggiori informazioni sul testing non funzionale, si veda il Capitolo 2; per maggiori informazioni sulle caratteristiche del software si faccia riferimento a: Software Engineering Software Product Quality (ISO 9126). Il testing può dare confidenza sulla qualità del software se trova alcuni difetti o nessuno. Un test progettato correttamente che viene eseguito con successo riduce il livello di rischio complessivo di un Pagina 14 di 77

15 sistema. Quando il testing trova difetti, la qualità del sistema software aumenta a seguito della correzione dei difetti. Diverse lezioni devono essere imparate da precedenti progetti. Attraverso la comprensione delle cause di difetti trovate in altri progetti, i processi possono essere migliorati, e questo a sua volta deve prevenire il riverificarsi di questi difetti e, di conseguenza, migliorare la qualità dei sistemi futuri. Questo è un aspetto di garanzia di qualità. Il testing dovrebbe essere integrato come una delle attività di garanzia di qualità (quindi accanto allo sviluppo di standard, di formazione e analisi dei difetti) Quando il testing può essere considerato sufficiente? (K2) La decisione di quanto testing è necessario, deve tenere conto del livello di rischio, includendo rischi tecnici, di business, di progetto, e vincoli di progetto come tempo e budget (il rischio è discusso successivamente). Il testing deve fornire sufficienti informazioni agli stakeholders per prendere decisioni consapevoli sul rilascio del software o del sistema sotto testing, per la successiva fase di sviluppo o la consegna ai clienti CHE COS È IL TESTING? (K2) 30 minuti Termini Debugging, requisito, review (revisione), test case (caso di test), testing, obiettivo del test Contesto Una percezione molto diffusa sul testing è che esso consista solo nell eseguire test e quindi nell esecuzione di software. Questa è solo una parte del testing; vi sono diverse altre attività di testing. Le attività di test sono presenti sia prima che dopo l esecuzione di test: attività come la pianificazione e il controllo, la scelta delle condizioni di test, la progettazione dei test cases e del controllo dei risultati, la valutazione dei criteri di uscita, il report sul processo di testing e sul sistema sotto test e la finalizzazione o le attività di chiusura dopo che una fase di test è stata completata. Il testing include anche la revisione dei documenti (compreso il codice sorgente) e la conduzione di attività di analisi statica. Sia il testing dinamico sia il testing statico possono essere usati con l intento di perseguire obiettivi simili e forniranno informazioni con lo scopo di migliorare sia il sistema che deve essere testato, sia i processi di sviluppo e del testing stesso. Ci possono essere differenti obiettivi dei test: o trovare difetti; o acquisire confidenza circa il livello di qualità e ottenere opportune informazioni; o prevenire i difetti. L impegnativo processo di dedicarsi alla progettazione dei test nelle fasi iniziali del ciclo di vita (verificando le fondamenta di tali test attraverso la loro progettazione) può aiutare a prevenire difetti prima che essi vengano introdotti nel codice. Anche revisioni di documenti (ad esempio dei requisiti) aiutano a prevenire difetti che compaiono nel codice. Pagina 15 di 77

16 Differenti punti di vista del testing tengono conto di diversi obiettivi. Per esempio, in diverse fasi di testing (ad esempio, testing di componente, testing di integrazione e testing di sistema), il principale obiettivo può essere quello di causare tanti più esiti negativi (failure) possibili, così che i difetti del software possano essere identificati e quindi corretti. Nel testing di accettazione, l obiettivo principale può essere di confermare che il sistema si comporti come atteso, per acquisire confidenza sul fatto che esso soddisfi i propri requisiti. In alcuni casi il principale obiettivo del testing può essere di valutare la qualità del software (senza l intenzione di correggere difetti), per fornire informazioni alle parti interessate del rischio di rilasciare il sistema in un certo momento. Per testing di manutenzione spesso si intende quel testing mirato a verificare che nessun nuovo difetto sia stato introdotto durante lo sviluppo delle correzioni. Durante il testing operazionale, il principale obiettivo può essere di valutare caratteristiche del sistema come affidabilità o disponibilità. Il debugging e il testing sono attività differenti. Il testing può mettere in evidenza degli esiti negativi (failures) causate da difetti. Il debugging è l attività di sviluppo che identifica la causa di un difetto, corregge il codice e controlla che il difetto sia stato risolto in modo corretto. Il successivo testing confermativo eseguito da un tester assicura che la correzione effettivamente risolva l esito negativo. La responsabilità per tali attività è molto differente e conseguentemente i testers fanno testing, gli sviluppatori fanno debug. Il processo di testing e le relative attività sono spiegate nella sezione PRINCIPI GENERALI DEL TESTING (K2) 35 minuti Termini Testing esaustivo Principi Un certo numero di principi sul testing sono stati suggeriti negli ultimi 40 anni e offrono linee guida generali per tutto il testing. Principio 1 Il testing mostra la presenza di difetti Il testing può mostrare la presenza di difetti, ma non può provarne l assenza. Il testing riduce la probabilità di difetti non scoperti ancora presenti nel software, ma anche se nessun difetto viene trovato, questa non è una prova di correttezza, ovvero di assenza di difetti. Principio 2 Il testing esaustivo.è impossibile Il testing esaustivo (ovvero di tute le combinazioni di dati in ingresso e di precondizioni) non è fattibile, tranne che per casi estremamente semplici. Quindi invece di concentrarsi sul testing esaustivo bisognerebbe focalizzare gli sforzi di testing sulle analisi dei rischi e delle priorità. Principio 3 Anticipare il testing il prima possibile Per individuare i difetti anticipatamente, le attività di testing devono partire il prima possibile nel ciclo di vita del software o del sistema e devono essere focalizzate con obiettivi ben definiti. Principio 4 Clustering dei difetti Pagina 16 di 77

17 Lo sforzo del testing deve essere indirizzato proporzionalmente alla densità dei difetti (attesa o misurata a posteriori) di ogni modulo. Un piccolo numero di moduli contiene normalmente la maggior parte dei difetti scoperti durante il testing di pre-rilascio, o sono responsabili di molti esiti negativi operativi (ovvero i difetti tendono a formare degli agglomerati, detti appunto cluster, concentrandosi, soprattutto nelle prime fasi di sviluppo, in alcuni moduli). Principio 5 Paradosso pesticida Se gli stessi test sono ripetuti più e più volte, presumibilmente lo stesso insieme di test cases non troverà nessun nuovo difetto. Per superare questo paradosso pesticida, i casi di test necessitano di essere riveduti e corretti, e nuovi test necessitano di essere riscritti per stimolare differenti parti del software e del sistema e per poter potenzialmente trovare più difetti. Principio 6 Il testing è dipendente dal contesto Il testing viene eseguito diversamente in contesti differenti. Per esempio, un software safety-critical viene testato in modo differente da un sito di commercio elettronico. Principio 7 Il luogo comune dell assenza di errori Trovare e correggere difetti non è sufficiente se il sistema sviluppato è inutilizzabile e non soddisfa le necessità e le aspettative dell utente. L assenza di errori è una falsa aspettativa. Un tester può solo dire, al limite, che non può trovare altri errori in un software, ma non che quel software non contenga errori. Questo sempre in base al Principio FONDAMENTI DEL PROCESSO DI TEST (K1) 35 minuti Termini Testing confermativo, retesting, criterio di uscita, segnalazione, testing di regressione, basi del test, test condition (condizione di test), copertura del test, dati di test esecuzione del test, test log, test plan (piano di test), test procedure (procedura di test), politica di test, strategia di test, test suite (insieme di test), test summary report (report riassuntivo del test), testware Contesto La parte più visibile del testing è quella relativa all esecuzione dei test. Tuttavia per essere efficaci ed efficienti, i piani di test devono includere anche il tempo che dovrà essere speso nella pianificazione dei test, nella progettazione dei test cases, nella preparazione per l esecuzione e nella valutazione dei risultati. I fondamenti del processo di test consistono delle seguenti attività principali: o pianificazione e controllo; o analisi e progettazione; o implementazione ed esecuzione; o valutazione dei criteri di uscita e report dei risultati; o attività di conclusione dei test. Benché queste attività siano logicamente sequenziali, nel processo descritto esse possono sovrapporsi o svolgersi contemporaneamente. Pagina 17 di 77

18 Pianificazione e controllo del test (K1) La pianificazione del test comprende la definizione degli obiettivi del testing e le specifiche delle attività di test che consentano di raggiungere i suoi obiettivi e quindi soddisfare la sua mission. Il controllo del test è la fase continuativa di confronto tra la pianificazione e lo stato di avanzamento, che consiste nel documentare lo stato attuale evidenziando deviazioni rispetto a quanto pianificato. Questa attività include la messa in atto delle contromisure atte a fare rispettare la mission e gli obiettivi del progetto: il controllo implica che il testing debba essere monitorato lungo tutto l arco del progetto. La pianificazione del test tiene a sua volta conto dei riscontri delle attività di monitoraggio e controllo. I compiti da svolgere nelle attività di pianificazione e controllo sono definiti nel Capitolo 5 di questo syllabus Analisi e progettazione del test (K1) L analisi e la progettazione del test è l attività nella quale gli obiettivi vengono trasformati in opportune test conditions e test cases. L analisi e la progettazione consiste dei seguenti compiti principali: o Revisione delle basi del test (come requisiti, architettura, progettazione, interfacce). o Valutazione della testabilità delle basi del test e degli oggetti del test. o Identificazione e assegnazione delle priorità delle test conditions basata sull analisi delle unità di test, delle specifiche, del comportamento e della struttura del software. o Progettazione e assegnazione delle priorità dei test cases. o Identificazione dei dati di test necessari per supportare le test conditions e i test cases. o Progettazione dell ambiente di test e identificazione di ogni elemento dell infrastruttura richiesta e degli strumenti di supporto all attività Implementazione ed esecuzione del test (K1) L implementazione e l esecuzione sono le attività nelle quali le test procedures (e gli eventuali scripts) vengono specificate combinando i test cases in un particolare ordine ed includendo ogni altra informazione necessaria per l esecuzione: l ambiente di test viene allestito e configurato ed i test cases vengono eseguiti. L implementazione e l esecuzione consistono dei seguenti compiti principali: o Sviluppo, implementazione e definizione delle priorità dei test cases. o Sviluppo e definizione delle priorità delle test procedures, creando i dati di test, preparando (eventualmente) i necessari corredi (test harness) e scrivendo degli scripts di test automatizzati. o Creazione di test suites dalle test procedures per una efficiente esecuzione. o Verifica che l ambiente di test sia stato preparato e configurato correttamente. o Esecuzione delle test procedures sia manualmente sia usando degli strumenti di esecuzione, in accordo con la sequenza pianificata. o Salvataggio in opportuni log, dell esito dell esecuzione dei test cases e registrazione degli identificativi e delle versioni dei software sotto test, degli strumenti di test e del testware. o Confronto dei risultati effettivi con i risultati attesi. o Indicazione delle discrepanze sotto forma di incidenti e loro analisi finalizzata a stabilire la loro causa (ad esempio, un difetto nel codice, nei dati di test, nel documento di test, od un errore nel modo in cui il test è stato eseguito ecc). o Ripetizione delle attività di test come risultato delle azioni adottate per ogni discrepanza. Per esempio, ri-esecuzione di un test precedentemente fallito con lo scopo di convalidare una Pagina 18 di 77

19 correzione (testing confermativo), esecuzione di un test valido e/o (ri-)esecuzione di test con lo scopo di assicurare che non siano stati introdotti difetti in parti di software non modificate o che la correzione di difetti non abbia scoperto altri difetti (testing di regressione) Valutazione dei criteri di uscita e report dei risultati (K1) La valutazione dei criteri di uscita è l attività nella quale l esecuzione di test è valutata rispetto agli obiettivi definiti. Questa attività deve essere svolta per ogni livello di test. La valutazione dei criteri di uscita consiste dei seguenti compiti principali: o Controllo dei test logs rispetto ai criteri di uscita specificati nella fase di pianificazione. o Valutazione della necessità dell introduzione di nuovi test o della modifica dei criteri di uscita inizialmente scelti. o Preparazione di un report riassuntivo dei test per le parti interessate (stakeholders) Attività di chiusura del test (K1) Le attività di conclusione dei test raccolgono i dati prodotti dalle attività di test completate per consolidarne l esperienza, il testware, i risultati e i dati quantitativi. Le attività di chiusura del test sono svolte: quando un sistema software viene rilasciato, un progetto di test viene completato (o cancellato), una milestone è stata raggiunta od un rilascio di manutenzione è stata completato. Le attività di conclusione dei test consistono dei seguenti compiti principali: o Controllo di quali consegne pianificate sono state effettuate. o Chiusura dei report degli incidenti o apertura delle segnalazioni di modifica per ogni incidente che rimane aperto. o Documentazione di accettazione del sistema. o Finalizzazione ed archiviazione del testware, dell ambiente di test e dell infrastruttura di test per un successivo riuso. o Consegna del testware alla organizzazione di manutenzione. o Analisi delle esperienze apprese da utilizzare per modifiche a futuri progetti. o Utilizzo delle informazioni raccolte per il miglioramento della maturità dei processi du testing LA PSICOLOGIA DEL TESTING (K2) 35 minuti Termini Error guessing (congetture sugli errori), indipendenza Contesto L approccio mentale da usare durante il testing e le fasi di revisione è differente da quello usato durante lo sviluppo del software. Col corretto atteggiamento mentale anche gli sviluppatori sono in grado di testare il loro proprio codice, ma l assegnazione di questa attività ad un tester viene tipicamente fatta per aumentare lo sforzo di focalizzazione e fornire ulteriori benefici, come una visione indipendente (e quindi senza inconsci condizionamenti) da parte di risorse professionali e dotate di una specifica formazione nell ambito del testing. Il testing indipendente può essere effettuato ad ogni livello di testing. Un certo grado di indipendenza (che eviti il condizionamento dell autore) è spesso più efficace nella rilevazioni di difetti e di esiti negativi (failures). L indipendenza non è, comunque, un sostituto della Pagina 19 di 77

20 dimestichezza col software e anche gli sviluppatori possono trovare in modo efficiente molti difetti nel loro codice. Possono essere definiti diversi livelli di indipendenza: o Test progettati dalla persona (o dalle persone) che hanno scritto il software sotto test (basso livello di indipendenza). o Test progettati da una persona (o da delle persone) diversa da chi ha scritto il software (ad esempio, da quella parte del team di sviluppo che non ha scritto quella parte di software). o Test progettati da una o più persone di un gruppo organizzativo differente (ad esempio, da un team di test indipendente) o da specialisti di testing. o Test progettati da una o più persone di un ente o di un azienda diversa (ad esempio, in outsourcing o certificazione da parte di un ente esterno). Le persone e i progetti sono guidati da obiettivi. Le persone tendono ad allineare i loro piani con gli obiettivi determinati dal management o da altri stakeholders, per esempio, per trovare difetti o per confermare che il software funzioni. Per questo è importante definire chiaramente gli obiettivi del testing. L identificazione di esiti negativi (failures) durante il testing può essere percepita come una critica nei confronti del prodotto e del suo autore. Il testing viene, per questo motivo, visto spesso come una attività distruttiva, benché sia molto costruttiva nella gestione dei rischi del prodotto. La ricerca di esiti negativi (failures) in un sistema, richiede curiosità, pessimismo costruttivo, occhio critico, attenzione ai dettagli, una buona comunicazione col team di sviluppo ed esperienza sulla quale basare le congetture sugli errori ( error guessing ). Se errori, difetti o esiti negativi (failures) vengono comunicati in un modo costruttivo, si possono evitare cattivi rapporti tra testers e analisti, progettisti e sviluppatori. Ciò è vero sia per le revisioni che per il testing. Il tester e il test leader hanno bisogno di buone capacità interpersonali per comunicare in modo costruttivo le informazioni riguardanti i difetti, i progressi ed i rischi. Le informazioni sui difetti possono aiutare l autore del software o di documenti a migliorare le proprie capacità. Difetti trovati e corretti durante il testing faranno risparmiare tempo e denaro in futuro e ridurre i rischi. Problemi di comunicazione possono particolarmente verificarsi se i testers sono visti solo come messaggeri di notizie indesiderate sui difetti. Comunque, ci sono diversi modi per migliorare la comunicazione e le relazioni tra i testers e le altre persone coinvolte: o Iniziare con un atteggiamento di collaborazione piuttosto che di disputa, ricordando ad ognuno che l obiettivo comune da raggiungere è sempre una migliore qualità dei sistemi. o Comunicare quanto scoperto sul prodotto in un modo neutrale, focalizzandosi sui fatti e sulle evidenze senza nessun atteggiamento di critica nei confronti della persona che ha sviluppato quel prodotto; tipicamente, scrivere il report sull eventuale problema riscontrato in modo oggettivo e basato sui fatti. o Provare a capire come le persone percepiscono l atteggiamento del tester e perché esse reagiscono in un certo modo. o Essere sicuri che l altra persona abbia compreso quello che il tester gli ha detto e viceversa, per evitare malintesi e incomprensioni. Pagina 20 di 77

21 1.6. CODICE ETICO (K2) 10 minuti La partecipazione ai test del software consente alle persone di apprendere informazioni riservate e privilegiate. Un codice etico è necessario, tra le altre ragioni, per garantire che tali informazioni non siano utilizzate ad uso improprio. ISTQB, riconoscendo il codice etico per gli ingegneri di ACM e IEEE, ha definito il seguente codice etico: * PUBBLICO i software tester certificati devono agire coerentemente con l'interesse pubblico * CLIENTE E DATORE DI LAVORO i software tester certificati devono agire nel miglior interesse del loro cliente e del loro datore di lavoro, in coerenza con l'interesse pubblico * PRODOTTO - i software tester certificati devono assicurare che quanto rilasciato (per i prodotti e/o sistemi soggetti a test) soddisfi i più elevati standard professionali * GIUDIZIO - i software tester certificati devono esprimere i propri giudizi professionali in modo integro e indipendente * GESTIONE - I software manager e leader devono sottoscrivere e promuovere un approccio etico alla gestione del testing del software * PROFESSIONE I software tester certificati devono far prevalere l'integrità e la reputazione della professione, coerentemente con l'interesse pubblico * COLLEGHI I software tester certificati devono essere leali e disponibili ad aiutare i propri colleghi e promuovere la cooperazione con gli sviluppatori di software * FORMAZIONE I software tester certificati devono partecipare a una formazione continua per quanto riguarda la pratica della loro professione e devono mantenere un approccio etico alla pratica di tale professione 1.7. RIFERIMENTI Black, 2001, Kaner, Beizer, 1990, Black, 2001, Myers, Beizer, 1990, Hetzel, 1988, Myers, Hetzel, Black, 2001, Craig, Black, 2001, Hetzel, 1988 Pagina 21 di 77

22 2. IL TESTING DURANTE IL CICLO DI VITA DEL SOFTWARE (K2) 115 minuti OBIETTIVI DI APPRENDIMENTO PER IL TESTING DURANTE IL CICLO DI VITA DEL SOFTWARE Gli obiettivi identificano quello che si dovrà essere in grado di fare al termine di ogni singolo modulo. 2.1 Modelli di sviluppo del software (K2) LO LO LO Comprendere le relazioni tra lo sviluppo, le attività di test e quanto prodotto nel ciclo di vita dello sviluppo software, e fornire esempi basati su contesto e sulle caratteristiche di progetti e prodotti. (K2) Riconoscere il fatto che i modelli di sviluppo del software devono essere adattati al contesto del progetto e alle caratteristiche del prodotto. (K1) Ricordare i ruoli dei differenti livelli di testing e le caratteristiche di un buon testing in ogni modello di ciclo di vita. (K1) 2.2 Livelli di test (K2) LO Tipi di test (K2) LO LO LO LO LO Comparare i differenti livelli di testing: obiettivi principali, tipici oggetti del testing, tipici livelli del testing (ad esempio, funzionale o strutturale) e prodotti correlati, persone che effettuano il testing, tipi di difetti e di esiti negativi (failures) da identificare. (K2) Comparare quattro tipi di software test (funzionale, non-funzionale, strutturale e legato alle modifiche) attraverso esempi. (K2) Riconoscere che test funzionali e strutturali sono possibili ad ogni livello di test. (K1) Identificare e descrivere tipi di test non-funzionali basati su requisiti non-funzionali. (K2) Identificare e descrivere tipi di test basati sull analisi dell architettura e struttura di un sistema software. (K2) Descrivere lo scopo del testing confermativo e del testing di regressione. (K2) 2.4 Testing di manutenzione (K2) LO LO LO Confrontare il testing di manutenzione (testing su un sistema esistente) al testing di una nuova applicazione, rispetto ai tipi di test, agli inneschi del testing ed alla quantità di testing. (K2) Identificare i ruoli del testing di manutenzione (modifica, migrazione e ritiro). (K1) Descrivere il ruolo del testing di regressione e l analisi di impatto.nella manutenzione. (K2) 2.1. MODELLI DI SVILUPPO DEL SOFTWARE (K2) 20 minuti Termini Commercial off-the-shelf (COTS), modello di sviluppo iterativo-incrementale, validazione, verifica, modello a V Contesto Il testing non esiste in modo isolato; le attività di testing sono legate a quelle dello sviluppo software. Diversi modelli di cicli di vita dello sviluppo necessitano di differenti approcci al testing Modello a V (modello di sviluppo sequenziale) (K2) Benché esistano diverse varianti del modello a V, un tipo comune di modello a V usa quattro livelli di test, corrispondenti ai quattro livelli di sviluppo. I quattro livelli usati in questo syllabus sono: Pagina 22 di 77

23 o Testing di componente (o di unità) ; o Testing di integrazione; o Testing di sistema; o Testing di accettazione. In pratica, un modello a V può avere un numero differente, sia maggiore che minore, di livelli di sviluppo e testing, a seconda del progetto e del prodotto software. Per esempio, ci possono essere il testing di integrazione dei componenti, dopo il testing dei componenti, e il testing di integrazione dei sistemi dopo il testing di sistema. I prodotti del software (come scenari di business o uses cases, specifiche dei requisiti, documenti di design e codice), ovvero tutti quegli elementi (non solo codice) prodotti durante la fase di sviluppo del software sono spesso le basi del testing, gli inputs in uno o più livelli di test. Riferimenti per generici cicli di vita includono il Capability Maturity Model Integration (CMMI) o il Software life cycle processes (IEEE/IEC 12207). La verifica e la validazione (e le prime fasi di test design) possono essere svolte durante lo sviluppo dei prodotti del ciclo di vita del software Modelli di sviluppo iterativo-incrementale (K2) Lo sviluppo iterativo-incrementale è il processo di definizione dei requisiti, progettazione, costruzione e testing di un sistema, svolto come una serie di cicli di sviluppo più corti. Esempi di questo modello sono: la prototipazione, il Rapid Application Development (RAD), il Rational Unified Process (RUP) e i modelli cosiddetti di sviluppo Agile. Il sistema risultante da un tale approccio può essere testato a diversi livelli durante ogni iterazione. Un incremento, aggiunto agli altri sviluppati precedentemente, forma un sistema parziale in crescita, che deve essere anch'esso testato. In questo contesto il regression testing diventa di importanza crescente durante tutte le iterazioni successive alla prima. La verifica e la validazione possono essere condotte su ogni singolo incremento Il testing in un modello di ciclo di vita (K2) In ogni modello di ciclo di vita, ci sono diverse caratteristiche per condurre un buon testing: o Per ogni attività di sviluppo c è una corrispondente attività di testing. o Ogni singolo livello di test ha degli obiettivi di test specifici di quel livello. o L analisi e la progettazione dei test per un dato livello di test deve iniziare durante la corrispondente attività di sviluppo. o I testers devono essere coinvolti nella revisione dei documenti non appena le loro versioni in bozza siano disponibili nel ciclo di vita di sviluppo. I livelli di test possono essere combinati o riorganizzati a seconda della natura del progetto o della architettura di sistema. Per esempio, per l integrazione di un prodotto software COTS (commercial offthe-shelf), l acquirente può eseguire del testing di integrazione a livello di sistema (ad esempio, integrazione all infrastruttura e ad altri sistemi, o deployment del sistema) e del testing di accettazione (funzionale e /o non funzionale e testing utente e/o operativo). Pagina 23 di 77

24 2.2. LIVELLI DI TEST (K2) 40 minuti Termini Alpha testing, beta testing, testing di componente (noto anche come testing di unità, di modulo, o di programma), driver, field testing, requisiti funzionali, integrazione, testing di integrazione, requisito non funzionale, testing di robustezza, stub, testing di sistema, livello di test, sviluppo test-driven (sviluppo guidato dal test), ambiente di test, testing di accettazione utente Contesto Per ogni livello di test, i seguenti elementi possono essere identificati: i loro obiettivi generici, gli inputs di riferimento per la derivazione dei test cases (quindi le basi di test), l oggetto del test (quindi quello che deve essere testato), i tipici difetti e gli esiti negativi (failures) più critici da trovare, i requisiti di test harness e il supporto degli strumenti, nonché gli specifici approcci e responsabilità. Il testing dei dati di configurazione di sistema deve essere preso in considerazione nella pianificazione del testing, se tali dati fanno parte del sistema Testing di componente (K2) Basi di test: Requisiti dei componenti Disegno dettagliato Codice Tipici oggetti di test: Componenti Programmi Programmi di conversione dati / migrazione Banche Dati Il testing di componente cerca i difetti e verifica il funzionamento di software (ad esempio, moduli, programmi, oggetti, classi, ecc) che sono testabili separatamente. Esso può essere condotto in isolamento dal resto del sistema, a seconda del contesto del ciclo di vita dello sviluppo e del sistema. In questa attività possono essere usati stubs, drivers e simulatori. Il testing di componente può includere il testing di funzionalità e di specifiche caratteristiche non funzionali, come il comportamento di alcune risorse (ad esempio, memory leaks ) o testing di robustezza, nonché il testing strutturale (ad esempio, copertura delle condizioni). I test cases sono derivati da input come una specifica del componente, il design del software o il modello dei dati. Tipicamente, il testing di componente si realizza con accesso al codice sotto testing e con il supporto dell ambiente di sviluppo, come un framework di test di unità o uno strumento di debugging e, in pratica, coinvolge normalmente il programmatore che ha scritto il codice. I difetti sono tipicamente corretti non appena sono trovati, senza effettuare delle segnalazioni formali. Un approccio al testing di componente è di preparare e automatizzare i test cases prima della codifica: questo viene chiamato approccio test-first o sviluppo test-driven). Questo approccio è altamente iterativo ed è basato su cicli di sviluppo di test cases, quindi di compilazione e integrazione di piccoli pezzi di codice, e di esecuzione dei test di componente fino a quando risultino corretti. Pagina 24 di 77