Corso ISTQB Certified Tester Livello Foundation

Transcript

1 Fornitore della formazione accreditato da ITA-STQB Corso ISTQB Certified Tester Livello Foundation Conforme al Syllabus Foundation versione 2011

2 ALTEN ITALIA ACADEMY ALTEN ITALIA is: Certified by BMC for providing courses on Remedy and ITSM technologies The first and main Italian Accredited Training Provider, accredited by ITA-STQB for providing training courses on software engineering; it covers the whole range of ISTQB courses (Foundation, AL Test Manager, AL Test Analyst and AL Technical Test Analyst) and REQB schemes The only Italian Company accredited by isqi for providing training on testing of mobile application(cmap) PMI RegisteredEducationProvider, offering training in project management ScrumAlliance Registered Education Provider, offering traning to Scrum Methodology 5

3 Strategia di ISTQB ISTQB Strategy To build and to evolve a complete and accurate knowledge base on software testing To consolidate the software tester profession To spread internationally the know-how on testing To contribute in achieving an adequate quality level on products and services in which software has a role 10

4 Diffusione Copertura geografica di ISTQB ISTQB è rappresentato da 49 Member Board in 72 Paesi di tutto il Mondo Member Board Presenza di un Global Exam Provider 16

5 ISTQB - Numero di Certificati Page 18

6 Cos è ITA-STQB ITA-STQB (ITAlian Software Testing Qualifications Board) è un associazione non profit nata nel 2007 e che ha iniziato a effettuare esami dalla seconda metà del 2008 Ha l'obiettivo di effettuare in Italia la certificazione delle competenze in ambito sw engineering, in riferimento a: Software Testing ISTQB Mobile App Testing CMAP Requirements Engineering REQB 19

7 ISTQB Levels and Contents Page 22

8 Programma del corso 1. Fondamenti del testing 2. Il testing durante il ciclo di vita del software 3. Tecniche statiche 4. Tecniche di progettazione di test 5. Gestione del test 6. Supporto di tool per il testing 7. Riferimenti 26

9 Fondamenti del testing 1. Fondamenti del testing 2. Il testing durante il ciclo di vita del software 3. Tecniche statiche 4. Tecniche di progettazione di test 5. Gestione del test 6. Supporto di tool per il testing 7. Riferimenti 27

10 Il software è dappertutto I sistemi software sono parte integrante della vita quotidiana, dalle applicazioni aziendali ai sistemi di bordo delle auto. Chiunque è stato testimone di un software che non si è comportato come previsto osservando diversi gradi di conseguenze. 29

11 Cause dei difetti nel software Terminologia Una persona compie un error... Error Fault Failure che causa un fault nel software... che puo causare un failure 30

12 Cause dei Difetti Gli esseri umani possono commettere errori, che producono difetti nel codice o nella documentazione. Gli errori possono avere origini differenti: mancanza di tempo, incomprensioni, complessità, cambi tecnologici, ecc. I difetti nel codice, se eseguiti, possono causare esiti negativi. Gli esiti negativi si possono presentare anche a causa di fattori esterni, come ad esempio i fenomeni magnetici o meteorologici. 31

13 Fondamenti del testing Terminologia Error (errore): azione umana che produce un risultato non corretto (scrivere codice non corretto) Fault (guasto): la manifestazione di un errore, nel software noto anche come defect (difetto) or bug (baco) se eseguito, un fault può generare un Failure (fallimento esito negativo): deviazione del comportamento del software da quanto atteso. L error è un azione; il fault è uno stato del software, che può generare un failure 32

14 Che cos è il testing? Testing (dal glossario): Il processo che include tutte le attività, sia statiche che dinamiche, del ciclo di vita, riguardanti l analisi di prodotti software e dei prodotti di lavoro correlati, per valutare se essi soddisfano i requisiti specificati. Il testing e il debugging sono attività differenti Il debugging è l attività di localizzazione e correzione dei difetti. Fa parte del processo di sviluppo, non del testing. L obiettivo del testing è la più o meno sistematica rilevazione di esiti negativi (che sono indice della presenza di difetti). 38

