Anatomia Funcional y Biomecnica Del Sistema Masticatorio Vpdf
IMI Formació Testing vPDF
-
Upload
xavier-c-cuadrado -
Category
Documents
-
view
103 -
download
3
Transcript of IMI Formació Testing vPDF
1
T O G E T H E RT A L E N T E DUnissons nos Talents
T O G E T H E RT A L E N T E D
Formació Testing ADINET 2009
Gener de 2009
Formació Testing ADINET 2009
2Formació Testing ADINET 2009
1. Fonaments i Gestió del Testing
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
3Formació Testing ADINET 2009
1. Fonaments i Gestió del TestingPer què és necessari el Testing?
Què és el Testing?
Processos Fonamentals del Testing
Organització de les proves
Pla de proves
Estimació de les proves
Monitorització i control del progrés de les proves
Gestió de riscos
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
4Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Context del software
On hi ha software? Funciona sempre correctament?
A qui pot afectar que un software no funcioni correctament? Companyia.
Pèrdues econòmiques, de temps, de reputació, ... Entorn.
Desbordament d’un tanc d’àcid, fuga de radiació, frens ABS, ...
Persones. Dispositius mèdics (marcapassos, etc).
El Testing és necessari!
5Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Motivació
El desenvolupament econòmic de qualsevol empresa es basa entre altres coses en el valor del seus sistemes informàtics. L’assegurament de la qualitat d’aquests sistemes esdevé un dels motors d’aquest desenvolupament.
El tester qualificat (i les activitats vinculades a les proves) no solament disposa dels coneixements pel seu treball diari, sinó que esdevé un factor influent del desenvolupament econòmic de la empresa.
6Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Error – Defecte - Fallada
Error (mistake): Acció realitzada per un ser humà que produeix un resultat incorrecte.
Defecte (fault/bug): És el resultat d’un error en el codi o en un document que provoca una desviació respecte el funcionament esperat. (p.ex. una sentència incorrecta o una definició de dades equivocada).
Quan s’executa, un defecte causa una Fallada.
Fallada (failure): Desviació del component o sistema respecte del resultat o funcionament esperat.
7Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Error – Defecte - Fallada
Una persona comet un error...
...que crea un defecte en el software o en un document,...
...que, al seu torn, provoca una fallada en el sistema
Una fallada és un succés; el defecte és un estat del producte, causat per un error.
8Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Error – Defecte - Fallada
És una acció realitzada per un ser humà que produeix un resultat incorrecte.
Quan els programadors cometen errors, introdueixen defectes al codi dels programes.
Els errors no són accidents o equivocacions evitables “anant amb més cura”, ni tampoc són un acte d'incompetència.
Els errors són inevitables en qualsevol activitat complexa.
És la manifestació d’un error en el software. Tambésón coneguts com a “bugs”.
Els defectes poden ser provocats per errors en els requisits, en el disseny o en la codificació.
Els defectes del software són estàtics (són trets del codi en el qual es troben).
Es poden descobrir, ja sigui inspeccionant el codi o deduint la seva existència a partir de les fallades.
És una desviació del software respecte al seu comportament esperat. Una fallada es produeix quan el software fa alguna cosa errònia o incorrecta.
Els defectes del software provoquen fallades quan els programes s’executen amb un conjunt d’entrades que evidencien el defecte.
Habitualment el software fa allò que és correcte, però a vegades falla.
Error FalladaDefecte
9Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Causes dels defectes
Errades humanes. Memòria a curt termini.
El ser humà només pot recordar entre 5 i 9 detalls importants a la vegada.
La memòria a curt termini es desborda. P.ex. oblidem definir o inicialitzar una variable.
Calendaris agressius / dates límit / pressió.
Complexitat del codi i de les infraestructures.
Tecnologia canviant.
Interacció de molts sistemes.
En el software existeixen defectes i les seves causes més comunes son:
Les condicions que afecten a l’entorn poden provocar errades:
Radiació, magnetisme, camps elèctrics, pol·lució.
Aquestes condicions poden afectar al firmware o al hardware i, com a conseqüència, a l'execució del software.
10Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?El paper del Testing
És important en:
El desenvolupament del software (p.ex. els desenvolupadors proven el seu propi software).
El manteniment: assegurar que millores i defectes corregits no afecten al funcionament del sistema.
Les operacions diàries: assegurar que el sistema continua funcionant.
Per tal de trobar defectes...
... de manera que quan siguin corregits,...
... es redueixin els riscos de tenir problemes en producció, i...
... contribueixi a incrementar la qualitat del producte que es posarà en producció.
El Testing pot ser un requisit legal o contractual.
Hi ha indústries que tenen els seu propis requisits a l’hora de fer proves.
P. ex. Mèdica, automoció, farmacèutica, ...
11Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Efectes dels defectes: Alguns exemples
El BMW 745i va ser retirat del mercat l’any 2003 per tal de resoldre un defecte de sincronització que podia provocar que el motor es calés, i no tornés a engegar!
Els errors dels programadors poden causar fallades de les quals mai ens assabentem o que tenen un impacte insignificant. Però alguns errors poden causar fallades dramàtiques i molt costoses:
En un programa FORTRAN que controlava la primera missió de la NASA a Venus, un programador va cometre l’error de posar un punt on hi havia d’haver una coma. La sonda MARINER I va explotar als pocs minuts d’enlairar-se. El projecte havia costat un mil milions de dòlars.
L’any 2000, un software defectuós en uns frens antiblocatge va comportar la retirada del mercat de 39.000 camions i tractors.
12Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Efectes dels defectes: Alguns exemples
El 4 de juny del 1996 en el seu primer vol la llançadora l’Ariane 5, prop de 40 segons després de l’enlairament i a una altitud de 3700 m, es va desviar de la seva trajectòria, es va partir i va explotar. La fallada va ser causada per la pèrdua d’informació d’orientació. Aquesta pèrdua va ser deguda a errors en l’especificació el disseny del software del sistema referència inercial.
El 23 de Setembre del 1999 la sonda espacial Mars Climate, enviada per la NASA per mantenir-se en òrbita marciana i estudiar el clima del planeta, es va estavellar a Mart va quedar completament destruïda.
Les extenses revisions i proves que s’havien realitzat durant el programa de desenvolupament de l’Ariane 5 no havien inclòs anàlisi i proves adequades del sistema de referència inercial o del sistema de comandament de vol complet, cosa que hauria pogut detectar el defecte potencial.
La programació dels sistemes de navegació i llançament de la sonda espacial havia anat a càrrec de dos laboratoris que no treballaven de la mateixa manera; l’un realitzava els seus mesuraments i proporcionava les seves dades en el sistema anglosaxó d'unitats (peus, milles, lliures, ....) mentre que l’altre utilitzava el Sistema Internacional d’unitats (metres, kilòmetres, kilograms, ...).
El cost global del projecte pujava a uns 125 milions de dòlars .
13Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?El Testing i la Qualitat
El Testing s’utilitza com a mesura de la Qualitat.
Allò que fa (funcionalitat) i com ho fa (característiques no funcionals).
Aporta confiança sobre la Qualitat d’un sistema si les proves estan ben realitzades.
Redueix els riscos.
Permet un increment de la Qualitat (quan els defectes són corregits).
Aporta “lliçons apreses”.
Causa arrel del problema i millora de processos.
El Testing ha de ser integrat amb l’assegurament de la Qualitat.
14Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Avaluant la Qualitat del Software
Baixa
Qua
litat
de
les
Prov
es
Qualitat del Software
Però podries estar aquí
Tu penses que ets aquí
Alta
Alta
Baixa
POCS POCS DEFECTESDEFECTES
POCS POCS DEFECTESDEFECTES
POCS POCS DEFECTESDEFECTES
MOLTS MOLTS DEFECTESDEFECTES
No es pot tenir una confiança justificada en la Qualitat del Software sense tenir confiança en la Qualitat del Testing.
15Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Quants camins d’un programa es poden provar?
Cada decisió té dues sortides. Quatre possibles camins.
En general: Camins = 2n
On n=número de decisions binàries.
Un nombre enorme en sistemes reals!
16Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Testing exhaustiu
Un Testing exhaustiu de tots els possibles camins de tots els programes és materialment impossible.
Un Testing exhaustiu de totes les entrades es materialment impossible.
Encara que poguéssim, moltes de les proves serien duplicades i no demostrarien res.
Es necessari, doncs, seleccionar proves que...
...siguin efectives (i trobin defectes).
...siguin eficients (no dupliquin “tests”).
17Formació Testing ADINET 2009
1.1. Per què és necessari el Testing?Com decidir quant Testing cal fer
L’abast del Testing a realitzar depèn dels següents factors:
Els riscos del sistema.
Riscos tècnics i de negoci (Producte / Projecte).
Expressats com la probabilitat i l’impacte en el temps.
Podem utilitzar els riscos per tal de prioritzar les proves, de manera que ho provem de la millor forma possible en el temps disponible.
Condicionants del projecte.
Temps / Pressupost.
Obligacions contractuals.
Un contracte pot obligar al proveïdor a cobrir el 100% del codi amb les proves.
En alguns sector (farmacèutic, aviació) existeixen estàndards amb la fi d'assegurar un Testing rigorós.
18Formació Testing ADINET 2009
1. Fonaments i Gestió del TestingPer què és necessari el Testing?
Què és el Testing?
Processos Fonamentals del Testing
Organització de les proves
Pla de proves
Estimació de les proves
Monitorització i control del progrés de les proves
Gestió de riscos
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
19Formació Testing ADINET 2009
Testing Estàtic
Testing Dinàmic
Verificació Verif. Verificació Verificació Verificació
requisits Anàlisi Disseny Construcció ProvesIntegrades
Enfoc. Proves
Planif. Proves
Gestió i Seguiment de Proves
Disseny de Proves
ExecucióProves
Avaluac.Sortida FI
1.2. Què és el Testing?Testing: Més que una simple execució
Cicle de Vida de Desenvolupament
Polítiques i Estratègies: Determinen l’enfocament dels Processos
Millora de Processos, incloent el de Proves
20Formació Testing ADINET 2009
1.2. Què és el Testing?Què és una prova amb èxit?
No! Trobar-hi defectes
Mostrar que el sistema funciona
Quina és la resposta correcta?
21Formació Testing ADINET 2009Formació Testing ADINET 2009
1.2. Què és el Testing?Objectius del Testing
Trobar defectes (Testing estàtic).
Assegurar el correcte funcionament Generar fallades (Testing dinàmic).
Guanyar confiança.
En relació al nivell de Qualitat. Proporcionar informació.
Prevenir defectes en el futur. A partir de l’aprenentatge extret de l'anàlisi de les causes i orígens dels defectes, i millorant els processos.
En relació als Riscos. Avaluar i mitigar els riscos.
Els objectius del Testing també depenen del seu nivell d’aplicació.Hi ha objectius diferents per a proves unitàries, proves d'integració, funcionals i d’acceptació.
22Formació Testing ADINET 2009
1. Fonaments i Gestió del TestingPer què és necessari el Testing?
Què és el Testing?
Processos Fonamentals del Testing
Organització de les proves
Pla de proves
Estimació de les proves
Monitorització i control del progrés de les proves
Gestió de riscos
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
23Formació Testing ADINET 2009
1.3. Els Processos fonamentals del Testing
Planificació i Control
Anàlisi i Disseny i Implementació
Execució
Avaluació dels criterisde Finalització i Reporting
Activitats de Tancamentde Proves
Aquests processos s’apliquen sobretot en
entorns de proves formals
Aquestes activitats poden ser seqüencials o
concurrents (poden solapar-se)
24Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingPlanificació i Control de les Proves
Planificació de proves.
Confirmar la missió del Testing i definir els objectius. Especificar les activitats a realitzar per tal d’acomplir-los.
Per poder fer un seguiment del Testing, s’avança en allò que seràmonitoritzat i com es farà.
Control de proves.
Comparar el progrés actual amb el que hi ha establert al pla.
Reportar l’estat (incloent les desviacions respecte el pla). Prendre mesures per tal d’acomplir la missió i els objectius. Monitoritzar durant tot el projecte.
Planificació i Control Anàlisi Disseny i Implementació Execució Avaluació Finalització i Reporting Activitats Tancament Proves
25Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingTasques de la Planificació de les Proves
Planificació (Estratègia)
Implementar una política o estratègia de proves (si aplica).
Determinar l’abast, els riscos i els objectius del Testing. Determinar el millor enfocament del Testing
Tècniques, número de proves, cobertura, eines, equips...
Determinar els recursos necessaris.
Persones, hardware, software, entorns...
Determinar els criteris d’inici i de finalització.
Establir el calendari de les tasques d'anàlisi i de disseny.
Establir el calendari de l’implementació, execució i avaluació de resultats.
Resultat: Pla de Proves específic per a cada nivell de Testing.
Planificació i Control Anàlisi Disseny i Implementació Execució Avaluació Finalització i Reporting Activitats Tancament Proves
26Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingTasques del Control de les proves
Control (Estratègia)
Mesurar i analitzar els resultats.
Monitoritzar i documentar:
El progrés. La cobertura de les proves. Els criteris de finalització.
Iniciar accions
Principalment correctives. Poden ser preventives.
Prendre decisions.
Planificació i Control Anàlisi Disseny i Implementació Execució Avaluació Finalització i Reporting Activitats Tancament Proves
27Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingActivitat d’Estratègia proposta ADINET
Formació Testing ADINET 2009
0 Definir estratègia de proves0.A1 Aspectes crítics a assegurar i objectius a aconseguir 0.A2 Planificació activitats de proves0.A3 Vist-i-plau estratègia i planificació0.A4 Enumeració tipus i casos de prova
* Extracció de les activitats de proves de la Metodologia ADINET
28Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingAnàlisi i Disseny de les Proves
Revisar la base de proves (Requisits, arquitectura, disseny, interfícies), i avaluar si es susceptible de ser provat.
Identificar les condicions de proves i les dades de proves en les quals es basen.
Establir el nombre de proves, així com la seva especificació, comportament i estructura.
Dissenyar les proves.
Avaluar la “testejabilitat” del sistema.
Dissenyar l'entorn de proves.
Identificar qualsevol infraestructura o eina necessària.
Durant aquesta fase els Objectius de les Proves són traduïts a Condicions de Proves, i es dissenyen les proves en si. (Creació)
Planificació i Control Anàlisi Disseny i Implementació Execució Avaluació Finalització i Reporting Activitats Tancament Proves
29Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingActivitat de Creació proposta ADINET
Formació Testing ADINET 2009
1 Definir casos de proves funcionals i d’acceptació1.A1 Identificació/selecció funcionalitat crítica o amb riscos1.A2 Definir casos de prova funcionals1.A3. Seleccionar casos de prova d’acceptació1.A4. Vist-i-plau de les proves
2 Definir casos de proves d’ integració2.A1 Identificació components arquitectura i/o
disseny crítica o amb riscos 2.A2 Definir casos de prova 2.A3. Vist-i-plau de les proves
3 Definir casos de proves d’estrès (opcional)3.A1 Identificació components arquitectura i/o disseny crítica o amb riscos 3.A2 Definir casos de prova 3.A3. Vist-i-plau de les proves
4 Definir Test de Regressió4.A1. Seleccionar els casos de test a executar4.A2. Definir l’entorn de test
I1 Implementació i tests unitarisI1.A4 Dissenyar e implementar tests unitaris
* Extracció de les activitats de proves de la Metodologia ADINET
30Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingTasques de l’execució de les Proves
Executar els casos de proves d’acord a les seqüències planificades.
Registrar les sortides, els números de versió del software, les eines, etc. en un “log” o registre de les proves.
Comparar els resultats obtinguts amb els esperats.
Reportar les discrepàncies com incidències, analitzant-ne les causes:
Defectes en el codi, dades de proves, documentació, procediments...
Repetir les activitats de proves tant com sigui necessari.
P.ex. proves de confirmació després que un defecte en el codi hagi estat corregit. Proves de regressió després de fer canvis.
Planificació i Control Anàlisi Disseny i Implementació Execució Avaluació Finalització i Reporting Activitats Tancament Proves
31Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingActivitats d’Execució proposta ADINET
Formació Testing ADINET 2009
I1 Implementació i tests unitarisI1.A5 Execució de tests unitaris I1.A6 Revisió test unitari
5 Executar proves d’integració5.A1. Preparar entorn de test5.A2. Executar els tests5.A3. Avaluar els resultats
6 Execució proves càrrega(opcional)6.A1. Preparar entorn de test6.A2. Executar els tests6.A3. Avaluar els resultats
7 Execució tests qualitat de codi7.A1. Executar les validacions7.A2. Avaluar els resultats
8 Execució tests de regressió8.A1. Executar les validacions8.A2. Avaluar els resultats
9 Executar proves funcionals i d’acceptació9.A1. Preparar entorn de test9.A2. Executar els tests9.A3. Avaluar els resultats
* Extracció de les activitats de proves de la Metodologia ADINET
32Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingAvaluació dels Criteris de Sortida i Reporting (1/2)
Comprovar, per a cada nivell de proves, els criteris de sortida especificats al pla de proves per tal de veure si s’han acomplert o no els objectius planificats de les proves.
Tasques:Confrontar els logs de proves amb els criteris de finalitzacióespecificats al pla de proves.
Valorar si són necessàries més proves o bé és necessari modificar els criteris de finalització.
Redactar un informe sumari de proves per a les persones relacionades amb l’aplicació (stakeholders).
Planificació i Control Anàlisi Disseny i Implementació Execució Avaluació Finalització i Reporting Activitats Tancament Proves
33Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingAvaluació dels Criteris de Sortida i Reporting (2/2)
Característiques de la Corba-S
Fase1: (Lenta) Inici – No més del 15% al 25% d’errors detectats.Fase2: Productiva – No més del 55% al 65% d’errors detectats.Fase3: Proves difícils – No més del 10% al 25% d’errors detectats.
Planificació i Control Anàlisi Disseny i Implementació Execució Avaluació Finalització i Reporting Activitats Tancament Proves
34Formació Testing ADINET 2009
1.3. Processos Fonamentals del TestingActivitats de Tancament de les Proves
Consolidar l'experiència, testware, ... d'acord amb dades de les activitats acabades. També se pot efectuar quan un projecte és cancel·lat, després d’una fita o d’un manteniment.
Tasques. Comprovar els lliurables previstos, tancar incidències, plantejar canvis en el documents d’acceptació del sistema. Finalitzar i arxivar el testware, l’entorn i la infraestructura per garantir una possible reutilització posterior. Entregar el testware als responsables del manteniment. Analitzar les lliçons apreses, millorar la maduresa de les proves. Comunicar aquests resultats a aquells que duran a terme les proves la pròxima vegada.
Planificació i Control Anàlisi Disseny i Implementació Execució Avaluació Finalització i Reporting Activitats Tancament Proves
35Formació Testing ADINET 2009
1. Fonaments i Gestió del TestingPer què és necessari el Testing?
Què és el Testing?
Processos Fonamentals del Testing
Organització de les proves
Pla de proves
Estimació de les proves
Monitorització i control del progrés de les proves
Gestió de riscos
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
36Formació Testing ADINET 2009
1.4. Organització de les provesIntroducció a la gestió del testing
Si volem un testing efectiu necessitem
Organització:
Equips de proves o persones amb rols de testing, però el primer és més
recomanable
Responsabilitats
Gestió
Riscos
Estimacions
Monitoritzacions
Control
Seguiment
37Formació Testing ADINET 2009
1.4. Organització de les provesDiferents punts de vista
Per trobar el major número de defectes necessitem diferents punts de vista i quan abans en el cicle de vida.
Fallades
Temps
Perquè els usuaris tenen una visió diferent del sistemaUsuari final
38Formació Testing ADINET 2009
1.4. Organització de les provesOrganització de les proves i independència
Només els desenvolupadors proven el seu codi.No són independents.
Els desenvolupadors proven el codi d’altres.
Testers en el equip de desenvolupament.
El equip de proves reporta al Project Manager o més amunt.
Testers de negoci i tecnologies.
Testers especialistes (certificacions, seguretat).
Testers d’una organització externa.
inde
pend
ènci
a
39Formació Testing ADINET 2009Formació Testing ADINET 2009
1.4. Organització de les provesExemples de independència
Sistemes grans, complexes i de seguretat crítica.
Varis nivells de prova.
Testers independents en alguns (o tots) els nivells.
Poden definir processos de proves i regles.
Proves a baixos nivells (unitàries) per altres desenvolupadors.
La escassa objectivitat del mateix que ha creat el codi limita l’efectivitat.
Aplicacions petites/mitjanes i no crítiques
Testing de components informal per part dels desenvolupadors.
Testing d’acceptació independent per part d’usuaris interns.
40Formació Testing ADINET 2009
1.4. Organització de les provesAvantatges i Desavantatges de la independència
Avantatges
Es detecten defectes diferents.
Imparcialitat.
Verificació de supòsits durant el
disseny i la construcció.
Punt de vista diferent no
condicionat.
Troba més errors.
Verificació independent.
Desavantatges
Aïllament respecte del equip de
desenvolupament.
Coll d’ampolla en el pas a
producció.
Sentiment de pèrdua de
responsabilitat en la qualitat per
part dels desenvolupadors.
41Formació Testing ADINET 2009
1.4. Organització de les provesQui fa les proves?
Les proves poden ser realitzades per persones que específicament tinguin aquesta responsabilitat:
Test leader. (Cap de Projecte)També conegut com a Test manager o Coordinador.
– En projectes grans poden ser dos llocs diferents
Testers. (Serveis Técnics)Diferents equips de proves.
Integrats en el equip de desenvolupament.
Poden ser fetes per:
Altres persones de la organització:Equip de projecte.
Responsable de qualitat.
Desenvolupador.
Experts.
Tècnics de suport.
42Formació Testing ADINET 2009
1.4. Organització de les provesTasques del Test Leader
Coordinar l'estratègia i la planificacióamb el cap de projecte.
Escriure i revisar la política i l’estratègia.
Contribuir a la perspectiva de les proves en el projecte.
Planificar les proves i adaptar el pla si es necessari.
Iniciar les tasques de proves.
Controlar les proves monitoritzantresultats.
Establir la Gestió de configuració. Rol específic de Cap de Projecte
Introduir les mètriques.
Decidir un enfocament d’automatització i seleccionar les eines.
Organització i formació.
Decidir l’entorn de proves.
Calendari de proves. Fer l’informe final de proves.
43Formació Testing ADINET 2009
1.4. Organització de les provesTasques del tester
Revisar i ajudar en la planificació de les proves.
Analitzar els requisits i les especificacions per a la testabilitat.
Descriure les especificacions de les proves.
Instal·lar i comprovar l’entorn de proves.
Preparar les dades de prova.
Fer les proves i catalogar els resultats.
Utilitzar les eines per catalogar les incidències i resultats.
Utilitzar eines d’automatització si es requereixen.
Analitzar les característiques del testing no funcional.
Revisar els tests fets per l’equip
44Formació Testing ADINET 2009
1. Fonaments i Gestió del TestingPer què és necessari el Testing?
Què és el Testing?
Processos Fonamentals del Testing
Organització de les proves
Pla de proves
Estimació de les proves
Monitorització i control del progrés de les proves
Gestió de riscos
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
45Formació Testing ADINET 2009
1.5. Pla de proves (Definició Estratègia)Influències del pla de proves
Pla de proves
Pla de proves de components
Pla de proves d’acceptació
Pla mestre de proves
Riscos
Restriccions
Criticitat
Disponibilitatde recursos
Àmbit de proves
Objectius
Política de Proves
46Formació Testing ADINET 2009
1.5. Pla de provesPla de proves (1/9)
Quin es el propòsit del pla de proves?Comunicar informació sobre el procés de proves.
Quina informació hauria de tenir un pla de proves?
Àmbit de treball.
Esforç de testing.
Recursos requerits.
Calendari.
El estàndard més conegut es el ANSI / IEEE 829 “Standard for Software Test Documentation”
47Formació Testing ADINET 2009
1.5. Pla de provesPla de proves (2/9)
1. Identificador del pla de proves.Número per identificar el pla de proves, el seu nivell i el nivell de software amb el que es relaciona.
2. Referències.Llista dels documents que recolzen el pla:
Pla de projecte.
Especificacions de requisits.
Documents de disseny.
Guies de metodologia i exemples.
Estàndards corporatius i guies.
3. Introducció.Resum executiu.Abast.
48Formació Testing ADINET 2009
1.5. Pla de provesPla de proves (3/9)
4. Objectes de les proves.Objectes a provar, el que es va a provar (aplicacions, documents,...) incloent la versió i revisió.Format (xarxa, disc, etc.)Referències a la documentació del software. Punt de vista tècnic.
5. Aspectes crítics del softwareIdentifica quin software va a ser provat i quines son les àrees crítiques, com:
Impactes sobre el client.
Habilitat per utilitzar i entendre el nou paquet / eina, etc.
Funcions extremadament complexes.
Seguretat...
49Formació Testing ADINET 2009
1.5. Pla de provesPla de proves (4/9)
6. Característiques a provar.Llista del que es va a provar des del punt de vista dels USUARIS(funcionalitats i processos).Similar al punt 4, varia en el punt de vista.
7. Característiques a no provar.Des del punt de vista dels usuaris. Raons.
8. Definició de proves.Tipus d’activitats, tècniques i eines.Detalls suficients per estimar.Identificar les restriccions (entorn, equip, data límit).
50Formació Testing ADINET 2009
1.5. Pla de provesPla de proves (5/9)
9. Criteris, correcte/incorrecte (per el que es prova) Criteris de sortida per projecte o fase.
Cobertura (codi o funcionalitat).Riscos residuals, defectes no arreglats o escassa cobertura.Quantitat de defectes o fiabilitat de les proves.Data de entrega.Pressupost gastat.
10.Criteris de suspensió i represa.Per totes o part de les activitats de proves.Quines activitats han de repetir-se o suspendre.
51Formació Testing ADINET 2009
1.5. Pla de provesPla de proves (6/9)
11.Documents a entregarEstratègia de provesDefinició pla de provesEspecificacions del disseny de provesEspecificacions dels casos de provesEspecificacions del procediment de proves.Informes resultat de les provesCatalogar les proves.Informes d’incidències.Informes del sumari de les proves.
Casos de Prova
Passos per executar els
casos
Condicions de prova
Què ha passat.
Donar informació
52Formació Testing ADINET 2009
1.5. Pla de provesPla de proves (7/9)
12.Tasques de les provesIdentificar àrees que no es poden provar.Tasques que afecten als equips de desenvolupament intern i externs (si existeixen).
13.EntornFísic, hardware, software, èines.Requisits de potència per a les màquines.Versions de software específics.Mode d’ús, seguretat, espai en la oficina.
14.Equip i formacióFormació en l’aplicació o en el sistema.Formació en qualsevol eina que es vagi a utilitzar.
53Formació Testing ADINET 2009
1.5. Pla de provesPla de proves (8/9)
15.ResponsabilitatsQui està al càrrec?Qui proporciona la formació?Qui decideix què fer amb les àrees no cobertes en el pla?
16.CalendariFites del projecte.Fites addicionals de les proves (entorn preparat).Quins recursos es necessiten i en quin moment.
17.Riscos i contingènciesPla de contingència per cadascuns dels riscos identificats.
És una bona ideaincloure pressupostos
54Formació Testing ADINET 2009
1.5. Pla de provesPla de proves (9/9)
18.Vist i plauNoms i quan aprovar-ho
19.GlossariS’utilitza per definir mots i acrònims utilitzats en el document i les proves en general, per eliminar confusions i promoure una comunicació consistent.
55Formació Testing ADINET 2009
1. Fonaments i Gestió del TestingPer què és necessari el Testing?
Què és el Testing?
Processos Fonamentals del Testing
Organització de les proves
Pla de proves
Estimació de les proves
Monitorització i control del progrés de les proves
Gestió de riscos
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
56Formació Testing ADINET 2009
1.6. Estimació de les provesEstimar el testing no es diferent d’altres activitats
Estimar qualsevol treball inclou:
Identificar les tasques.
Temps necessari per cadascuna de les tasques.
Qui fa cadascuna de les tasques.
Quan es té que començar i finalitzar.
De quins recursos disposem, quines habilitats.
Dependencies predicibles.
Prioritat de les tasques.
57Formació Testing ADINET 2009
1.6. Estimació de les provesEstimar el testing també es diferent
Raons d’aquestes diferencies
El testing no és una activitat independent.
Les proves depenen del desenvolupament
Es depèn del que entregui l’equip de desenvolupament sigui lo previst.
Si les entregues no van segons el previst caldrà canviar les dates.
L’entorn de proves és crític.
Si l’entorn de proves és inestable, es produirà un nou canvi de dates.
58Formació Testing ADINET 2009
1.6. Estimació de les provesMétodes estimatius, consideracions
Qualitat de les especificacions.
Grandària i complexitat de l’aplicació.
Requisits del testing no funcional.
Estabilitat i maduresa del procés de desenvolupament.
Tipus i lloc de l’entorn de proves.
Ús de les eines de prova.
Habilitats de l’equip involucrat.
Temps disponible.
Quantitat de treball per revisar.
59Formació Testing ADINET 2009
1.6. Estimació de les provesMètodes d’estimació
Percentatge de projectes previstos i similars.Si disposem d’un historial guardat d’anteriors projectes.
ExpertsDepèn de la seva experiència.
Altres, per proporcionar informació
Endevinar. Rebentar l’aplicació.
Anàlisi dels punts de proves
Punts de proves: son els punts funció del testing.
Model estimatiu.
60Formació Testing ADINET 2009
1. Fonaments i Gestió del TestingPer què és necessari el Testing?
Què és el Testing?
Processos Fonamentals del Testing
Organització de les proves
Pla de proves
Estimació de les proves
Monitorització i control del progrés de les proves
Gestió de riscos
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
61Formació Testing ADINET 2009
1.7. Monitorització i control del progrés de les provesMonitorizació del progrés de les proves, raons
Per proporcionar feedback i visibilitat de les activitats de proves.
Mostrar com es fa comparat amb el pla.
Quines mètriques s’utilitzen i per què.
Adequació dels objectius de proves.
Efectivitat de les proves respecte als seus objectius.
62Formació Testing ADINET 2009
1.7. Monitorització i control del progrés de les provesMètriques comunes
Percentatges / comparació
Casos descrits respecte al pla.
Execucions (executades si/no passen/fallen).
Actuals respecte a històrics.
Cost respecte al pressupost.
Informació de defectesTrobats / arreglats, percentatge de fallades, proves repetides.
Cobertura del codi o aplicació.
63Formació Testing ADINET 2009
1.7. Monitorització i control del progrés de les provesInforme de les proves
Fer un resum mostrant en quin punt de les proves s'està
Que ha passat durant les proves?
Coincideixen les dades amb els criteris de sortida?
Analitzar les mètriques i fer les recomanacions apropiades
Es pitjor continuar provant?
Quina és la situació amb riscos?
Confiem en que l’aplicació funciona?
64Formació Testing ADINET 2009
1.7. Monitorització i control del progrés de les provesControl de les proves
Accions preses segons l’informació de monitorització
Activitats de les proves o altres activitats del cicle de vida. Exemples:
Reprioritzar les proves quan apareix una fallada.
Canviar el calendari de proves segons la disponibilitat del entorn.
Concretar els criteris per donar per arreglat un error / bug (confirmat per el
desenvolupador).
65Formació Testing ADINET 2009
1. Fonaments i Gestió del TestingPer què és necessari el Testing?
Què és el Testing?
Processos Fonamentals del Testing
Organització de les proves
Pla de proves
Estimació de les proves
Monitorització i control del progrés de les proves
Gestió de riscos
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
66Formació Testing ADINET 2009
1.8. Gestió de riscosCicle de proves basats en riscos
Analitzar riscospotencials
Millorar el procésd’anàlisi de
riscos
Analitzar elsriscos actuals
Reportarproblemes
Realitzar el testingapropietat
Producció Desenvolupament
67Formació Testing ADINET 2009
1.8. Gestió de riscosEls beneficis del testing basat en riscos
No és necessari provar-ho tot!
Les proves poden estar focalitzades.
Els costs de les proves es poden reduir.
El Pla és molt flexible als canvis.
El èxit és més probable “on és més necessari”.
68Formació Testing ADINET 2009
1.8. Gestió de riscosPuntuació de riscos
Impacte i probabilitatPuntuar impacte (de 1 a 5).Puntar probabilitat (de 1 a 5).Multiplicar probabilitat per impacte.
MoSCoWEs imprescindible provar-ho (Must test).Hauria de provar-se (Should test).Pot provar-se (Could test).No es necessari provar-se (Won’t test).
Exposició: Quant està vostè exposat a un risc?
Detecció: Quina facilitat hi ha de mitigar un risc?
Indicador de criticitat: És una funció crítica d’usuari?
O probablement, combinacions de les anteriors.
69Formació Testing ADINET 2009
1.8. Gestió de riscosMoSCoW
Si això
falla,
Llavors…
Té conseqüències econòmiques pel nostre
client
No té conseqüències econòmiques pel nostre
client
No té conseqüències econòmiques pel nostre
client
Té conseqüències econòmiques pel nostre
departament
Tots els clients
Un client
Tots els clients
Un client
No hi ha solucióalternativa
Hi ha solució alternativa
S’ha de provar
S’hauria de provar
Es pot provar
No provar
No hi ha solucióalternativa
Hi ha solució alternativa
S’hauria de provar
Es pot provar
Es pot provar
No provar
70Formació Testing ADINET 2009
1. Fonaments i Gestió del Testing
2. Cicle de vidaEl model en V
Gestió i traçabilitat de requisits
Tipus de proves
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
71Formació Testing ADINET 2009Formació Testing ADINET 2009
2.1. El Model en V
Relacionat amb
Proves unitàries
Proves d’integració
Proves funcionals
Proves d’acceptació
Execucióde les Proves
Especificacions del Sistema(Anàlisi Funcional)
Especificacions del Disseny(Disseny Tècnic)
Requisits de Negoci
Codi
Documentació iDisseny de les Proves
Auditories, revisions de Documentació, etc.
Proves
Proves
Proves
Proves
72Formació Testing ADINET 2009
2.1. El model en VCaracterístiques del model en V
Els nivells de proves es corresponen amb els nivells de desenvolupament
Els 4 nivells de proves mostrats aquí son exemples. Poden ser més, menys o
diferents nivells.
P.ex. Components, integració, funcionals.
La base pel testing. El producte resultat del treball:P.ex. requisits, escenaris, casos d’us, disseny, etc.
Es realitza verificació i validació sobre els productes.
Referències genèriques del producte de treball:
CMMI IEEE / IEC 12207: “Procesos del ciclo de vida del software”.
73Formació Testing ADINET 2009
1. Fonaments i Gestió del Testing
2. Cicle de vidaEl model en V
Gestió i traçabilitat de requisits
Tipus de proves
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
74Formació Testing ADINET 2009Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsCaptura imprecisa de requisits
Un requisit és un objectiu documentat que l’aplicació ha de complir.
A vegades, els usuaris expressen els seus requisits d’un mode ambigu.
El negoci no sempre es quelcom lògic.
Els usuaris no sempre expliquen tots els seus requisits o no ho fan completament.
Els desenvolupadors no coneixen el negoci a la perfecció.
75Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsSabieu que...?
El 18% dels projectes no tenen els requisits que havia sol·licitat el client.
Només el 29% dels projectes compleixen amb els requisits i tenen beneficis.
El 51% dels projectes són posats en producció després de la data prevista inicialment.
Un 43% dels projectes excedeixen del seu pressupost original.
Problema número ú = requisits
El 56% dels defectes s’originen en la fase de requisits.
Un 25% dels costs innecessaris es deuen a sobretreballs deguts a requisits dolents.
76Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsDoncs...per què provar els requisits?
Un enfocament inconsistent té impacte sobre conseqüents activitats.
Redueix la multiplicació de defectes.
Assegura l’ajust al ús i al propòsit.
Redueix les possibilitats de malentesos
amb els proveïdors.
77Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsLes 8 regles dels requisits
Singular
No ambigu
Mesurable
Complet
Desenvolupable
Testejable
Orientat a resultats
Pertinència
78Formació Testing ADINET 2009Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsSingulars?
Son els requisits singulars
Dividir els requisits en
unitats úniques.
No superposar límits (no solapar).
Mai duplicar requisits.
Mantenir-se en els nivells
acordats de granularitat.
Solament les interrelacions
estrictament necessàries.
79Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsNo ambigus?
Son els requisits no ambigus?
No oberts a interpretacions.
No són opinions o històries.
Directes i al gra.
No estan plens d’argot.
Altres grups entendran
la definició del requisit.
No admeten suggeriments ni evasió.
Falten requisits.
Falten interlocutors per identificar
que puguin necessitar nous requisits.
80Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsMesurables?
Són els requisits mesurables?
Les mètriques específiques definides són utilitzades
apropiadament.
No hi ha expressions imprecises del tipus “la millor part
del temps”, “ús raonable”, “un número de”...
Rangs medibles específics que defineixin clarament els
rangs d’inici i de fi.
El conjunt de mètriques acordats s’utilitzen al llarg dels
requisits.
81Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsComplets?
Són els requisits complets?
Quina probabilitat hi ha que canviïn?
S’ha establert un control de canvis efectiu?
Com es veuran afectats els requisits actuals pels
nous requisits?
Quines són les dependències a completar cada
requisit?
Què provocaren els canvis tardans al cicle de vida
del testing o la posada en producció?
82Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsDesenvolupables?
Són els requisits desenvolupables?
Es factible la construcció de requisits?
Es pot construir el requisit dins dels terminis del
projecte?
Tenen els equips de desenvolupament
Interns/externs les eines/habilitats adequades
per fer el treball?
Està justificat el cost del requisit?
83Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsTestejables?
Son els requisits testejables?
Es pot replicar el requisit?
Es pot mesurar la sortida de les proves
del requisits?
Es poden provar les altres 7 regles?
Quins elements de suport es necessiten
per provar el requisit?
Poden els testers interpretar fàcilment
les especificacions tècniques?
84Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsOrientats a resultats?
Estan els requisits orientats a resultats?
Quin benefici obtindrà l’empresa i/o els seus
clients del requisit?
Es major el cost de construir, provar i gestionar
el requisit, que el benefici final?
Ha canviat el cost/aspecte del projecte des de
que es van crear les especificacions tècniques?
85Formació Testing ADINET 2009Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsPertinència?
Qui és el propietari del requisits?
Cada requisit hauria de tenir un propietari
assignat.
Com enllacen els requisits tècnics
amb els seus corresponents requisits
de negoci?
El propietari ha de ser conscient del impacte que
es faci realitat el risc del requisit.
86Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsContext del testing de requisits i traçabilitat
Objectius del Negoci
Riscos del servei
Disseny / Construcció
Codi
Proves d’acceptació
Requisits del servei
Testing de requisits
Producció
87Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsTraçabilitat de requisits
La traçabilitat de requisits implica documentar les dependències i connexions lògiques entre requisits individuals i del projecte, objectius de negoci per un costat i elements del disseny i proves per una altre elements del sistema.
Els elements poden incloure: altres requisits, arquitectura i altres components,
mòduls de codi font, casos de prova, arxius de ajuda i defectes.
El testing de la traçabilitat de requisits consisteix en assegurar la traçabilitat entre els requisits originals i els conseqüents components o elements que son alliberats.
requisits
Disseny
Codi
Proves
88Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsTesting de traçabilitat de requisits
Es posa èmfasi en assegurar la traçabilitat entre lliurables dels projectes.
Testejar l’associació entre proves, requisits, disseny i codi.
Vital quan existeixen múltiples equips de disseny o desenvolupament, o hi ha ajudar externa.
Redueix de forma molt important els defectes d’integració.
Testing de traçabilitat
Requisits
Disseny de baix nivell
Especificació Codi
Codi
Disseny d’arquitectura
Anàlisi funcional
89Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsPer què traçar els requisits?
Incrementa l’eficiència, redueix costos.
CertificacióCertifica que tots els requisits estan implementats.
Anàlisi d’impacte de canvisIdentifica tots els elements del sistema impactats per una sol·licitud de canvi.
MantenimentFer els canvis de forma correcta i completa.
Seguiment del projecteFer un seguiment de tot el projecte.
ReenginyeriaCapturar informació d’un sistema mitjançant un procés d’enginyeria inversa
Reducció del risc i testeigAssegurar que es prova el codi de la funcionalitat desitjada
90Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsTipus de traçabilitat
Pre-Traçabilitat de requisits(Origen dels requisits)
Post-Traçabilitat de requisits(relació dels requisits)
Regles de l’empresa
Idees
Apunts de reunions
Visions
Estudis
R1
R3
R6
R4
R5 R2
Origendels requisits
Especificacionsdels requisits
Disseny, proves iimplementació
91Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsTipus de traçabilitat
Pre-traçabilitat dels requisits
Endavant / endarrere en la traçabilitat
Connecta altres documents (que poden precedir els documents de requisits) amb /
des dels requisits actuals
Post-traçabilitat dels requisits
Endavant / endarrere en la traçabilitat
Connecta amb els requisits amb / des del disseny, les proves i la implementació de
components.
Origen dels requisits(p. Ex. Business Plan)
Documents de requisits
Treballs Posteriors(p.Ex. Casos de Prova)
Documents de requisits
92Formació Testing ADINET 2009
2.2. Gestió i traçabilitat de requisitsInformació de traçabilitat
La informació de la traçabilitat es la informació que ajuda a valorar l’impacte del canvi de requisits
Dependència dels requisits.
Dependència del disseny de sistemes.
Dependència de la implementació del sistema.
Dependència de les proves.
Dependència dels interessats.
93Formació Testing ADINET 2009
1. Fonaments i Gestió del Testing
2. Cicle de vidaEl model en V
Gestió i traçabilitat de requisits
Tipus de proves
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
94Formació Testing ADINET 2009Formació Testing ADINET 2009
2.3. Tipus de proves
Les activitats de proves s’organitzen depenent de quins siguin els objectius.
4 tipus de proves o objectius de testing:Funcionals. Basades en especificacions.
Característiques (de qualitat) no funcionals.
Caixa Blanca Basades en l’estructura.
Unitària.
Integració.
Regressió. Basades en els canvis de versions del software.
Poden estar basats en models o descripcions:Funcionals: text, flux de processos, transició de estats.
Estructura: flux de control, jerarquia de menús.
95Formació Testing ADINET 2009
2.3. Tipus de provesTesting de funcions. Testing funcional
Funció: El que un sistema realitza.Comportament extern del software (Caixa Negra)
Descrita per:Especificació de requisits. Casos d’ús.Especificacions funcionals.En cas de no existir documentació. Coneixement que tenen les persones que l’han creat/mantenen o que l’utilitzen.
Es realitza en tots els nivells del testingExemples:
Testing basat en requisits. A partir d’una especificació de requisits funcionals
es dissenyen i prioritzen les proves.
Testing basat en el negoci. A partir de perfils de negoci o perfils d’usuari es
reparteix l’esforç en proves.
Testing basat en tècniques intuïtives.
96Formació Testing ADINET 2009Formació Testing ADINET 2009
2.3. Tipus de provesTesting funcional o de sistema
El testing funcional recau en l’àmbit del black-box testing.El testing funcional pren com entrada la totalitat de components de software els quals ja han passat al testing d’integració.
El testing funcional busca fallades del funcionament especificat.
Les fallades trobades no només fan referència al disseny del software sinótambé al seu comportament esperat i fins i tot respondre a les expectatives de l’usuari final.
97Formació Testing ADINET 2009Formació Testing ADINET 2009
2.3. Tipus de provesTesting no funcional
Proves de les característiques del producte de software.Quin és el comportament del sistema?, com respon?
Es quantifiquen en una escala variable (p.ex. Temps de resposta)
Es realitza en tots els nivells del testing.
El estàndard ISO 9126 descriu els atributs de qualitat que es proven:
Rendiment Mantenibilitat
Càrrega Fiabilitat
Estres Portabilitat
Interoperabilitat Usabilitat
98Formació Testing ADINET 2009
2.3. Tipus de provesProves d’estructura. Testing estructural
Es basen en l’estructura d’un component o en l’arquitectura d’un sistema.
També conegudes com “caixa blanca” perquè ens interessa veure que succeeix “dins de la caixa”.
Es poden realitzar amb qualsevol nivell de testing:
Proves Unitàries o de Components.
Disposa de bones eines per mesurar la cobertura del codi.
Proves d’Integració:
Arquitectura / disseny.
Jerarquia de trucades.
99Formació Testing ADINET 2009
2.3. Tipus de provesPer què provar l’estructura?
Un aspecte important: Com de conscients hem estat amb les proves?Medir quanta estructura del sistema ha estat testejada per les nostres proves.
La cobertura es el percentatge d’elements estructurals coberts per un test suite (conjunt de proves)
Si la cobertura no és del 100% potser necessitem executar més proves sobre les
parts del sistema que no han estat cobertes.
S’ha provat suficient?
100Formació Testing ADINET 2009
2.3. Tipus de provesTesting d’integració
Consisteix en el procés d’identificar fallades en les interrelacions d’interfícies dels components.
Els mòduls són testejats com a grup.
Són les proves posteriors a les proves unitàries.
101Formació Testing ADINET 2009
2.3. Tipus de provesTesting d’integració: 4 passos
Identificació de les interfícies modulars o interfícies de components.
Comprovar la integritat entre interfícies.
Crear les condicions de proves d’integració.
Avaluar la finalització de la integració.
102Formació Testing ADINET 2009
2.3. Tipus de provesTesting de canvis, Testing de regressió
Un bon testing troba defectes.Arreglar defectes es depurar i no es una activitat del testing.
S’ha corregit la fallada?Proves de confirmació.
La resta del sistema segueix comportant-se correctament?
Proves de regressió.
També es realitza quant el entorn canvia.
103Formació Testing ADINET 2009
2.3. Tipus de provesProves de confirmació funcional
Executar una prova, falla, es reporta una fallada.
Considerar proves per defectes similars o relacionats.
Es rep una nova versió del software amb la fallada suposadament corregida.
Es torna a executar la mateixa provaEl mateix entorn i versions (excepte la del software, que lògicament ha canviat).
Si la prova obté èxit, la fallada s’haurà corregit, però, el software és ara correcte?
104Formació Testing ADINET 2009
2.3. Tipus de provesProves de regressió (1/2)
El seu propòsit es verificar que les modificacions del software o del entorn no causen efectes adversos inesperats, i que el sistema segueix complint els requisits.
Casos de prova que abans no fallaven pot ser que tornin a fallar després d'haver realitzat un canvi.
Les proves de regressió testegen les funcions més importants del sistema però no en detall.
S’executen cada cop que hi ha un canvi en el software o en el entorn.
Van canviant a mesura que evoluciona el sistema (s’afegeixen/eliminen casos de prova).
Convé que siguin automatitzades i no molt grans.
Quant testing de regressió es necessari?Depèn! P.ex. Del risc de deixar passar una fallada en el sistema.
El testing de regressió succeeix a tots els nivells del testing.Proves de regressió de:
Funcionalitats.
Característiques no funcionals.
Estructura (White Box).
105Formació Testing ADINET 2009
2.3. Tipus de provesProves de regressió (2/2)
Objectiu: preservar la qualitat que hem aconseguit un cop que el sistema està operatiu.
Raons per les proves de regressió:Modificacions.
Millores, correcció de defectes.
Canvis en la infraestructura, actualitzacions, patchs (afegits).
Migració (a noves plataformes)
Proves operacionals de la nova plataforma.
Retirada (sistema en desús)
Hi ha que provar la migració i el arxivat de dades a un altre sistema.
Diferències amb l’etapa de desenvolupament:Podem començar provant el sistema complet.
Disposem de dades reals i no hi cal construir dades de prova.
No sempre es disposen de les dades adequades.
106Formació Testing ADINET 2009Formació Testing ADINET 2009
2.3. Tipus de provesQuè es prova en el testing de regressió?
Es prova funcionalitat i codi prèviament existent
Anàlisi d’impacte en el codi existent.
En què podria causar un impacte aquest canvi?
Quanta importància té un defecte en l’àrea d’impacte?
Mateix component a dos llocs amb diferent criticitat.
Provar el que ha resultat afectat, però quant?
Les àrees afectades més importants?
Les àrees més propenses a ser afectades?
El sistema complet?
107Formació Testing ADINET 2009
2.3. Tipus de provesPetit canvi = Poc testing
Un petit canvi pot afectar a vàries àrees del sistema.
S’introdueix una millora
Proves de regressió per si apareixen nous defectes
Proves funcionals
Anàlisi d’impacte
XQue hem de
provar?
Sistema
X
Més test aquí?
Més test aquí?
108Formació Testing ADINET 2009
2.3. Tipus de provesDificultats del testing de regressió
El testing de regressió és difícil, com tots els tipus de proves si:
No hi ha especificacions.
Qualsevol documentació no està actualitzada.
No hi ha scripts de proves de regressió.
La base de coneixement és limitada degut a la edat del sistema.
Què fer?
Contactar amb persones que coneixen el sistema per esbrinar què realitzar i què ha
de realitzar.
Documentar la informació que obtinguem d’ells. Mirar guies o manuals d’usuari (si
existeixen).
109Formació Testing ADINET 2009
1. Fonaments i Gestió del Testing
2. Cicle de vida
3. Tècniques estàtiques i dinàmiquesComparativa de les tècniques de testing
4. Categories del disseny de proves
5. Conclusions
Índex
110Formació Testing ADINET 2009
3.1. Comparativa de les tècniques de testingTesting dinàmic vs. estàtic: Objectius similars
Proporcionar informació relativa al software o al sistema.
Trobar defectes o fallades.
Indirectament (Testing Estàtic). Directament (Testing Dinàmic).
Mesurar aspectes del sistema per a guanyar confiança en aquest.Per exemple, la complexitat, la densitat estimada de defectes,...
Trobar formes per millorar els processos, per tal de prevenir defectes.
Processos de desenvolupament. Processos de proves.
111Formació Testing ADINET 2009
3.1. Comparativa de les tècniques de testingTesting dinàmic vs. estàtic: Diferències
Estàtic Dinàmic
El software no és executat.
Mètodes manuals.Revisió de codi i de documentació.
Mètodes automàtics.
Anàlisi estàtica.Anàlisi de codi i de documentació.
No executa casos de proves.
En relació als defectes que es poden detectar…
…troba totes les ocurrències.…troba defectes aviat.
El software s’executa (se’n fan proves).
Mètodes manuals o automàtics.
Necessita casos de proves.Entrades, sortides esperades...
El disseny prematur de proves pot ajudar a trobar fallades aviat.
Mostreig de totes les possibles proves.
Caixa blanca, caixa gris, caixa negra o altres.
Troba Defectes Detecta Fallades
112Formació Testing ADINET 2009
3.1. Comparativa de les tècniques de testingEsquema bàsic
Estàtic (sense execució)Sobre documents walkthrough, revisions, inspeccions Sobre codi (caixa blanca): walkthrough, revisions, inspeccions; anàlisi de codi PMD)
Dinàmic (amb execució) (caixa blanca i caixa negra)Caixa blanca (estructurals) unitàries, integració.Caixa negra funcionals o de sistema
113Formació Testing ADINET 2009
3.1. Comparativa de les tècniques de testingEsquema tècniques de testing
Estàtiques Dinàmiques
Revisions informals
Walkthroughts
RevisionsTècniques
Inspeccions
Anàlisi estàtic
Flux de control
Flux de
dades
Estructural
Funcional
Afirmació Transiciód’estats
Taules de decisió
Anàlisi de valors límits
Particiód’equivalència
Arbres de classificació
Aleatori
Gràfics causa-efecte
Combinaciócondicions
de salt
Condició de Salt
Salt/Decisió
Control condicions de bucles
Flux de dades
114Formació Testing ADINET 2009
3.1. Comparativa de les tècniques de testingTècniques estàtiques
Troben defectes.
No executen codi
Manuals (revisions) i automàtiques (anàlisi estàtic)
Han de realitzar-se abans del testing dinàmic per obtenir el màxim benefici
Diferents tècniques trobaren diferents defectes
115Formació Testing ADINET 2009
3.1. Comparativa de les tècniques de testingTècniques dinàmiques
Troben fallades.
Haurien d’anar a continuació de les tècniques estàtiques.
Són complementaries al testing estàtic.
Requereixen executar les proves
Tècniques diferents troben fallades diferents.
116Formació Testing ADINET 2009
1. Fonaments i Gestió del Testing
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
117Formació Testing ADINET 2009
4. Categories del disseny de provesPer què utilitzar tècniques en el disseny de proves
El testing exhaustiu (utilitzar totes les dades d’entrada i condicions possibles) es impracticable. Provar-ho tot es molt car
Es necessari plantejar una estratègia.
S’han d’utilitzar un subconjunt de tots els possibles casos de prova.
Han de tenir una alta probabilitat de detectar defectes.
Es necessiten metodologies que ens ajudin a seleccionar els casos de prova de manera més intel·ligent.
Les tècniques de disseny de proves són aquestes metodologies.
118Formació Testing ADINET 2009
4. Categories del disseny de provesBeneficis d’utilitzar tècniques de disseny de proves
Diferents persones: Major probabilitat de trobar defectes o fallades.S’aconsegueix certa independència de pensament.
Testing efectiu: Troba més defectesCentrar-se en trobar tipus de fallides específiques.
Saber que s’està provant el correcte.
Testing eficient. Troba defectes amb menys esforç
Evitar les repeticions.
Es poden utilitzar mètriques amb les tècniques sistemàtiques.
Les tècniques fan que el testing sigui més efectiu i
més eficient
119Formació Testing ADINET 2009
4. Categories del disseny de provesQuè és una tècnica de testing?
Un procediment que ajuda a identifica condicions i casos de prova. Té èxit a l’hora de buscar i trobar defectes.
Una bona manera d’obtenir casos de prova.
Una bona manera de mesurar objectivament l’esforç de les proves.
Existeixen 3 tipus de tècniques:Basades en les especificacions (caixa negra).
Funcionals
No funcionals (característiques de qualitat)
Basades en el codi (caixa blanca).Basades en l’experiència.
El testing hauria de ser complet (el més exhaustiu possible) i
sistemàtic
120Formació Testing ADINET 2009
4. Categories del disseny de provesTècniques basades en les especificacions (tècniques de caixa negra)
Utilitza models (descripcions) del que hauriade fer el software.
Una especificació (model formal)
O el enteniment del que el software hauria de fer (model informal)
Anàlisi de la documentació (funcional o no funcional) de la Base de les Proves, sense tenir en compte el codi.
Els casos de prova s’obtenen de manera sistemàtica en base els casos d’ús i l’anàlisi de requisits.
121Formació Testing ADINET 2009
4. Categories del disseny de provesTècniques basades en l’estructura(tècniques de caixa blanca)
Utilitza models (descripcions) del software.
Basats en l’arquitectura del software; en com s’ha construït.
Normalment s’utilitza el disseny, estructura de menús o codi font.
Anàlisi de l’estructura interna d’un component o sistema.
Es pot mesurar la cobertura del software aconseguida amb els casos de prova.
Es poden obtenir nous casos de prova de manera sistemàtica per augmentar la cobertura.
122Formació Testing ADINET 2009
4. Categories del disseny de provesTècniques basades en l’experiència
S’utilitza l’experiència per obtenir les condicions i casos de prova.
Coneixement dels testers, desenvolupadors, usuaris i altres interessats o
involucrats.
Coneixement del software, el seu ús i el seu entorn. Coneixement dels seus
defectes més probables i la seva distribució. Heurística (aleatori).
123Formació Testing ADINET 2009
4. Categories del disseny de provesBasat en especificacions vs. Basat en l’experiència
Basats en especificacions
Les decisions es prenen en
base a les especificacions.
Les tècniques son
algorítmiques
(regles a seguir).
Limitat al que hi ha en
l’especificació (es pot deixar
passar el que no esta escrit.
S’ensenya més fàcilment.
Basats en experiència
El tester assumeix l’autoritat.
Pren les decisions.
Es recolza més en l’habilitat d’un
individu.
Brainstorming o llistes
recollides.
Es poden deixar defectes ja que
no hi ha especificacions.
124Formació Testing ADINET 2009
1. Fonaments i Gestió del Testing
2. Cicle de vida
3. Tècniques estàtiques i dinàmiques
4. Categories del disseny de proves
5. Conclusions
Índex
125Formació Testing ADINET 2009
5. ConclusionsAnticipació del testing
Distribució dels defectes segons la fase del cicle en el que es generen els errors
7% 10%
27%
56%
Requisitos y Diseño funcional Diseño técnico
Construcción Otras
7% 10%
27%
56%
Requisitos y Diseño funcional Diseño técnico
Construcción Otras
La situació actual ens diu que...
Mes de la meitat dels errors es cometen en les primeres fases del cicle.El cost de corregir errors creix exponencialment segons avança el projecte.El cost depèn de dos factors:
La fase en que s’introdueix l’error.La fase en la que es detecta.
Els esforços en detecció d’errors en fases primerenques estalvien molts diners.
Fuente: Edward Kit “Software Testing in the Real World. Improving the process”, citando una Presentación de Dick Bender titulada “Writing Testable Requirements”.
Fuente: Edward Kit “Software Testing in the Real World. Improving the process”, citando una Presentación de Dick Bender titulada “Writing Testable Requirements”.
126Formació Testing ADINET 2009
5. ConclusionsQuan dissenyar les proves?
Disseny de proves el més tard possible del cicle de vida implica...
No es progressa des de el punt de vista de la qualitat, els defectes es troben més tard són més cars d’arreglar.
En el pitjor moment (dates d’entregues molt properes), O pitjor, pel provador
menys apropiat, el client O pitjor, en producció, per l’ usuari
Els defectes més crítics i importants normalment es troben al final.
Amb un disseny de proves en fases inicials:
Els defectes trobats són més econòmics de corregir. Els defectes més significatius es troben abans de la implantació.
No es requereix un esforç addicional, només és necessari replanificar una segona iteració en l’execució de les proves funcionals o de regressió.
Canvis en els requisits provocats per defectes o errors trobats en fases de anàlisi funcional..
El disseny en fases inicials de les provesajudar a generar qualitat, parant
la multiplicació de defectes
127Formació Testing ADINET 2009
5. ConclusionsUn cas real: Escenari 1
La realitat ens mostra que, en molts casos, els projectes pateixen alguns retards.
Pla de Projecte
Resultats
Realitat
150 errors en execució de provesBaixa qualitat: 50 errors durant el primer mes en produccióDesviació en termini i costInsatisfacció dels usuaris.
2 mesosdesenvolupament
2 mesosproves
2.5 mesosdesenvolupament
2 mesosproves
Es necessita entrar en producció, però encara no funciona
Arrancada
Retard
128Formació Testing ADINET 2009
5. ConclusionsUn cas real: Escenari 2
Aplicant una sèrie de canvis s’obtenen millors resultats.
Pla de Projecte
Realitat
Resultats El testing estàtic redueix els errors en la execucióMillor qualitat: 0 errors durant el primer mesCompliment de termini i costSatisfacció del usuaris
Test estàticDefinició casos de prova
2 mesosdesenvolupament
2 mesosdesenvolupament
Test estàticDefinició casos de prova
6 setmanes deproves
6 setmanes deproves
Proves d’acceptació, 1 setmana complertaenlloc d’un únic dia
129Formació Testing ADINET 2009Formació Testing ADINET 2009
5. Conclusions Beneficis del testing
Millora de manera concreta els resultats.
Disminueixen els costs (Els errors no es multipliquen, menys retreball).
Disminució de mant. correctiu. (Optimitza el retorn de la inversió )
S'assegura la qualitat dels productes i per tant del servei. Són més fiables i més estables.
Permet als usuaris concentrar-se en el seu treball.
Disminueix les seves intervencions a les proves d’acceptació. Millora en l’eficiència
Es defineixen i formalitzen les condicions d'acceptació del software.
Facilita l’acceptació del software.
Racionalitza el procés de testing.
Estructura l’activitat de testing en tot el cicle de vida del SW.
Dirigeix la activitat de testing mitjançant objectius gestionats amb mètriques.
130Formació Testing ADINET 2009
5. Conclusions Percentatges de millores amb el procés de Testing
Menor Mitja Major
Increment en productivitat 9% 35% 67%
Increment en detecció en fases inicials dels defectes
6% 22% 25%
Reducció en temps d’entrega 15% 19% 22%
Reducció del número de defectes després de l’implementació
10% 39% 94%
Retorn d’inversió (R.O.I.) 420% 500% 880%
Font: T. Capers Jones
131Formació Testing ADINET 2009
Gràcies per la vostra atenció
Formació Testing ADINET 2009