Total Test Management

Transcript

1 Total Test Management Laboratorio di ingegneria del software Fabio Rabini

2 Software Development LifeCycle Configuration Management S Business Modeling & Requirements Analysis & Design Implementa tion Building & Deployment Test Test Case Test Script Test Planning Design Design Execution Defects Acceptance & Rollout Non Conformancy Mainteinance Defects Cost Control & Estimation Change Management

3 Test Process (Verification + Validation) Piano dei Test (Test Plan) Documento dei Test case Progettazione degli scenari di Test Risultati dei Test (Test Summary Report) Strategia di Test Schedulazione attività Risorse assegnate Effort (costi) Analisi del Rischio Test Planning Test Case/Script Design Workload Design Test Execution Esecuzione degli scenari di Test Apertura difetti (CR) Software Validation Test Management Piano di Collaudo (ATP)

4 Test Planning Test Planning Test Case/Script Design Workload Design Test Execution Software Validation Test Management

5 Piano dei Test (Test Plan) E il documento che disciplina lo svolgimento dei Test per un determinato sistema/applicazione Secondo lo standard IEEE 829 il Test Plan deve comprendere: La specifica dei moduli che devono essere testati Il confine funzionale dell applicazione La matrice di copertura dei test I Criteri di sospensione e ripresa dei Test I Criteri di Pass/ Fail I Deliverables della Fase di Test Necessità di sviluppo di stub/drivers La descrizione dell ambiente Hardware/ Software Eventuali tools utilizzati per la Test Automation Gantt delle attività di Test e relative responsabilità Piano dei Test (TestPlan)

6 Test Planning: Stimare L effort di Test Test Estimation is the estimation of the testing size, testing effort, testing cost and testing schedule for a specified software testing project in a specified environment using defined methods, tools and techniques. L effort necessario al Test di un sistema dipende da diversi fattori alcuni dei quali sono: Size del Sistema Tipo di Test Pianificato Presenza o meno della documentazione di Test (Test Case) Attività non di test strettamente correlate ai test (Loggare le CR, aggiornare la documentazione, deploy del sistema, configurazione dell ambiente di test )

7 Test Planning: Stimare L effort di Test Approcci Diversi Approcci 1. Quota Parte dell effort di progetto 2. Analogy Based Estimation 3. Software Size Based Estimation 4. Test Case Enumeration Based Estimation 5. Task (Activity) based Estimation

8 Test Estimation: Quota parte dell effort di progetto In total development rientrano le attività di analisi, sviluppo e test. Non comprende (di solito) le attività a supporto (CM) e bugfixing

9 Test Estimation: Analogy Based L effort di test viene stimato per analogia con progetti simili (per tecnologia, tipo di test, tool utilizzati, architettura ) già testati. Facile e Veloce Impreciso, Grossolano Necessita di una base di dati storici e relativa clusterizzazione

10 Test Estimation: Software Size Based L effort di test viene stimato a partire dalla dimensione funzionale/tecnica (FP, SLOC, classi) del software da testare applicando una produttività di Test. Facile e Veloce Abbastanza accurato (se esiste Benchmark) La stima (i razionali) non è verificabile se non ex-post Difficile derivare la produttività di Test Difficile derivare la produttività di Test (multifattoriale)

11 Test Estimation: Test Case Enumeration Applicare il seguente algoritmo: 1. Enumerare (fare la lista) di tutti i test case 2. Stimare l effort di test per ciascun test case (Best Case, Normal Case and Worst Case) 3. Calcolare l effort atteso per ciascun caso di test utilizzando la distribuzione Beta Expected = Best Case + Worst Case + (4 * Normal Case)/6 Abbastanza accurato Razionali verificabili Fornisce un range di valori Non immediato

12 Test Estimation: Test Activity Applicare il seguente algoritmo: 1. Enumerare (fare la lista) di tutte le attività di test (Top Down) 2. Stimare l effort di test per ciascun test case (Best Case, Normal Case and Worst Case) 3. Calcolare l effort atteso per ciascuna activity utilizzando la distribuzione Beta Expected = Best Case + Worst Case + (4 * Normal Case)/6 Abbastanza accurato tiene in conto tutti i task Razionali verificabili Fornisce un range di valori Non tiene in conto la dimensione del SW