15 Vantaggi del testing Requisiti Analisi Sviluppo Test Produzione 5 5 % 20 % 40 % 30 % < 5 % Livello di maturità del test 4 3 % 12 % 30 % 50 % 5 % 3 0 % 2 % 20 % 70 % 8 % 2 0 % 0 % 3 % 80 % 17 % 1 0 % 0 % 2 % 50 % 48% Distribuzione Fault COSTO PER BUG FIXING

16 Sette Principi del Testing 1. Il fatto di non trovare difetti col testing non implica la correttezza del software. Il testing riduce la probabilità che si manifestino i difetti non trovati. 2. Il test esaustivo non è possibile. L analisi del rischio e le priorità indicano come distribuire le risorse. 3. Il testing deve iniziare il prima possibile e deve avere obiettivi ben definiti. 4. I difetti tendono a raggrupparsi (cluster); un piccolo insieme di moduli contiene un grosso numero di difetti. 43

17 Sette Principi del Testing 5. Paradosso del pesticida. Se gli stessi test vengono ripetuti, la loro efficacia nel trovare difetti diminuirà nel tempo. 6. Il test viene svolto in modi diversi a seconda del contesto. Ad esempio, il test di un software safety-critical è svolto in modo diverso dal test di un software di e-commerce. 7. Trovare e risolvere difetti è inutile se il sistema non soddisfa le aspettative e le esigenze degli utenti. 44

18 Fondamenti del Processo di Test La parte più visibile del processo di testing è quella dell esecuzione, ma perché l intero processo sia efficace è necessario svolgere diverse attività. Il processo di test consiste nelle seguenti: Pianificazione dei test e controllo Analisi e progettazione dei test Implementazione ed esecuzione dei test Valutazione dei criteri d uscita e reportistica Attività di chiusura del test 45

19 La Psicologia del Testing Capita a tutti di sbagliare, ma a nessuno piace sentirselo dire. La mentalità con cui si svolge il testing è diversa da quella con cui si sviluppa. L indipendenza dei ruoli fornisce diversi benefici ed aiuta a raggiungere risultati migliori. In alcuni casi la conoscenza del codice è invece un fattore importante. 66

20 La Psicologia del Testing Possono nascere incomprensioni e contrasti se i tester sono visti come messaggeri di cattive notizie sui difetti. Le seguenti azioni possono aiutare a migliorare la situazione: Ricordare sempre che l obiettivo comune è la qualità del progetto. Comunicare in maniera neutra, focalizzandosi solo sui fatti ed sui dati, anziché sulle persone. Comprendere sensazioni e reazioni altrui. Assicurarsi che l interlocutore abbia compreso quanto condiviso. 70

21 Il testing durante il ciclo di vita del software 1. Fondamenti del testing 2. Il testing durante il ciclo di vita del software 3. Tecniche statiche 4. Tecniche di progettazione di test 5. Gestione del test 6. Supporto di tool per il testing 7. Riferimenti 74

22 Il testing durante il ciclo di vita del software In questo capitolo presenteremo i seguenti argomenti: Modelli di sviluppo del software Livelli di test Tipi di test 75

23 Il testing durante il ciclo di vita del software Il testing non è un attività indipendente dal ciclo di sviluppo del software, le attività di test sono collegate alle attività di sviluppo. Diversi modelli del ciclo di sviluppo del software necessitano di diversi approcci al test. Una tipica classificazione dei modelli di sviluppo è la seguente: Modelli sequenziali Modelli evolutivi Modelli incrementali Processi Agili Modelli iterativi 76

24 Modello a V - Sequenziale Il modello a V costituisce l integrazione delle fasi di testing nel modello sequenziale (waterfall) in alternativa al modello classico che prevede il testing come ultima fase prima del rilascio dell applicazione. 77

25 Modello a V - Sequenziale Definizione dei requisiti Test di accettazione Progettazione Funzionale del sistema Test di sistema Progettazione Tecnica del sistema Test di integrazione Specifica di componente Test di componente Programmazione 79

26 Modelli di Sviluppo Iterativi In questi modelli la progettazione, lo sviluppo ed il test vengono affrontati in modo incrementale e sono basati su un insieme crescente di requisiti. In questo modo si riduce il rischio di produrre il prodotto sbagliato, infatti, esso viene validato dal cliente fin dai primi cicli di sviluppo. Esempi di questo modello di ciclo di vita sono: il Prototyping, il RAD (Rapid Application Development), UP (Unified Process) ed i modelli di sviluppo Agile. 80

