Il documento descrive le procedure di Software Quality Assurance (SQA) e Software Quality Control (SQC) necessarie per garantire che i processi e i prodotti software soddisfino standard di qualità. Illustra le diverse tecniche di testing, siano esse statiche o dinamiche, e i vari livelli di test, evidenziando l'importanza di una pianificazione e progettazione accurata del processo di test. Viene anche sottolineato il ruolo cruciale del testing nel rilevare difetti e migliorare la qualità del software.

1. Software Quality Assurance & Control

2. Software Quality Assurance & Control
 SQA - Insieme di procedure per assicurare che i processi, metodologie e
standard siano appropriate e correttamente implementate per lo
sviluppo di un prodotto sw
 Orientato al Processo
 SQC - Insieme di procedure per assicurare che un prodotto sw raggiunga i
propri obiettivi di qualità
 Orientato al Prodotto
 Software Testing - Principale attività di SQC
Il Testing non assicura la qualità…la controlla!

3. Software Quality Assurance & Control
 SQA
 Modello di sviluppo (es: Waterfall)
• Raccolta dei requisiti completata  Analisi Funzionale  Sviluppo
 Standard
• ISO 9001
 SQC
 Requisiti Funzionali
 Requisiti NON-Funzionali
 Verifica - Corretto funzionamento (Requisiti di Sistema)
 Validazione - Corretta implementazione (Requisiti Utente)

4. Software Testing
Indagine condotta per fornire le informazioni relative alla
qualità del sistema sotto esame.
Misura della qualità in termini di numero di difetti rilevati
Rilevando difetti si aumenta la qualità del sistema in seguito alla loro
correzione
L’obiettivo del Testing è rilevare il maggior numero di difetti

5. Software Testing
 Il Testing prova la presenza di difetti, non l’assenza
 Anche se nessun difetto viene trovato questa non è una prova di correttezza
 Il Testing esaustivo non è possibile
 Effort troppo elevato per provare tutti i possibili input
 Anticipare il Testing il prima possibile
 Per abbassare i costi di risoluzione e l’effort di Test successivo
 Il Testing dipende dai contesti
 Sistemi safe-critical vs E-Commerce
 Il Testing non è Debugging
 Fallimento vs Causa

6. Software Testing – Tecniche – Test Statico
Test Statico
 Basato sulla revisione (esame manuale) della documentazione e sull’analisi
statica (esame automatico) del codice
 Un difetto nell’analisi inevitabilmente si ritrova nel software
 Mancanze nei requisiti
 Si approfondisce la conoscenza del business anticipando il test design
 L’obiettivo è trovare anomalie e non fallimenti
 Revisione (review)
 Revisione Informale
 Walkthrough
 Revisione Tecnica
 Ispezione

7. Software Testing – Tecniche – Test Statico
Revisione Informale
 Propedeutica ad una revisione tecnica o walkthrough
 Solitamente svolta in coppia (peer)
 Documentazione opzionale
 Obiettivo: confronto
Walkthrough
 Condotta dall’autore
 Peer Group
 Solitamente documentata se svolta in sessioni
 E’ necessaria preparazione dei partecipanti (revisione informale)
 Obiettivo: acquisizione di informazione e rilevamento anomalie

8. Software Testing – Tecniche – Test Statico
Revisione Tecnica
 Condotta da un moderatore
 Peer Group ed esperti tecnici
 Documentata, metodi ben definiti
 Obiettivo: decisioni, rilevamento di anomalie, aderenza a standard e processi
Ispezione
 Condotta da un moderatore
 Peer examination e ruoli ben definiti
 Documentata, follow-up, checklist con I/U
 Obiettivo: rilevare anomalie

9. Software Testing – Tecniche – Test Statico
Analisi Statica
 Utilizzo di strumenti (compilatori, control & data flow check)
 Uso di metriche  rilevazione di elevata misura di complessità
 Rilevazione di codice morto, cicli infiniti, dipendenze e inconsistenze
 Identificazione di anomalie non facilmente rilevabili con il test dinamico

10. Software Testing – Tecniche – Test Dinamico
Test Dinamico
 Basato sull’esecuzione del codice
 Vengono rilevati i fallimenti, e cioè esiti negativi (effetti di un anomalia)
 Test Funzionale e Non-Funzionale
 Black-Box Testing
 Partizionamento in classi di equivalenza
 Analisi ai valori limite
 Tabelle delle decisioni
 Diagrammi di transizioni tra stati
 Use Cases

11. Software Testing – Tecniche – Test Dinamico
 White-Box Testing
 Copertura delle istruzioni
 Copertura delle decisioni