13 Business Game Obiettivo: Pianificare le attività di Test per una Web Application di 800 FP. Parametri: Capacità di Test (Team Senior): 65 FP/day Efficacia del 80% - costo 700 /day Capacità di Test (Team Junior): 50 FP/day Efficacia del 70% - costo 250 /day Densità BUG (iniziale): 0,2 Bug/FP Capacità di BugFix: 30 Bug/day Costo BugFix/day = 750 Total elapsed a disposizione: 40 days Exit Criteria: nbug <=15 Correggere un bug in produzione = 300 Budget a disposizione Test + BugFixing + Mainteinance = min

14 Business Game Step 1: Calcoliamo la difettosità attesa Bug Attesi = Densità Difettosità * Size = 0,2*800 = 160 Bug Step 2: Pianifichiamo i Run di test (e i relativi costi) per raggiungere l exit criteria (15 bug residui) Bug da rilevare e correggere = = 145 Step 3: calcoliamo l effort e i costi con i due team

15 Business Game Step 4: Aggiungiamo il BugFix Time e il costo (Bugfix rate = 30bug/day) Team Team Senior Run 1 Team Junior Team Senior 25,6 1 Run 2 Team Junior 33,6 1 Bug trovati BugFix Time costo Step 5: Calcoliamo il costo della non qualità Team Bug Residui Costo unit Costo Senior Junior

16 Business Game Step 6: Putting all Togheter Quale delle due strade?

17 Business Game Evento: Lo sviluppo tarda 12 gg i test iniziano 12 gg dopo Valutiamo l impatto: giorni residui = = 28 A disposizione Planned % esecuzione Senior % Junior % Azioni Correttive?

18 Test Design Test Planning Test Case/Script Design Workload Design Test Execution Software Validation Test Management

19 Test Design: Review dei Requisiti

20 Test Design: Review dei Requisiti

21 Attributi di Qualità di un Requisito Un Requisito di Qualità ha i seguenti attributi: Completo Consistente Corretto Non-Ambiguo Tracciabile Testable

22 Rivediamo i Seguenti Requisiti ID 1 Descrizione del Requisito All'inserimento di una carta Bancomat valida, il sistema controllerà il codice digitato dall'utente ed, in caso il controllo abbia avuto esito positivo, autorizzerà l'accesso alle funzioni di sportello 10 min 2 Nel caso in cui l'utente sbagli ripetutamente l'inserimento del PIN il sistema dovrebbe trattenere la carta bancomat 3 Il sistema deve negare l'erogazione dell'importo se è stato superato già il limite massimo di prelievo nella settimana precedente 4 Il sistema deve presentare la schermata di inserimenti PIN entro 30 secondi dall'inserimento della carta Se l'utente seleziona l'opzione "stampa ricevuta" il sistema deve stampare la ricevuta al termine della transazione Nel caso in cui il prelievo non sia disponibile il sistema deve presentare nella Home Page dell'applicazione il messaggio ("Prelievo non disponibile") Nel caso in cui il prelievo non sia disponibile il sistema potrebbe avvisare l'utente prima che questo inserisca il PIN 8 l'atm deve essere disponibile per una lasso ragionevole di tempo 9 Il sistema dovrebbe consentire il prelievo di valuta estera 10 Nel caso in cui cada la linea durante la transazione il sistema deve fare il roll-back 11 Il sistema deve presentare la schermata di inserimento PIN entro 25 secondi dall'inserimento della carta