27 Modelli di Sviluppo Iterativi Un sistema prodotto con questi modelli può essere sottoposto a test di diverso livello durante ogni ciclo di sviluppo. Assume quindi un aspetto preponderante il test di regressione. All insieme dei test di regressione, si aggiungono quelli relativi alla nuova iterazione. 84

28 Modelli di Sviluppo Iterativi Un modo per vedere come si distribuisce il test nei modelli iterativi è il seguente: Rilascio 1 Rilascio 2 Rilascio 3 Rilascio 4 Rilascio 5 Rilascio e test 85

29 Il testing nel ciclo di sviluppo Qualsiasi sia il modello di sviluppo, il buon testing è caratterizzato dal fatto che: Ad ogni attività di sviluppo corrisponde un attività di testing. Ogni livello di test ha degli obiettivi specifici per quel livello. L analisi e la progettazione dei test di un livello dovrebbero iniziare durante la corrispondente attività di sviluppo. I tester dovrebbero essere coinvolti nella review dei documenti non appena essi sono disponibili. 86

30 Livelli di Test Per ogni livello di test è possibile identificare i seguenti: Obiettivi generici dell attività. I documenti da cui derivare i test case (detti basi di test). L oggetto del test, cioè cosa si vuole testare. Tipologia di difetti che si vuole individuare. Ambiente di test e tool di supporto. Ruoli e responsabilità. 87

31 Test di Componente Chiamato anche test di Modulo o di Unità. Cerca difetti in parti di codice testabili separatamente dal resto dell applicazione: moduli software, programmi, oggetti, classi. Può includere il testing di funzionalità, di utilizzo risorse (memory leak), robustezza o test strutturale (copertura delle istruzioni o delle decisioni). 88

32 Test di Componente E spesso necessario usare stub, driver o simulatori. L attività viene svolta con il supporto degli sviluppatori e i difetti vengono corretti non appena rilevati. E meno importante una loro gestione formale. Un approccio può essere quello di pensare i test prima di sviluppare il codice (test-first o test-driven development). E un approccio molto iterativo e tipico dello sviluppo agile. 89

33 Test di Componente I tipici difetti trovati durante il testing di componente sono calcoli errati o cammini nel software scelti in modo errato (condizioni espresse male) La robustezza è un altro aspetto molto importante del testing di componente Importanti sono anche efficienza e manutenibilità 90

34 Test di Integrazione Si concentra sulle interfacce tra componenti, interazioni con altre parti del sistema come il SO, l hardware e altri sistemi. Ci possono essere più livelli di integrazione e quindi gli oggetti del test possono essere di diverse dimensioni, ad esempio: Integrazione di componenti. Si svolge dopo il test di componente. Integrazione fra sistemi o tra hardware e software. Si svolge dopo il test di sistema. 92

35 Test di Sistema Il test di sistema verifica che il prodotto integrato soddisfi i requisiti specificati. Ci sono almeno due motivi per i quali questo livello è ancora necessario dopo i test di componente e di integrazione: Il test di sistema valuta il sistema dalla prospettiva del cliente e dell utente finale. I tester validano se i requisiti utente sono soddisfatti completamente ed in modo appropriato Molte funzioni e caratteristiche del sistema risultano dalle interazioni di tutti i componenti del sistema e quindi sono visibili solo quando tutto il sistema è integrato. 107

36 Test di Sistema Strumenti di Monitoraggio STTE (Special Type Test Equipment) HOST PC Sistema oggetto del test HOST PC Strumenti di Supporto (es. simulatori) STTE (Special Type Test Equipment) ETH RS232 RS232 ETH RS422 (V11) 110

37 Tipi di Test All interno di ciascun livello di test possono essere utilizzati diversi tipi di test a seconda di quale sia il particolare obiettivo, ad esempio: Una funzione svolta del software. Una caratteristica non funzionale (ad es. l usabilità). La struttura o l architettura del software o del sistema. Verificare delle modifiche (ad es. la rimozione di un difetto). 116

38 Tipi di Test Test Funzionale Le funzionalità indicano cosa il sistema deve fare. La loro descrizione può essere tipicamente trovata nei requisiti funzionali o negli use case. Il test funzionale considera il comportamento esterno del sistema (black-box testing). I test funzionali possono essere svolti a qualsiasi livello di test. 118

