1. Requirement
based
tes/ng
27
Giugno
2012
Gian
Giacomo
Ermacora
So-ware
and
Product
Consultant
per
Emeraso5
EMEA
Presale
Engineer
per
Polarion
So5ware
giangiacomo.ermacora@emeraso-.com

2. Webex
Webex
Microfono in mute
Per interventi e domande: chat o Q&A
Se non sentite l’audio:

3. Emerasoft: solution areas

4. Partner & Technologies
Business Intelligence
ePublishing
Polarion®
Application Lifecycle Management
Mainframe modernization
Modeling
Configuration Management

5. Alcuni cilenti

6. Agenda
§ Perché
è
criFco
avere
buoni
requisiF?
§ RBT
(Requirement
Based
Tes0ng),
cos'è,
perché
adoNarlo
§ La
tracciabilità
§ Polarion
Requirement
e
Polarion
QA
§ TesFng
session:
ü Definire
requisiF
e
test
case
in
Polarion
ü Disegnare
i
test
case
ü Creare
i
test
case
ü Esecuzione
dei
test
ü Verificare
i
risultaF
dei
test
ü Verificare
la
test
coverage
ü GesFre
e
tracciare
i
task
e
i
difeY
ü GesFre
la
test
library
§ Domande
e
Risposte
6

7. Perché
è
cri/co
avere
buoni
requisi/?
qualche
esempio
reale
7

8. Perché
è
criFco
avere
buoni
requisiF?
qualche
esempio
reale
In
ingegneria,
un
requisito
è
una
singolare
e
documentata
necessità
fisica
e
funzionale
che
un
parFcolare
prodoNo
o
servizio
deve
possedere.
E‘
comunemente
usato
nel
senso
formale
nell’ingegneria
dei
sistemi,
del
so-ware
engineering,
o
ingegneria
aziendale.
Si
traNa
di
un'istruzione
che
idenFfica
un
a:ributo
necessario,
capacità,
caraNerisFche,
o
la
qualità
di
un
sistema
per
produrre
un
valore.
8

9. Perché
è
criFco
avere
buoni
requisiF?
qualche
esempio
reale
Saturn
V
Per
vincere
la
gravità
terrestre,
un
veNore
deve
raggiungere
quella
che
viene
chiamata
la
“velocità
di
fuga”.
Questa
velocità
equivale
a
11,2
km/sec.
9

10. Perché
è
criFco
avere
buoni
requisiF?
qualche
esempio
reale
300
milioni
di
dollari
per
lo
sviluppo
e
manutenzione
so>ware
84
milioni
per
la
cancellazione
dei
progeY
mai
consegnaF
192
milioni
su
progeY
so-ware
la
cui
realizzazione
è
uscita
dai
tempi
e
budget
previs/
10

11. Perché
è
criFco
avere
buoni
requisiF?
qualche
esempio
reale
Lo
Standish
Gruoup
ha
anche
evidenziato
le
tre
principali
ragioni
per
le
quali
i
progeY
so-ware
hanno
fallito:
ü I
requisiF
e
le
specifiche
erano
incomple/;
ü I
requisiF
e
le
specifiche
cambiavano
troppo
spesso;
ü C’è
una
carenza
di
informazioni
da
parte
degli
utenF
finali
nei
requisiF.
11

12. Perché
è
criFco
avere
buoni
requisiF?
qualche
esempio
reale
Il
processo
RBT
risponde
ad
ognuno
di
quesF
tre
punF:
ü Si
introduce
durante
la
prima
fase
dello
sviluppo
so-ware,
dove
la
correzione
degli
errori
ha
un
costo
inferiore;
ü Si
introduce
nella
fase
della
raccolta
dei
requisi0,
dove
la
maggior
parte
dei
difeY
hanno
effeYvamente
luogo;
ü Risponde
in
modo
effeCvo
alla
crescita
della
qualità
dei
requisi0:
i
requisi/
inadegua/
sono
spesso
la
ragione
del
fallimento
del
progeNo.
12

13. Perché
è
criFco
avere
buoni
requisiF?
qualche
esempio
reale
Distribuzione
dei
bug
Codice,
7%
Altro,
10%
Design,
27%
RequisiF,
56%
13

14. Perché
è
criFco
avere
buoni
requisiF?
qualche
esempio
reale
Distribuzione
dell'effort
per
correggere
i
bug
Altro,
4%
Codice,
1%
Design,
13%
RequisiF,
82%
14

15. RBT
il
Requirement
Based
Tes0ng
cos'è,
perché
adoNarlo
15

16. RBT
il
Requirement
Based
Tes0ng
cos'è,
perché
adoNarlo
Il
Requirement
Based
Tes/ng
è
un
processo
aNo
alla
risoluzione
due
grandi
problemi:
ü la
validazione
dei
requisiF
ü la
progeNazione
dei
casi
di
test
16

17. RBT
il
Requirement
Based
Tes0ng
cos'è,
perché
adoNarlo
Nel
disegnare
i
casi
di
test
è
necessario
affrontare
due
quesFoni:
ü Avere
una
quan/tà
ragionevole
di
casi
di
test;
ü Assicurarsi
che
quesF
test
siano
davvero
efficaci
per
verificare
i
requisi0.
17

18. RBT
il
Requirement
Based
Tes0ng
cos'è,
perché
adoNarlo
La
strategia
del
Requirement
Based
Tes/ng
è
quindi
di
integrare
la
definizione
dei
test
durante
il
ciclo
di
vita
e
di
sviluppo
del
progeNo
stesso,
avendo
costantemente
in
mente
le
specifiche
ed
i
requisi0.
18

