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


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


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



5. Conclusions

Índex


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!


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.


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.



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.



É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


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.


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, ...


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.


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 .


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.


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



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.


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!


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”).


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.






Pla de proves



Gestió de riscos

2. Cicle de vida



5. Conclusions

Índex


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


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ó.






Pla de proves



Gestió de riscos

2. Cicle de vida



5. Conclusions

Índex


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)


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


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.



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.



1.3. Processos Fonamentals del TestingActivitat d’Estratègia proposta ADINET


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


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ó)



1.3. Processos Fonamentals del TestingActivitat de Creació proposta ADINET


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



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.



1.3. Processos Fonamentals del TestingActivitats d’Execució proposta ADINET


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



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).



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.



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.







Pla de proves



Gestió de riscos

2. Cicle de vida



5. Conclusions

Índex


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


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


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


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.


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.


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.


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.


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






Pla de proves



Gestió de riscos

2. Cicle de vida



5. Conclusions

Índex


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


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”



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.



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...



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).



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.



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ó



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.



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



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.






Pla de proves



Gestió de riscos

2. Cicle de vida



5. Conclusions

Índex


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.


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.


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.


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.






Pla de proves



Gestió de riscos

2. Cicle de vida



5. Conclusions

Índex


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.


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ó.


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?


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).






Pla de proves



Gestió de riscos

2. Cicle de vida



5. Conclusions

Índex


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


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”.


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.


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



2. Cicle de vidaEl model en V

Gestió i traçabilitat de requisits

Tipus de proves



5. Conclusions

Índex


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


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”.





Tipus de proves



5. Conclusions

Índex


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ó.


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.


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.


2.2. Gestió i traçabilitat de requisitsLes 8 regles dels requisits

Singular

No ambigu

Mesurable

Complet

Desenvolupable

Testejable

Orientat a resultats

Pertinència


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.


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.


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.


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ó?


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?


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?


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?


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.


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ó


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


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


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


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ó


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


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.





Tipus de proves



5. Conclusions

Índex


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.


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.


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.


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


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.


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?


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.


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ó.


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.


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?


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).


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.


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?


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í?


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).



2. Cicle de vida

3. Tècniques estàtiques i dinàmiquesComparativa de les tècniques de testing


5. Conclusions

Índex


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.


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


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


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


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


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.



2. Cicle de vida



5. Conclusions

Índex


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.


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


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


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.


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.


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).


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.



2. Cicle de vida



5. Conclusions

Índex


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”.


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


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


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



Test estàticDefinició casos de prova

6 setmanes deproves

6 setmanes deproves

Proves d’acceptació, 1 setmana complertaenlloc d’un únic dia


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.


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


Gràcies per la vostra atenció