39 Tipi di Test Test Non Funzionale Il test non funzionale include il test prestazionale, il test di carico, l usabilità, la manutenibilità, l affidabilità e la portabilità. E un test su come il sistema deve funzionare. Il termine non funzionale indica la necessità di misurare una caratteristica. 120

40 Tipi di Test Test Non Funzionale modello ISO

41 Tipi di Test Test Strutturale Il testing strutturale (white box) può essere svolto a qualsiasi livello di test. La copertura, espressa in percentuale, è la prova che la struttura è stata esercitata completamente da un insieme di test. Le tecniche strutturali sono utilizzate al meglio se utilizzate in aggiunta a tecniche basate sulle specifiche. 123

42 Tipi di Test Test Strutturale Nei livelli più bassi del test (componente, integrazione), è utile l utilizzo di strumenti automatici per misurare la copertura del codice, delle decisioni. Il test strutturale può basarsi anche sull architettura del sistema, come una gerarchia di chiamate. 124

43 Tipi di Test Test sulle Modifiche Dopo che un difetto è stato rilevato e corretto, il software deve essere nuovamente testato per verificare l effettiva rimozione (test confermativo) e che ciò non abbia causato l insorgenza di nuovi difetti nel resto dell applicazione (test di regressione). Il test di regressione si applica anche nel caso di modifiche all ambiente operativo, quindi non del software stesso. Per sua natura il test di regressione è un ottimo candidato per essere automatizzato. 125

44 Tecniche statiche 1. Fondamenti del testing 2. Il testing durante il ciclo di vita del software 3. Tecniche statiche 4. Tecniche di progettazione di test 5. Gestione del test 6. Supporto di tool per il testing 7. Riferimenti 144

45 Tecniche Statiche e Processo di Test Diversamente dalle tecniche dinamiche, che richiedono l esecuzione di software, le tecniche statiche si basano sull esame manuale (review) e su analisi automatiche (analisi statica) del codice o di altri documenti di progetto. Le review sono modi di testare manufatti (deliverable) e possono essere svolte prima dell esecuzione dinamica. Difetti trovati durante le review nelle fasi iniziali del progetto sono molto meno costosi da rimuovere di quelli trovati durante l esecuzione dei test. 145

46 Tecniche Statiche e Processo di Test I benefici delle review includono: la scoperta anticipata e la correzione di difetti, incremento della produttività nello sviluppo, riduzione dei costi di testing, e riduzione globale dei costi. Le review possono trovare omissioni, come ad esempio requisiti mancanti o sottintesi, o inconsistenze che il test dinamico non può trovare. 147

47 Analisi Statica con Tool L obiettivo dell analisi statica è quello di trovare difetti nel codice o nel modello del software. I vantaggi dell analisi statica includono: Scoperta anticipata dei difetti Scoperta di possibili aspetti sospetti del codice, o del modello del sistema, attraverso il calcolo di metriche ad esempio sulla complessità Scoperta di difetti non identificabili con il test dinamico Scoperta di dipendenze o inconsistenze Miglioramento nella manutenibilità del codice Prevenzione di difetti simili in futuri progetti 158

48 Analisi Statica con Tool I difetti tipici che vengono individuati da tool di analisi statica sono: Variabili con valori indefiniti Variabili che non sono usate o che sono impropriamente dichiarate Codice morto Errori logici (potenziali cicli infiniti) Costrutti logici inutilmente complessi Violazioni a standard di programmazione Vulnerabilità di sicurezza 159

49 Tecniche di progettazione di test 1. Fondamenti del testing 2. Il testing durante il ciclo di vita del software 3. Tecniche statiche 4. Tecniche di progettazione di test 5. Gestione del test 6. Supporto di tool per il testing 7. Riferimenti 164

50 Categorie di Tecniche di Progettazione dei Test Lo scopo delle diverse tecniche di progettazione dei test è quello di identificare le condizioni di test, i test case ed i dati di test. Tipicamente si distinguono tecniche black-box e white-box. 171