23 Requirement Review: Soluzione ID Descrizione del Requisito Caratteristiche Osservazioni All'inserimento di una carta Bancomat valida, il sistema controllerà il codice digitato dall'utente ed, in caso il controllo abbia avuto esito positivo, autorizzerà l'accesso alle funzioni di sportello Nel caso in cui l'utente sbagli ripetutamente l'inserimento del PIN il sistema dovrebbe trattenere la carta bancomat Il sistema deve negare l'erogazione dell'importo se è stato superato già il limite massimo di prelievo nella settimana precedente Il sistema deve presentare la schermata di inserimenti PIN entro 30 secondi dall'inserimento della carta Se l'utente seleziona l'opzione "stampa ricevuta" il sistema deve stampare la ricevuta al termine della transazione Nel caso in cui il prelievo non sia disponibile il sistema deve presentare nella Home Page dell'applicazione il messaggio ("Prelievo non disponibile") Nel caso in cui il prelievo non sia disponibile il sistema potrebbe avvisare l'utente prima che questo inserisca il PIN Incompleto Incompleto, Ambiguo Incompleto, Ambiguo Manca la specifica sul formato del PIN (numerico,quante cifre) Quali info vengono controllate? Quanti tentativi? Dovrebbe? Contraddittorio Contraddice 11 Incompleto Ambiguo Quanto è il limite massimo? La settimana è lavorativa o calendariale? Per settimana precedente cosa si intende (LUN-DOM o i precedenti 7 giorni?) Manca la specifica sulle info contenute nel Report; che succede se manca la carta? se è finito il toner? Potrebbe? 8 l'atm deve essere disponibile per una lasso ragionevole di tempo Ambiguo, Incompleto Disponibile = (con denaro e On line) ragionevole? 9 Il sistema dovrebbe consentire il prelievo di valuta estera Incompleto, Ambiguo Se il sistema è multy country quale sarà la valuta estera permessa?dovrebbe? 10 Nel caso in cui cada la linea durante la transazione il sistema deve fare il roll-back Ambiguo manca la definizione di transazione (da quando parte a quando finisce) 11 Il sistema deve presentare la schermata di inserimento PIN entro 25 Contraddittorio secondi dall'inserimento della carta Contraddice 4

24 Raccolta dei Test Case E il documento che contiene gli scenari di test funzionali e i workload prestazionali a livello del singolo modulo a livello di più moduli (integrazione) a livello di sistema (scenari end-to-end) I dati di Test sono contenuti di solito in un foglio excel allegato Raccolta dei Test Case

25 Test Design - Social Network: facebook Upload del File (TR01) 10 min Precondizioni: L utente è autenticato e ha selezionato il link Notizie 1 L utente digita un testo e seleziona il link Foto Il sistema mostra il box con le opzioni per caricare/scattare la foto 2 L utente seleziona il link Carica una foto dall unità il sistema da la possibilità di cercare la foto sul HD dell utente

26 Social Network: facebook Upload del File (TR01) 3 L utente seleziona il file dal proprio HD e clicca su condividi (vedi BR-01) Il sistema mostra la foto sulla bacheca dell utente secondo BR-02 <BR-01: la foto deve essere in formato JPEG o BMP e deve avere una dimensione inferiore a 5 MB> <BR-02: la foto diviene visibile nella bacheca dell utente ai suoi amici a seconda delle seguenti impostazioni Tutti: visibile a tutti Solo amici: visibile solo agli amici Amici degli amici: visibile agli amici fino al secondo livello> <BR-03: l utente può annullare in ogni momento il caricamento della foto premendo il pulsante chiudi X >

27 Social Network: facebook (Soluzione) azione/condizione R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 Foto formato JPEG T T T F F F F T F - Foto formato BMP F F F T T T F F T - Foto inferiore a 5MB T T T T T T - F F - Premuto pulsante chiudi? F F F F F F F F F T Privacy= tutti T F F T F F Privacy = amici F T F F T F Privaci = amici^2 F F T F F T Foto condivisa x x x x x x Errore: dimensione eccessiva x x Errore: formato sconosciuto x Condivisione annullata x TS01: Main Success TS02: Dimensione Eccessiva TS03: Formato sconosciuto TS04: Condivisione annullata Perché non abbiamo fatto alcuno scenario circa il caricamento del file (browse) ad esempio: - File non trovato - Nome del file non consentito /?

28 Test Execution Test Planning Test Case/Script Design Workload Design Test Execution Software Validation Test Management

29 Test Execution (Zoom in) Creazione Build Code Inspection Black Box Testing Load Test Stress Test Regression Test (Peer Review) Guerrilla Testing Deploy in Test Functiona l Test Performan ce Test Acceptanc e Test Smoke Test Memory Leack Detection Bug Fixing Tuning E il White Box?

30 Ciclo di Vita di Una Change Request Tester Developer SW Analyst Apertura del Difetto Sviluppo Verifica Test Stato del Difetto Verified Fixed Fixed In Progress New/Open Consegna della Release Build della nuova Relase senza il difetto

31 Ciclo di Vita di Una Change Request (Advanced)