19. La
tracciabilità
traceability
19

20. La
tracciabilità
traceability
tracciabilità
Per
(o
traceability)
si
intende
la
possibilità
di
ricostruire
la
relazione
tra
i
vari
item
prodoY
nel
corso
di
un
progeNo.
E’
la
possibilità
di
ricostruire
le
relazioni
degli
elemenF
di
un
progeNo
con
le
specifiche
dei
requisiF
iniziali,
viene
deNa
tracciabilità
dei
requisi/.
ü La
tracciabilità
è
un
aspeNo
di
qualità
di
un
proge[o
fondamentale
per
una
vasta
gamma
di
aYvità,
come
l'analisi
degli
impaC
di
un
cambiamento
di
requisiF,
la
verifica
della
corre:ezza
di
un'implementazione
ed
il
tesFng.
20

21. La
tracciabilità
traceability
Nel
Require
Based
TesFng
quindi
assolutamente
fondamentale
avere
uno
strumento
che
ci
evidenzi
la
tracciabilità.
21

22. Polarion
Requirements
e
Polarion
QA
un
unico
tool,
dal
requisito
al
test
22

23. Polarion
Requirements
e
Polarion
QA
un
unico
tool,
dal
requisito
al
test
23

24. Polarion
Requirements
e
Polarion
QA
un
unico
tool,
dal
requisito
al
test
24

25. Polarion
Requirements
e
Polarion
QA
un
unico
tool,
dal
requisito
al
test
Configura/on
Cer/ficazioni
di
Test
Management
Qualità
e
Management
Conformità
Ges/one
Ges/one
Requisi/
Documentale
Ges/one
Repor/s/ca
Fornitori
Direzionale
Process
Polarion
E-­‐Collabora/on
Governance
So-ware
25

26. Polarion
Requirements
e
Polarion
QA
un
unico
tool,
dal
requisito
al
test
• CollaboraFon
ü GesFone
fornitori
ed
integrazione
dei
processi
fra
aziende
partner
ü efficienza
e
controllo
del
processo,
tempesFvità
delle
comunicazioni
ü l’individuazione
degli
aNori
e
la
definizione
delle
azioni
che
debbono
svolgere
a
fronte
di
ciascun
evento
ü ges0one
ordinata
e
controllata
dei
processi
aziendali
ü possibilità
di
verificare
in
ciascun
momento
lo
stato
del
flusso
di
lavoro
• Asset
Management
ü cosFtuiscono
una
ricchezza
per
l’azienda,
è
importante
gesFre
il
loro
ciclo
di
vita,
in
ogni
momento
il
loro
stato
e
le
correlazioni
fra
essi.
• Service
Delivery
e
Change
Management
ü requisiF,
configurazioni,
codice
so5ware,
testcase,
rilasci
integraF
ü iter
evolu0vo,
nuove
versioni,
regressioni,
autorizzazioni,
dismissioni
26

27. Polarion
Requirements
e
Polarion
QA
un
unico
tool,
dal
requisito
al
test
• GesFone
Documentale
ü documenF
in
formato
eleNronico
ü workflow
per
il
controllo
delle
fasi
di
processo
ü classificazione
avanzata
dei
documenF
ü consultazione
e
lavorazione
mulFutente/concorrente
di
Word
documents
ü Firma
digitale
• ReporFsFca
Direzionale
ü monitorare
processi
e
ciascuna
Fpologia
di
informazione
ü classificazione,
approvazione
e
archiviazione
dei
documenF
ü strumenF
di
sFma
budget,
analisi
pre/post
valutazioni
progeNuali
• CerFficazioni
di
Qualità
e
Conformità
ü Modelli
CMMI,
ISO,
Medical
Standard
IEC
62304
ü Reports
automaFci
e
live
27

28. Polarion
Requirements
e
Polarion
QA
un
unico
tool,
dal
requisito
al
test
28

29. Polarion
Requirements
e
Polarion
QA
un
unico
tool,
dal
requisito
al
test
Workitem descrive un artifact che vogliamo gestire e controllare in un progetto:
Può essere in relazione Segue un processo
con altri
Work item
Può avere una Può cambiare
pianificazione e mantenere la storia
29

30. Polarion
Requirements
e
Polarion
QA
un
unico
tool,
dal
requisito
al
test
Document
Requirement
Change Request
Task
Test
30

31. Tes/ng
session
ü Definire
requisiF
e
test
case
in
Polarion
ü Disegnare
i
test
case
ü Creare
i
test
case
ü Esecuzione
dei
test
ü Verificare
i
risultaF
dei
test
ü Verificare
la
test
coverage
ü GesFre
e
tracciare
i
task
e
i
difeY
ü GesFre
la
test
library
31

32. What’s
next
ContenuF
disponibili
su:
Canale
youtube
di
Emeraso-
Canale
slideshare
di
Emeraso-
Gruppo
linkedin
Polarion
Italy
www.emeraso-.com
www.polarion.com
Q& A ?

33. Grazie!
27
Giugno
2012
Gian
Giacomo
Ermacora
So-ware
and
Product
Consultant
per
Emeraso5
EMEA
Presale
Engineer
per
Polarion
So5ware
giangiacomo.ermacora@emeraso-.com
Emeraso5
University
Marcella
Arrabito
marcella.arrabito@emeraso-.com
011.19879273
33