51 Categorie di Tecniche di Progettazione dei Test Nelle tecniche Black-Box le informazioni necessarie alla progettazione dei test vengono derivate dall analisi della documentazione, sia per il test funzionale che quello non funzionale. Nelle tecniche White-Box le informazioni vengono derivate dalla struttura del componente o del sistema. 172

52 Tecniche Black-Box Partizioni in classi di Equivalenza (Equivalence Partitioning) I possibili input di un sistema sono divisi in gruppi da cui ci si aspetta un comportamento uniforme. Le partizioni di equivalenza (o classi) possono contenere dati validi e non validi. Partizioni possono essere identificate anche per gli output, valori intermedi, valori temporali, parametri di interfacce, ecc. Il test viene progettato in modo da coprire tutte le partizioni valide e non valide. 174

53 Tecniche Black-Box Esempio Min negativo Max positivo 0 Dominio di input 1000 Classe di equivalenza invalida Classe di equivalenza Valida Classe di equivalenza invalida 175

54 Tecniche Black-Box Analisi dei Valori Limite Il comportamento ai limiti delle classi di equivalenza è quello maggiormente a rischio Il valore massimo e quello minimo di una partizione sono i valori limite E una tecnica particolarmente facile ed estremamente efficace I valori limite si ottengono analizzando la specifica di dettaglio 183

55 Tecniche Black-Box Transizioni di Stato Un sistema può avere un comportamento dipendente dalla condizione in cui si trova in un determinato istante, oltre che da eventi esterni. In questi casi si può rappresentare il comportamento del sistema con un diagramma di transizioni di stato. Questo permette al tester di vedere il sistema come un insieme di stati e transizioni tra stati, eventi che provocano il cambiamento di stato e azioni che sono eseguite in base a questi cambiamenti. Gli stati del sistema sono separati, identificabili ed in numero finito. 193

56 Tecniche Black-Box Transizioni di Stato: Esempio top pop [se dimensione > 1] push [se dimensione < Max-1] top vuota init push pop [dimensione = 1] parzialmente riempita push [dimensione = Max-1] pop piena delete Legenda: Stato di Inizio e Fine Transizione di stato nome Stato 196

57 Tecniche White-Box Sono basate sulla conoscenza della struttura del software o del sistema, ad esempio: A livello di componente: la struttura del componente, come le istruzioni, le decisioni, i rami di codice, ecc. A livello di integrazione: la struttura potrebbe essere l albero delle chiamate (diagramma con le chiamate fra i diversi moduli). A livello di sistema: potrebbe essere la struttura dei menu, il processo di business o la mappa di navigazione di un sito web. Per le tecniche white-box è di estremo aiuto l utilizzo di strumenti automatici. 200

58 Tecniche White-Box Tra le tecniche di progettazione di test white-box vedremo: Testing e copertura delle istruzioni Testing e copertura delle decisioni Testing e copertura delle condizioni (cenni) 201

59 Tecniche White-Box Testing delle istruzioni e copertura Questa tecnica si focalizza su ogni singola istruzione dell oggetto del test (codice) Il primo passo consiste nella creazione del grafo del flusso di controllo Nel grafo le istruzioni condizionali sono rappresentate come nodi, ed il flusso di controllo tra le istruzione è rappresentato attraverso archi (connessioni) I test case devono eseguire una quota minima predefinita (obiettivo del test) delle istruzioni dell oggetto del test; idealmente il 100% 202

60 Tecniche White-Box Se sequenze di istruzioni non condizionali appaiono in un frammento di programma, allora esse sono illustrate come un singolo elemento. Istruzioni condizionali (IF, CASE) e cicli (WHILE, FOR) hanno più diramazioni che escono da essi. c IF ENDIF b d Istr Istr IF a f i Istr g WHILE Istr DO h k ENDIF e 204

61 Tecniche White-Box Testing delle decisioni e copertura E la valutazione della percentuale di decisioni sollecitate da una test suite. Le decisioni sono i valori Vero e Falso assunti dalla condizione complessiva utilizzata in un istruzione condizionale Facendo riferimento al grafo, le decisioni sono rappresentate dagli archi. Si noti che il 100% di copertura delle decisioni implica il 100% della copertura delle istruzioni, ma non il viceversa. 205