12. Software Testing – Tecniche – Black-Box
Partizionamento in classi di equivalenza
 Viene partizionato il dominio di input: classi valide e non valide
 Un Test Case per ogni classe
 Si associano due classi (valida-non valida) per ogni condizione di input
Es: Funzione il cui dominio di input siano i mesi dell’anno
... -2 -1 0 1 .............. 12 13 14 15 .....
-------------|-------------------|---------------------
Partizione NON Valida 1 Partizione Valida Partizione NON Valida 2
EC1= 1 ≤ N ≤ 12 Rappresentante: 6
EC2= N < 1 Rappresentante: -3
EC3= N > 12 Rappresentante: 16

13. Software Testing – Tecniche – Black-Box
Analisi ai valori limite
 Complementare al metodo precedente
 Tiene in considerazione il comportamento ai margini delle classi di
equivalenza
 Solitamente vengono trovati più difetti utilizzando i valori limite
(massimo e minimo) di una partizione
EC1= 1 ≤ N ≤ 12 --- EC3= N > 12 ● Valori limite: 12, 13

14. Software Testing – Tecniche – Black-Box
Tabelle delle decisioni
Condizioni 1 2 3 4 5 6 7 8
Conto attivo Y Y Y Y N N N N
Conto coperto Y Y N N Y Y N N
Prelievi disponibili Y N Y N Y N Y N
Azioni
Consentire il Prelievo Y N N N N N N N
Trattenere Carta N N Y Y Y Y Y Y
Inviare Comunicazione N N Y Y N N N N