32 Attributi di una Change Request Severity + Priority = Triage Status: lo stato in cui si trova la CR; Type: tipo di CR; Severity: low, medium, high; Priority: grado di urgenza con cui la CR deve essere risolta (da 1 a 3); Last build tested: la build label dove la CR è stata aperta; Addressed in build: la build label dove la CR è stata risolta (fixed); Synopsis: breve testo che identifica la CR;

33 Triage Fare il Triage di un Bug vuol dire qualificarlo assegnando in particolare Severity & Priority S1 - Urgent/Showstopper. Like system crash or error message forcing to close the window. Tester's ability to operate the system either totally (System Down), or almost totally, affected. A major area of the users system is affected by the incident and it is significant to business processes. S2 - Medium/Workaround. Exist like when a problem is required in the specs but tester can go on with testing. Incident affects an area of functionality but there is a work-around which negates impact to business process. This is a problem that: a) Affects a more isolated piece of functionality. b) Occurs only at certain boundary conditions. c) Has a workaround (where "don't do that" might be an acceptable answer to the user). d) Occurs only at one or two customers. or is intermittent S3 - Low. This is for minor problems, such as failures at extreme boundary conditions that are unlikely to occur in normal use, or minor errors in layout/formatting. Problems do not impact use of the product in any substantive way. These are incidents that are cosmetic in nature and of no or very low impact to business processes.

34 Test Summary Report E il documento che contiene i risultati di uno più Run di Test a livello del singolo modulo a livello di più moduli (integrazione) a livello di sistema (scenari end-to-end) Test Summary Report

35 Test Summary Report Velocità Apertura bug open / day Velocità Chiusura bug closed / day Cumulativo Bug Aperti Backlog Cumulativo Bug Chiusi BackLog = Bug Aperti Bug Chiusi

36 Test Summary Report Velocità Apertura bug open / day Velocità Chiusura bug closed / day Zona Divergenza Velocità Apertura bug open / day < Velocità Chiusura bug closed / day Zona Convergenza #Bug D #Bck D C C t t

37 Test Summary Report: Analisi Single Test Run Backlog Numero totale di TC da eseguire = 100 Bug Attesi = 120 Target: eseguire tutti i TST entro 20/05 Risolvere tutti i Bug entro 20/05 # BUG/#TC 01/05/10 02/05/10 03/05/10 04/05/10 05/05/10 06/05/10 07/05/10 08/05/10 09/05/10 10/05/10 11/05/10 12/05/10 13/05/10 14/05/10 15/05/10 16/05/10 17/05/10 18/05/10 19/05/10 20/05/10 Time= 11 days Data Aperti Chiusi TC Eseguiti

38 Test Summary Report: Analisi Velocità Apertura (4days) = 0 Velocità Chiusura (4days) = 20/4 = 5 BackLog = = 25 Se manteniamo le cose così ce la facciamo?

39 Test Summary Report: Analisi Velocità Apertura (4days) = 0 Velocità Chiusura (4days) = 20/4 = 5 BackLog = = 25 Se manteniamo le cose così ce la facciamo? E i Casi di Test?? Velocità Esecuzione (4 days) = 0 Velocità Esecuzione (prima blocco) = 5,8 Proiezione TST al 20/05 = 5,8 * = 87

40 Test Summary Report: Analisi Velocità Apertura (4days) = 0 Velocità Chiusura (4days) = 20/4 = 5 BackLog = = 25 E i Bug Non Scoperti? Nascosti = Attesi (120) - Trovati (70) = 50 Backlog Totale (Nascosti + aperti) = = 75 75/5 = 15 giorni!!!! La situazione potrebbe essere peggiore!!! Densità reale 2Bug/TST 200 Defect

41 Azioni Correttive? E il contrario? Aggiungo un Tester? (aumento velocità di Test) Aggiungo un Developer? (aumento velocità di BugFixing) E sufficiente?

42 Piano di Collaudo E il documento che disciplina lo svolgimento del collaudo contiene informazioni sulla pianificazione del collaudo le precondizioni minime affinchè il collaudo sia valido una raccolta degli casi di test che possono essere a livello della singola funzionalità scenari di business (end to end) Richiede approvazione da parte del cliente Piano di Collaudo

43 Questions?

44 Thank You for Your Attention! Software Testing Fabio Rabini