62 Tecniche White-Box Facendo riferimento all esempio si noti che la copertura delle istruzioni b è data da un solo test case: a, b, f, g, h, d, e Mentre per la copertura delle decisioni servono 3 test case: a, b, c, d, e a, b, f, g, i, g, h, d, e a, k, e c IF ENDIF d Istr Istr i WHILE Istr ENDIF IF f Istr g h a DO e k 206

63 Gestione del test 1. Fondamenti del testing 2. Il testing durante il ciclo di vita del software 3. Tecniche statiche 4. Tecniche di progettazione di test 5. Gestione del test 6. Supporto di tool per il testing 7. Riferimenti 233

64 Gestione del test In questo capitolo presenteremo i seguenti argomenti: Organizzazione del testing Pianificazione e stima del test Monitoraggio e controllo nell avanzamento del test Gestione della configurazione Gestione degli incidenti 234

65 Organizzazione del test Organizzazione del test e indipendenza L efficacia nello scoprire gli errori con tecniche statiche e dinamiche può essere aumentata impiegando tester indipendenti. L indipendenza può essere di diversi gradi: 1. Assenza di tester indipendenti. Gli sviluppatori testano il proprio codice. 2. Tester indipendenti all interno del team di sviluppo. 3. Gruppi di test indipendenti all interno della stessa azienda. 4. Tester indipendenti appartenenti al business o agli utenti. 5. Specialisti del test specifico, ad esempio usabilità, sicurezza. 6. Tester esterni all azienda (Outsourcing del test). 235

66 Pianificazione del test e stima Pianificazione del test Il contenuto di un piano di test è descritto dal documento standard for test documentation (IEEE Std ). La pianificazione è influenzata dalla politica aziendale di test, dallo scopo del test, gli obiettivi, i rischi, i vincoli, le criticità, la testabilità e la disponibilità delle risorse. Con l avanzamento del progetto e del test stesso, diventano disponibili maggiori informazioni che possono essere inserite nel piano di test. La pianificazione del test è un attività dinamica che dura tutto il progetto e le informazioni ottenute possono modificare, ad esempio, rischi ed approcci dei rimanenti test. 246

67 Strategia e approccio al test Scegliere una strategia appropriata è una delle più importanti decisioni delle attività di pianificazione L obiettivo è di scegliere un approccio di test che ottimizzi la relazione costi/benefici Una strategia di test definisce gli obiettivi di testing del progetto i modi per raggiungerli La strategia di test determina quindi anche: lo sforzo del testing i costi di testing 254

68 Strategia e approccio al test L approccio al test è l implementazione della strategia per un progetto specifico. L approccio è definito e raffinato nel piano di test e nella progettazione dei test. Include le decisioni prese in base agli obiettivi ed alle valutazioni sui rischi. E il punto d inizio per la pianificazione del processo di test, per la scelta delle tecniche di progettazione, per la definizione dei criteri di ingresso e uscita, e per i tipi di test da implementare. 255

69 Monitoraggio e controllo del test Metriche tipiche del monitoraggio sono: Percentuale del lavoro fatto nella preparazione dei test case. Esecuzione dei test case (numero dei test case eseguiti, numero di test case falliti). Informazioni sui difetti (densità, trovati e corretti, risultati dei re-test). Copertura dei requisiti. 259

70 Configuration management Lo scopo del configuration management (CM) è di stabilire e mantenere l integrità dei prodotti (componenti, dati e documentazione) durante il ciclo di vita del progetto e del prodotto. Nell ambito specifico del testing, il CM garantisce che: Tutti gli oggetti del testware sono identificati, sottoposti a controllo della versione, le modifiche siano tracciate. Tutti i documenti e oggetti software siano referenziati in modo non ambiguo nella documentazione di test. 263

71 Gestione degli incidenti Lo scopo del testing è trovare difetti. Le discrepanze tra i risultati ottenuti e quelli previsti vengono tracciate tramite incidenti. Un incidente deve essere investigato e può rivelarsi un difetto. Devono essere definite appropriate azioni per gestire gli incidenti; essi devono essere tracciati, classificati e ne deve essere confermata la soluzione. Per fare ciò è necessario definire un processo per la gestione e delle regole per la classificazione. 272

72 Supporto di tool per il testing 1. Fondamenti del testing 2. Il testing durante il ciclo di vita del software 3. Tecniche statiche 4. Tecniche di progettazione di test 5. Gestione del test 6. Supporto di tool per il testing 7. Riferimenti 287