15. Software Testing – Tecniche – Black-Box
 Ogni colonna della tabella rappresenta un Caso di Test (2n, n= # condizioni)
 Alcuni Casi di Test sono privi di senso:
 Conto non attivo & Conto coperto
 Conto non attivo & Conto non coperto & Prelievi disponibili
 Se il valore di particolari condizioni non incide sulle azioni, relative colonne
possono essere rimosse
 Solitamente sono colonne vicine
 Le azioni sono le stesse
 Si tiene una colonna come rappresentante e si sostituisce il valore delle
condizioni diverse con ‘ – ‘ per indicare che il loro valore è ininfluente
 Si continua a rimuovere colonne finchè non ci sono colonne con le stesse
azioni o se la rimozione di una colonna comporta l’eliminazione di una
distinzione importante

16. Software Testing – Tecniche – Black-Box
Tabelle delle decisioni
Condizioni 1 2 3 4 5 6 7 8
Conto attivo Y Y Y Y N N N N
Conto coperto Y Y N N Y Y N N
Prelievi disponibili Y N Y N Y N Y N
Azioni
Consentire il Prelievo Y N N N N N N N
Trattenere Carta N N Y Y Y Y Y Y
Inviare Comunicazione N N Y Y N N N N

17. Software Testing – Tecniche – Black-Box
Tabelle delle decisioni
Condizioni 1 2 3 5
Conto attivo Y Y Y N
Conto coperto Y Y N -
Prelievi disponibili Y N Y -
Azioni
Consentire il Prelievo Y N N N
Trattenere Carta N N Y Y
Disattiva Conto N N Y N

18. Software Testing – Tecniche – Black-Box
Diagramma degli stati B
Prelievo [Prelievi disponibili > 0 & Saldo Conto > -500 €]
1 A 2 3
Deposito Conto Prelievo Conto
Conto Attivo
Coperto Saldo ≤ -500 € Scoperto
C
D
Deposito Prelievo
TC1= 1 – A – 2 – C – 3 – D – 4 E
TC2= 1 – A – 2 – B – 2 – B – 2 4
Conto
NON
Attivo

19. Software Testing – Tecniche – Black-Box
Diagrammi delle transizioni tra stati
 Gli output non sono influenzati solo dagli input ma da eventi
 Stato iniziale  Stati intermedi  Stato finale
 Eventi occorsi nel tempo (storia) influenza il comportamento dell’oggetto
di test
 Object-oriented
 Diagramma degli stati, macchina a stati finiti, tabelle di transizioni degli
stati

20. Software Testing – Tecniche – Black-Box
Albero delle Transizioni
1
TC1= 1 – A – 2 – C – 3 – D – 4
A
TC2= 1 – A – 2 – B – 2 – B – 2
2
B C
2 3
B D
2 4

21. Software Testing – Tecniche – Black-Box
Use Cases
 I Test Cases sono ricavati dagli Use Cases dell’analisi
 Test Cases business oriented
 Particolarmente utili per il test d’integrazione

22. Software Testing – Tecniche – White-Box
Copertura delle istruzioni
 Si valuta la % di istruzioni eseguite da una famiglia di test (Test Suite)
 L’obiettivo è aumentare la copertura delle istruzioni
 # istruzioni eseguibili attivate dai Casi di Test (Test Cases) / # totale di istruzioni eseguibili
 Particolarmente utili per il test d’integrazione
 Si traduce il codice sorgente in un grafo del flusso di controllo
 Nodi = Istruzioni non divisibili
 Archi = flusso di controllo

23. Software Testing – Tecniche – White-Box
Grafo del Flusso di Controllo
A
B
TC= A – B – F – G – H – D – E IF
F
IF
DO C
L
G I
WHILE
H
END IF
END IF
D
E

24. Software Testing – Tecniche – White-Box
Copertura delle decisioni (branch coverage)
 Si valuta la % di decisioni eseguite da una famiglia di test (Test Suite)
 L’obiettivo è aumentare la copertura delle decisioni
 # decisioni eseguibili attivate dai Casi di Test (Test Cases) / # totale di decisioni
eseguibili
 E’ una forma di testing del flusso di controllo, ma ogni decisione deve
essere eseguita con entrambi i possibili risultati (Vero/Falso)
 La copertura del 100% delle decisioni  La copertura del 100% delle
istruzioni
 Ma non il contrario

25. Software Testing – Tecniche – Test Espolorativo
Test Espolorativo (Exploratory Testing)
 Basato sull’esperienza/intuizione dei testers
 Partecipazione cognitiva
 Usato in unione alle altre tecniche per rafforzarle
 Error guessing
 Utile quando la documentazione è povera e le tempistiche ristrette

26. Software Testing – Tipologie – Test Funzionale
Test Funzionale
 Si verifica il comportamento del sistema in termini di funzionalità:
 Idoneità
 Correttezza
 Interoperabilità
 Verifica il software testandolo rispetto a :
 Specifica dei requisiti
 Specifica Funzionale
 Use-Cases

27. Software Testing – Tipologie – Test Funzionale
 I Test Cases vengono disegnati applicando tecniche di tipo Black-Box:
 Equivalent class partitioning
 Boundary Value Analysis
 Error Guessing
 Può essere applicato a tutti i livelli di test:
 Test di Modulo
• Test Funzionale basato sui requisiti (Requirements-based testing)
 Test d’Integrazione
• Test Funzionale basato sui processi business

28. Software Testing – Tipologie – Test NON Funzionale
Test NON Funzionale
 Si verificano attributi non funzionali, quali:
 Affidabilità
 Efficienza
 Usabilità
 Manutenibilità
 Portabilità
 Compatibilità
 Per verificare le caratteristiche non funzionali di un sistema software è
utile riutilizzare i Test Cases disegnati per il test funzionale
 Business Process Scenarios – I test funzionali servono per veicolare la
determinazione delle caratteristiche non funzionali

29. Software Testing – Tipologie – Test NON Funzionale
 Performance, Load, Stress Test – Efficienza
 Endurance Test – Affidabilità
 Esecuzione di task predefiniti da parte di un focus group – Usabilità
 Thinking –aloud
 Interviste,
 Questionari
 Test della documentazione tecnica e della struttura del software –
Manutenibilità
 Test di compatibilità per SO, browser, piattaforme differenti –
Compatibilità

30. Software Testing – Livelli
I livelli del Test
 I livelli di test vengono identificati a seconda della fase del processo di
sviluppo software (e indipendentemente dal modello seguito):
 Test di Modulo
 Test di Integrazione
 Test di Sistema
 Test Confermativo
 Test di Regressione
 Test di Accettazione

31. Software Testing – Livelli
Test di Modulo
 Verifica del corretto funzionamento di componenti testabili
separatamente
 Possono essere applicate sia tecniche White che Black-Box
 Unit Testing
 Test di copertura (istruzioni/decisioni)
 Test Funzionale di Modulo
 Test non funzionali di performance (memory leaks, stored procedure
execution time)
 Approccio automatico
 Test Driven Development
 Test il più esaustivo possibile

32. Software Testing – Livelli
Test di Integrazione
 Verifica della corretta interazione tra moduli
 E’ prioritaria l’interazione rispetto alle funzionalità implementate dai
singoli moduli
 Due approcci principali:
 Top-down – Vengono integrati per primi i moduli ad alto livello
 Bottom-up – Vengono testati per primi i moduli di utilità
 Umbrella – Test eseguiti secondo i percorsi funzionali dei dati e del flusso di
controllo (business process oriented)

33. Software Testing – Livelli
Test di Sistema
 Verifica il corretto funzionamento dell’intero sistema software
 L’ambiente di test deve corrispondere il più possibile a quello finale
 Test Cases Business Process Oriented
 A differenza degli altri livelli di test è fondamentale l’utilizzo di un team di
test indipendente
 Unitamente al Test Confermativo e di Regressione, l’output deve essere la
versione che sarà sottoposta a Test di Accettazione (candidate release)

34. Software Testing – Livelli
Test Confermativo
 Per ogni livello di test un certo numero di difetti viene rilevato, e questi
devono essere risolti dal team di sviluppo
 Il Test Confermativo ha come obiettivo il test puntuale delle risoluzioni
 Il bug fixing viene validato
 Molto utili, in fasi avanzate del processo di sviluppo, strumenti che consentono
un fast-forwarding
 E’ molto importante tenere traccia della versione del software nella quale
le correzioni sono state validate
 In caso di regressioni future è più semplice risalire alla causa

35. Software Testing – Livelli
Test di Regressione
 E’ inevitabile che introducendo nuove funzionalità o apportando
correzioni (nuovi sviluppi) vengano introdotte regressioni su funzionalità
positivamente testate in precedenza
 L’obiettivo è verificare che il software non sia regredito a fronte di nuovi
sviluppi
 Vengono tipicamente esercitati Test Cases Business Process Oriented
 Dovrebbe essere automatizzato

36. Software Testing – Livelli
Test di Accettazione
 L’obiettivo è valutare il grado di maturità del sistema per approvarne il
rilascio ed utilizzo
 Solitamente sotto la responsabilità del Cliente, Stakeholder, Key-User
 L’obiettivo non deve essere la ricerca di difetti, ma valutare se il sitema
risponde ai requisiti espressi e se lo fa nel modo corretto/aspettato

37. Processo di Test
 Il Processo di Test viene portato avanti in cinque fasi:
 Pianificazione
 Progettazione/Design
 Implementazione
 Esecuzione
 Gestione delle Anomalie
 Ogni fase deve essere ben documentata
 Garantire la manutenibilità dei test
 Consentire la massima sinergia tra i gruppi di lavoro

38. Processo di Test - Pianificazione
Pianificazione
 Produce il Master (o Project) Test Plan Document
 Definizione del sistema oggetto di test
 Test Scope
 Obiettivi del Test
 Ruoli e Responsabilità
 Assunzioni, vincoli e rischi
 Glossario cn tutti i termini tecnici (SQC related) utilizzati
 Strategia, metodologia e tecniche di test utilizzate
 Strumenti di supporto utilizzati
 Ambienti di Test

39. Processo di Test - Pianificazione
 Configurazioni hardware e software
 Criteri di Ingresso/Uscita del Piano di Test
 La pianificazione in termini di date di inizio-fine e le risorse umane necessarie

40. Processo di Test - Progettazione
Progettazione
 Creazione delle Famiglie di Test (Test Suites)
 Collezione di Casi di Test (Test Cases)
 Identificazione di tutti i requisiti e delle “storie” dell’utente (use cases)
 Organizzazione gerarchica per area funzionale o cross-section
 Creazione dei Casi di Test (Test Cases)
 Costituiscono le specifiche di test
 Per ogni use case deve esistere almeno un test case (m ↔ n)
 Identificazione dei prerequisiti, dati necessari (setup), input, passi, risultato
aspettato
 Definizione dei criteri di ingresso/uscita

41. Processo di Test - Implementazione
Implementazione
 Si realizza ciò che è stato disegnato/progettato
 L’output è costituito da una collezione di:
 Test Suites
• Test Cases per l’esecuzione manuale
• Test Scripts per l’esecuzione automatica
 Data sets
 Configurazioni (scripts e/o documenti) - Riutilizzo
 Launch Test Document
• Setup e dati necessari
• Ordine di esecuzione

42. Processo di Test - Esecuzione
Esecuzione
 Le Test Suites e i Test Scripts preparati vengono eseguiti
 Manualmente
 In modo automatico con l’ausilio degli strumenti di supporto
 Per ogni Test Case (manuale/automatico) viene preparato il rapporto di
esecuzione (Execution Report)
 Stato di esecuzione (Passato, Fallito, Non Eseguito)
 Data di esecuzione e Versione del software oggetto di test
 Nome del Test Engineer che lo ha eseguito
 Viene preparato il Rapporto dei Test (Test Report)
 Viene preparato il Rapporto delle Anomalie (Anomalies Report)

43. Processo di Test – Gestione delle Anomalie
Gestione delle Anomalie
 Procedura fondamentale per avere un’analisi affidabile e veloce dei difetti
rilevati durante l’esecuzione del test
 Standard per il reporting dei difetti
 Informazioni per una rapida ricerca e comprensione
 Informazioni per la corretta riproducibilità
 Classificazione dei difetti
 Priorità
 Severità
 Ciclo di vita dei difetti
 Stati dei difetti

44. Contatti
Via Chiomonte, 26 – 10141 – Torino www.ixmasoft.it
0039.011.04.37.746 info@ixmasoft.it