73 Strumenti di supporto al testing L attività di testing può trovare grossi miglioramenti in termini di efficacia ed efficienza se supportata dagli strumenti adeguati. In particolare: Per l esecuzione dei test, generazione di dati per i test, per il confronto tra i risultati previsti e quelli ottenuti Per la gestione del processo di test: gestione dei test, dei risultati, dei dati, dei requisiti, degli incident e per il reporting Per l esplorazione: monitor, sonde, ecc 288

74 Strumenti di supporto al testing Possono avere diversi scopi a seconda del contesto, ad esempio: Incrementare l efficienza ad esempio automatizzando test ripetitivi o aiutando la gestione delle attività. Automatizzare attività che se svolte in modo manuale richiederebbero risorse significative, come ad esempio il test statico. Automatizzare attività che non possono essere fatte manualmente, come ad esempio test di performance su larga scala. Incrementare l affidabilità del test. 289

75 Utilizzo dei tool: benefici e rischi Il prezzo non è l unico costo per l introduzione di un tool in un organizzazione. La sua introduzione comporta inoltre dei benefici, ma presenta anche dei rischi. I potenziali benefici sono: Riduzione del lavoro ripetitivo (test di regressione) Maggiore consistenza e ripetibilità dei test Valutazione obiettiva dei risultati Maggiore facilità ad accedere alle informazioni necessarie al testing ed ai report del testing 302

76 Utilizzo dei tool: benefici e rischi I potenziali rischi sono: Aspettative irrealistiche dai tool Sottovalutazione del tempo, dei costi e dello sforzo per l introduzione iniziale del tool (inclusa la formazione) Sottovalutazione del tempo e dello sforzo necessari per raggiungere significativi e continui benefici, incluse variazioni al processo di sviluppo. Sottovalutazione dello sforzo necessario alla manutenzione del tool e dei suoi risultati. Sovrastima delle attività che il tool può svolgere. Problemi con il fornitore, il prodotto e l assistenza. 303

77 Riferimenti 1. Fondamenti del testing 2. Il testing durante il ciclo di vita del software 3. Tecniche statiche 4. Tecniche di progettazione di test 5. Gestione del test 6. Supporto di tool per il testing 7. Riferimenti 314

78 Riferimenti Bibliografici A. Spillner, T. Linz, H. Schaefer Software Testing Foundations: A Study Guide for the Certified Tester Exam (3rd edition) Rockynook Jan 2011 Dorothy Graham, Isabel Evans, Erik Van Veenendaal, Rex Black Foundations of Software Testing: ISTQB Certification (3nd edition) Cengage

79 STF Italian Software Testing Forum L evento italiano sul Testing e la Qualità di Prodotti e Servizi Software Intensive, che fa parte dell ISTQB Conference Network La quarta edizione si è tenuta a Milano dal 23 al 26 giugno 2014 Organizzazione in due giornate Prima giornata dedicata a tutorial specializzati Seconda giornata di conferenza ad ingresso libero Page 316

80 STF 2013 Facts & Figures Alcuni dati quantitativi relativi alla quarta edizione di STF, che ha avuto un ottimo riscontro da parte di Partecipanti e Sponsor Numero di partecipanti ai tutorial: 71 Numero di iscritti alla conferenza: 506 Numero di presentazioni: 30 Numero di sponsor: 14 Numero di patrocinanti: 4 Indice di soddisfazione dei partecipanti ai tutorial: 76,68 % Indice di soddisfazione dei partecipanti alla conferenza: 76,12 % Percentuale di partecipanti che hanno dichiarato interesse a partecipare a future edizioni dell evento 92% I video delle presentazioni della sessione plenaria e delle interviste agli Sponsor sono disponibili su: Page 317

81 Per approfondimenti Per ulteriori dettagli: Sito web ITA-STQB: Sito web STF: Sito web ISTQB : Sito web REQB : Sito web CMAP : Community LinkedIn ITA-STQB : Contatto info@ita-stqb.org 318

82 Social Networks ISTQB YouTube presence: Slide Share presence: LinkedIn Community: ISTQB International Software Testing Qualifications Board Twitter channel: XING community: Facebook presence: ISTQB Smartshow 319