Curso Testing Funcional (Alonso Carra)

www.alonsocarra.com [email protected]

Quality Assurance

KnowledgeManagement

ChangeManagement

IT Governance

Business ProcessManagement

Project ManagementOffice

Best Practices

PM.MED.21VERSION 1.1

SERVICIOS

ALONSO CARRA S.A. Todo el material est protegido por las leyes de propiedad intelectual. Uso exclusivo de la organizacin y sus clientes de acuerdo a los contratos vigentes. Queda hecho el depsito que marca la ley. Prohibida su reproduccin.

PM.MED.21 MEDICIONES DE SOFTWARE

CURSO TEST FUNCIONAL

TSOFT03 SEPTIEMBRE - 2007

18.00 a 21.00

SERIE: QA QUALITY ASSURANCE

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

2

www.alonsocarra.com [email protected] ALONSO CARRA S.A. Todo el material est protegido por las leyes de propiedad intelectual. Uso exclusivo de la organizacin y sus clientes de acuerdo a los contratos vigentes. Queda hecho el depsito que marca la ley. Prohibida su reproduccin.


CURSOS

PM - PROJECT MANAGEMENTSE SOFTWARE ENGINEERINGUP SUPPORT ENGINEERINGQA QUALITY ASSURANCESD SOFTWARE DEVELOPMENTSA STRATEGIC ADMINISTRATIONQM QUANTITIVE METHODSHR - HUMAN RESOURCES

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

3



SERIE: QUALITY ASSURANCE

IQA INTRODUCCIN A QUALITY ASSURANCENCO NO CONFORMIDADESMCT MEJORA CONTINUAADD AUDITORA DE PRODUCTOSADC AUDITORA DE PROCESOSTQM CALIDAD TOTALQAM ADMINISTRACIN DE CALIDADCDC CRCULOS DE CALIDADEMC ESTIMACIN Y MEDICIN EN CALIDADCGT CONCEPTOS GENERALES DE TESTINGCPT TEST FUNCIONALOPF OTRAS PRUEBAS FUNCIONALESPDU PRUEBA DE USABILIDADSCP PRUEBA DE STRESS, CARGA Y PERFORMANCEPDI PRUEBAS DE INSPECCINPTS PROCESO DE TESTING


Quality Assurance

KnowledgeManagement

ChangeManagement

IT Governance



Best Practices


SERVICIOS



TEST FUNCIONAL

PRLOGO

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

5



Recursos fsicosCelular.

El celular del expositor permanecer

en silencio, se recomienda que los de ustedes tambin.

Baos. Localizados a la derecha de los ascensores

Agua y caf. Se podr

tomar agua y/o caf

en cualquier momento

Material.Se entregar

una copia del material expuesto.Preguntas.

Se podr

hacer preguntas en cualquier momento.Se contestarn en el momento o se estacionarn.Al final de la charla se invita a preguntar dudas generales.

II. REC

UR

SOS D

EL CU

RSO

OFR

ECID

O

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

6



Recursos Humanos

II. REC

UR

SOS D

EL CU

RSO

OFR

ECID

O

Licenciado en sistemas (CAECE), ha realizado estudios de especializacin y postgrado en Argentina, Brasil, Uruguay, Espaa y EE.UU. Actualmente est terminando su tesis de doctorado en la Universidad Politcnica de Madrid.Con 28 aos de experiencia laboral se ha desarrollado en cargos gerenciales de IT, liderado y administrando el desarrollo de sistemas.Desde hace 15 aos se ha dedicado al rea de metodologas, calidad y direccin de proyectos, asesorando a varias organizaciones. Estas actividades las desarrollo en ms de 50 empresas de primera lnea, tanto en la administracin pblica como privada, as como varias pymes. Ha sido perito de parte de importantes organizaciones.Gerenci proyectos de CMMI e ISO, liderando o asesorando en la mayora de los proyectos CMMI formalmente registrados en Argentina. Es auditor ISO 9001:2000 (Georgia Institute of Technology) y Certified Product Specialist de Mercury Interactive. Ha realizado los cursos oficiales de CMMI y PSM.Se desempea como docente e investigador en las universidades CAECE y UADE. Habiendo dictado cursos de grado y postgrado desde hace 27 aos en diversas universidades como ITBA, Belgrano, UBA, de la Matanza, Palermo, Catlica de Salta y del Centro (Tandil).Ha sido director y jurado de tesis y participa continuamente de jornadas de actualizacin cientfica y perfeccionamiento docente. Tambin ha actuado como instructor de temas de IT en diversas organizaciones empresarias.

DANIEL

EDUARDO

ALONSO

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

7



TEMARIO

01. CASO DE USO. ESTRUCTURA02. CASO DE USO. ESPECIFICACIN03. SELECCIN DE CASOS DE PRUEBA04. CAJA NEGRA. 05. CAJA BLANCA

II. REC

UR

SOS D

EL CU

RSO

OFR

ECID

O


Quality Assurance

KnowledgeManagement

ChangeManagement

IT Governance



Best Practices


SERVICIOS



TEST FUNCIONAL

CASO DE USO. ESTRUCTURA

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

9



Definicin

Descripcin de una parte del sistema, desde el punto de vista funcional.Un caso de uso representa una accin, un escenario posible de un requerimiento funcional.El caso de uso no representa requerimientos no funcionales.Las interacciones con el sistema son dilogos que se mantienen con el medio ambiente y ese dilogo est representado en un caso de uso.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

10



Objetivo

Intencionalidad.Que comportamiento se espera del caso de uso.No indica como.Indica que.Es lo que debe lograrse en la accin normal del caso de uso.No tiene detalles de implantacin.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

11



Requerimientos

El caso de uso debe indicar que requerimientos, tanto funcionales como no funcionales cubre.La relacin requerimiento caso de uso debe ser lo menos n a n posible.Para cumplir esto ltimo puede ser necesario redefinir los requerimientos o los caso de uso.Al redefinir los requerimientos se propone hacer super requerimientos o sub requerimientos para mantener trazabilidad con las expresiones de deseo.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

12



Reglas de negocio

Las reglas de negocio son la forma de describir el dominio de la aplicacin.Plantean restricciones propias del dominio, es decir requisitos.Cada caso de uso debera indicar que reglas de negocio lo restringen.Existen reglas de negocio generales que afectan a todos los caso de uso.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

13



Actor

Persona, software, hardware o cualquier entidad que interacta con el sistema iniciando caso de uso.Actor puede ser primario o secundario.El actor dispara comportamientos en el sistema.La definicin de un actor es una clase.La abstraccin del caso y su objetivo define el plano de abstraccin del actor.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

14



Trigger

Evento disparador del comportamiento de un caso de uso.Es activado por un actor.Es nico.Si el caso recibe varios estmulos, solo uno de ellos es el trigger.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

15



Dnde termina el caso de uso?

Si un caso empieza con un trigger, debe terminar ante un trigger o cierto comportamiento del sistema no estar representado en los casos de uso.El caso recibe varios estmulos durante su ejecucin.Cmo identificar el estmulo que es el trigger final?Concepto de interrupcin lgica.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

16



Condiciones

Estados del sistema.Deben ser lebles en forma externa al caso de uso.Un caso de uso puedo no cambiar estados del sistema o puede estar siempre disponible para actuar en cualquier estado.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

17



Pre Condiciones

Estados iniciales de un caso de uso.Una precondicin no puede ser precondicin de otra precondicin.Existen precondiciones que sern cambiadas por el mismo caso de uso, otras no sern afectadas por el mismo.Las pre condiciones son establecidas por el medio ambiente o por otro caso de uso.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

18



Post Condiciones

Estados finales de un caso de uso.Una post condicin no puede ser post condicin de otra post condicin.Existen post condiciones que sern resultado del mismo caso de uso, otras no sern afectadas por el mismo.Las post condiciones afectan al medio ambiente o a otro caso de uso.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

19



Escenario Normal

El comportamiento que se espera del caso de uso de acuerdo a su objetivo.Un escenario es tan restringido como el detalle del objetivo planteado.Es conveniente expresarlo:

sujeto - verbo objeto.Ejemplo: El cliente selecciona la provincia.

Las acciones deben expresar el curso lgico pero no dar detalles de implantacin.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

20



Alternativas

Otros escenarios posibles del caso de uso.Una alternativa es un escenario posible, no es un if.Las alternativas pueden encontrarse negando post condicionesNo todo escenario posible, es alternativa del caso de uso.Existen alternativas de alternativas.Las alternativas tienen condiciones y triggers propios

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

21



Variaciones

Si el orden de acciones dentro de un caso de uso puede variar y sigue cumpliendo con el mismo escenario, se denomina variacin.Las variaciones no suelen documentarse apropiadamente.Las variaciones siempre son dentro de un mismo escenario.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

22



Inclusiones y extensiones

Inclusiones: Caso de uso que puede ser incluido como escenario alternativo de otro caso de uso.Extensin: Caso de uso que extiende la funcionalidad de otro caso de uso por invocacin directa o indirecta.


Quality Assurance

KnowledgeManagement

ChangeManagement

IT Governance



Best Practices


SERVICIOS



TEST FUNCIONAL

CASO DE USO. ESPECIFICACIN

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

24



Especificar casos de uso

La descripcin del caso de uso es textual.Los diagramas sirven para verlos contextualmente pero no para describirlos.La descripcin puede ser un texto libre (no estructurada).

Mas coloquial, pierde rigurosidad, difcil rescatar informacin

La descripcin puede ser un texto estructurado (un template con campos a llenar).

Puede tener campos que no aplican en la mayora de las veces

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

25



UC: Alta de procesoSe intenta agregar un proceso a la base de datos, verificando se completitud, la consistencia de los datos y no dar alta de procesos duplicados.Se incorpora el cdigo de proceso en la interfaz descripta en 1.1.1, validando que sea alfabtico y de un mximo de 2 letras. Al incorporar el proceso, se busca el mismo en la tabla de procesos de acuerdo al cdigo ingresado. De existir otro proceso con ese cdigo se informar desplegando una ventana de mensaje segn especificado en la interfaz 0.1.5Luego de verificar su inexistencia se desplegar la interfaz 1.1.2 y se proceder a ...

Especificacin libre (no estructurada)

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

26



Especificacin con template (estructurada)

Cdigo: UC02.01.02Nombre: Alta de procesoActor: Pedido de incorporar procesos.Objetivo: Se intenta agregar un proceso a la base de datos, verificando se completitud, la consistencia de los datos y no dar alta de procesos duplicados.Requerimientos funcionales: Incorporar procesos.Requerimientos NO funcionales: La incorporacin de procesos deber tener una interfaz que permita acceder a toda la informacin del entorno informativo.Reglas de negocio: Los procesos solo pueden ser cargados por el perfil administrador

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

27



Especificacin libre (no estructurada)

Actor: Pedido de incorporar procesos.Precondiciones: La estructura jerrquica a la que pertenece el proceso debe estar dada de alta.Postcondiciones: El proceso existe correctamente grabado en la base de datos.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

28



Especificacin con template (estructurada)

Escenario de altaPrecondiciones: La estructura jerrquica a la que pertenece el proceso debe estar dada de alta.Postcondiciones: El proceso existe correctamente grabado en la base de datos.EscenarioEl sistema despliega la interfaz 1.1.1El usuario ingresa el cdigo de procesoEl cdigo de proceso se busca en la tablaLa tabla devuelve el resultado de la bsqueda...

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

29



Cuantos diagramas?

No hay un nmero exacto, pero el nmero de casos es un indicador de complejidad.Si usted tiene un sistema simple y muchos casos o viceversa es un indicador de funcionalidad no modela o demasiado modelada.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

30



Casos de uso poco o mal vestidos

AtributosObjetivoActorTriggerPre y post condiciones

Qu casos de pueden anticipar?Funcin esperadaNegacin de las pre condicionesValidacin del triggerPostcondiciones como resultado esperado

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

31



Casos de uso muy o bien vestidosAtributos

Los mismos que el caso mal vestidoAlternativasVariacionesInclusionesExtensionesSe depuran pre y post condiciones

Qu casos de pueden realizar?.Funciones alternativas.Nuevas negaciones de las pre condiciones.No quedan establecidas las pruebas dependientes de la interfaz.Nuevas postcondiciones como resultado esperado.


Quality Assurance

KnowledgeManagement

ChangeManagement

IT Governance



Best Practices


SERVICIOS



TEST FUNCIONAL

SELECCIN DE CASOS

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

33



El problema

Qu va a testear?, le preguntaron.Lo mas importante, respondi.Y como sabe que es lo mas importante?....Despus de pensar, la solucin pareci ser un anlisis de riesgos. Determinar:

Riesgos involucrados en el procesoEsfuerzo de testing involucradoPruebas mitigantesCostos de esas pruebas

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

34



Casos de prueba primarios

Se construyen a partir del escenario normal.Luego se agregarn casos por cada escenario.Se deben recorrer todos los caminos planteados funcionalmente.No armar un caso de prueba si el camino lo recorrer un juego de datos, debe armarse por escenario.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

35



Casos de prueba secundarios

Se pueden armar en funcin de datos del caso de uso que no son lo escenarios.Negar las precondiciones.Pensar alternativas a las postcondiciones.Analizar el dominio del actor.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

36



Los riesgosNo estamos hablando de riesgos del proyecto (por ejemplo: entregar tarde, cambios de personal, etc.).Estamos hablando de identificar los riesgos de no pasar un test.Para cada caso se identifica un riesgo de falla, ejemplo:

1. Severa, falla crtica, Riesgo: el sistema no ser

fiable o no cumplir

su SLA.2. Alta, falla inaceptable, Riesgo: el sistema no

ser

predecible o cumplir

con muy baja performance su SLA.

3. Mediano, falla superable, Riesgo: Problemas operacionales o no podrn excederse los lmites del SLA.

4. Bajo, fallas incmodas o triviales, no existen riesgos.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

37



Como asignar el tipo de riesgo

Factores de riesgo:RequerimientoSeveridadProbabilidadCostoVisibilidadToleranciaFactor Humano

Cada uno de los factores sern de la misma escala y permitirn el N/A.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

38



CostoSe debe calcular el costo de no servicio.Se recomienda calcular un costo optimista y pesimista, en forma estadstica.Por ejemplo:

Cul es el costo de un sitio por estar down

1 hora?

Cul es el costo de una mala imputacin en un banco?Cul es el costo de no llegar con informacin al cliente?

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

39



Riesgo

Se asigna un riesgo a cada requerimiento a testear de acuerdo a lo visto y se genera un ranking:Ejemplo:

Se deber

emitir un listado de clientes morosos.Caso: Se identifica a un cliente como moroso sin serlo.Tipo de riesgo: 2. Alto, inaceptableCantidad de pruebas previstas para el caso: 17.

Pregunta: Se deben hacer todos los 17 casos, mas o menos?

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

40



Modelo de decisin

Se utiliza un modelo matemtico para determinar la decisin.Un modelo sera promediar los riesgos y dividir la cantidad de casos por el mismo.Ejemplo:

El riesgo recibi

un 1 en Visibilidad, 2 en Requerimiento, 1 en Costo y 1 en Tolerancia. El resto de los factores fue N/A.El ranking es de (1+2+1+1)/4=1,25. Como se tienen 17 casos, tendrn prioridad y se ejecutarn en primera instancia 17/1,25 casos, es decir 13.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

41



Probabilidad y costo del riesgoLos casos efectivamente tomados sobre la cantidad de casos previstos nos indica la cobertura de riesgo que estamos tomandoEjemplo:Se tenan 17 casos previstosSe ejecutarn 13 casosSe tiene un 76% de cobertura de riesgo.Suponiendo un costo: $ 9.300 (promedio de valores pagados por la organizacin por juicios por informacin no veraz). El costo del riesgo es de $ 2188.-

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

42



Lmite del anlisis

Debe recordarse que estamos trabajando sobre un universo de 17 casos.No son todos los casos posibles, son los casos previstos en nuestro anlisis de testing.


Quality Assurance

KnowledgeManagement

ChangeManagement

IT Governance



Best Practices


SERVICIOS



TEST FUNCIONAL

CAJA NEGRA

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

44



Herramientas funcionales de caja negra

Clases de equivalenciaAnlisis de fronteraError guessingPairwise

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

45



Como identificar clases de equivalencia

Para cada entrada:Si es un rango, identificar un valor dentro del rango y dos valores fuera (anterior y posterior al rango).Si es un nmero, identificar un nmero correcto, null y un nmero incorrecto.Si es un conjunto, seleccionar un valor perteneciente al conjunto y uno fuera del mismo.Si el programa toma casos en forma distinta, seleccionar distintos casos.Si existen casos obligados tomar un caso por cada obligacin.Se pueden tener subcasos.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

46



Casos de test por clases de equivalencia

Asignar un nmero a cada clase de equivalencia.Cuando se han cubierto todas las pruebas de casos correctos, cubrir los casos incorrectos con un conjunto mnimo de pruebas.Hacer pruebas para los casos incorrectos restantes (normalmente una prueba por caso).

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

47



Anlisis de frontera

Es una variacin de clases de equivalencia.Sus diferencias son:

Se seleccionan valores en la frontera de los conjuntos de testing (no cualquier valor)Se inspecciona la salida tambin, no solo la entrada.

No siempre es fcil identificar los valores de frontera.El mtodo no toma combinaciones de condiciones de entrada.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

48



Gua para anlisis de frontera

Establecer casos vlidos para los lmites de los conjuntos y valores justo despus de esos lmites.Si es un conjunto de valores, establecer como valores de prueba el mnimo y el mximo del conjunto y los primeros valores antes del mnimo y luego del mximo como no vlidos.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

49



Error guessing

Se basa en la intuicin o experiencia sobre errores comunes en la organizacin.La historia de defectos es una gran ayuda.Ejemplos comunes son:

Listas o valores vacos.CeroNmeros negativosValores significativosValores con significado culturalValores organizacionales

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

50



Pairwise

Intenta encontrar clases de equivalencia de conjuntos de valores.Debido a la combinatoria de las entradas es altamente costoso establecer todas las combinaciones.Por otro lado, muchas combinaciones son equivalentes.Se intenta establecer que combinaciones son equivalentes a otras y testearlas.


Quality Assurance

KnowledgeManagement

ChangeManagement

IT Governance



Best Practices


SERVICIOS



TEST FUNCIONAL

CAJA BLANCA

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

52



Herramientas funcionales de caja blanca.

CoberturaComplejidad ciclomticaPrueba de escritorio.Prueba sintctica.Prueba estructural.Prueba funcional.Revisin entre pares.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

53



Criterios de cobertura

De Sentencias:Se trata de generar los casos de prueba necesarios para que cada sentencia o instruccin del programa se ejecute, al menos, una vez.

De decisiones:Consiste en escribir casos suficientes para que cada decisin tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso.Nota: No se prueba el lenguaje !!!

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

54



Criterios de cobertura

De condiciones:Se trata de disear tantos casos como sea necesario para que cada condicin de cada decisin adopte el valor verdadero al menos una vez y el falso al menos una vez.

De decisin/condicin.Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla tambin el criterio de decisiones.

De condicin mltiple.En el caso de que se considere que la evaluacin de las condiciones de cada decisin no se realiza de forma simultnea.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

55



Prueba estructural

La cobertura de caminos es el criterio mas completoCada camino debe ser probadoCaminos de prueba: ejecutar cada bucle por lo menos una vezUtilizando caminos de prueba se puede cuantificar la cantidad de caminos (permite asignar correctamente los recursos)

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

56



Complejidad ciclomtica

Indicador del nmero de caminos independientes que existen en un grafo. Ejecucin de un conjunto de caminos independientesLa complejidad de McCabe V (G) se puede calcular de las tres maneras siguientes a partir de un grafo de flujo G:

V (G) = a - n + 2, siendo a el nmero de arcos o aristas del grafo y n el nmero de nodos.V (G) = r, siendo r el nmero de regiones cerradas del grafo.V (G) = c + 1, siendo c el nmero de nodos de condicin

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

57



Complejidad ciclomtica

El criterio de prueba de McCabe consiste en elegir V(G) caminos que sean independientes entre s y crear casos de prueba cuya ejecucin siga dichos caminos. V (G) marca un lmite mnimo de nmero de casos de prueba para un programa, contando siempre cada condicin de decisin como un nodo individual.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

58



Mtodo del camino bsico

Consiste en realizar variaciones sobre la eleccin de un primer camino de prueba tpico denominado camino bsico.Conviene aclarar que algunos de los caminos quizs no se puedan ejecutar solos y requieran una concatenacin con algn otro.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

59



Mtodo del camino bsico

A partir de estos caminos, el diseador de las pruebas debe analizar el cdigo para saber los datos de entrada necesarios para forzar la ejecucin de cada uno de ellos. Puede ocurrir tambin que las condiciones necesarias para que la ejecucin pase por un determinado camino no se puedan satisfacer de ninguna manera. En ese caso, debemos sustituir dicho camino por otro posible que permita satisfacer igualmente el criterio de prueba.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

60



Prueba de escritorio

Planear la prueba de escritorio.Prueba sintctica.Prueba estructural.Prueba funcional.Reporte final.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

61



Prueba sintctica.Identificar compliance del cdigo.

Se usan las estructuras deseadas?Se usan las sentencias apropiadas?Se identifican las variables correctamente?Las estructuras de datos son las correctas?Las sentencias usan los datos correctos?Las polticas de programacin son respetadas?.

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

62



Prueba estructural.La arquitectura del programa.

Se pasa por todas las sentencias?Se usan todas las definiciones y estructuras de datos?Todos los branch tienen un punto de entrada correcto?Los parmetros se pasan correctamente?Los valores de entrada son tomados correctamente?

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

63



Prueba funcional

El objetivo del programa se logra?.Las funciones se ejecutan correctamente?Se validan los datos de entrada y salida?Se acumulan los datos correctamente entre corridas?Se pueden detectar datos erroneos?Se pueden detectar datos irazonables?

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

64



Reporte final

El reporte final es opcional.Debe quedar claro quien y cuando encontr el error.Debe determinar si el error es reproducibleDebe indicar con que juego de datos se encontr. Debe indicarse en que accin del sistema se encuentra el error.Debe indicar severidad y prioridad.


Quality Assurance

KnowledgeManagement

ChangeManagement

IT Governance



Best Practices


SERVICIOS



PRUEBA FUNCIONAL

EPLOGO

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

66


PM.MED.21 MEDICIONES DE SOFTWAREEPLO

GO

Dudas, preguntas, angustias, llantos, crisis de nervios, problemas existenciales, dramas o consultas?

SO

L

E

R

4

4

1

8

4

t

o

.

1

7

(

C

1

4

2

5

B

W

Z

)

-

B

U

E

N

O

S

A

I

R

E

S

(

0

1

1

)

1

5

-

5

1

0

4

-

0

1

6

5

d

a

n

i

e

l

.

a

l

o

n

s

o

@

a

l

o

n

s

o

c

a

r

r

a

.

c

o

m

67



MUCHAS GRACIASCURSO BRINDADO POR:

ALONSO CARRA S.A.SOLER 4418 4to. 17

(C1425BWZ) - BUENOS [email protected]

ARGENTINA

EXPOSITORDANIEL E. ALONSO(011)15-5104-0165

[email protected]

EPLOG

O

CURSOTEST FUNCIONALCURSOSSERIE: QUALITY ASSURANCETEST FUNCIONALRecursos fsicosRecursos HumanosTEMARIOTEST FUNCIONALDefinicinObjetivoRequerimientosReglas de negocioActorTriggerDnde termina el caso de uso?CondicionesPre CondicionesPost CondicionesEscenario NormalAlternativasVariacionesInclusiones y extensionesTEST FUNCIONALEspecificar casos de usoEspecificacin libre(no estructurada)Especificacin con template (estructurada)Especificacin libre(no estructurada)Especificacin con template (estructurada)Cuantos diagramas?Casos de uso poco o mal vestidosCasos de uso muy o bien vestidosTEST FUNCIONALEl problemaCasos de prueba primariosCasos de prueba secundariosLos riesgosComo asignar el tipo de riesgoCostoRiesgoModelo de decisinProbabilidad y costo del riesgoLmite del anlisisTEST FUNCIONALHerramientas funcionales de caja negraComo identificar clases de equivalenciaCasos de test por clases de equivalenciaAnlisis de fronteraGua para anlisis de fronteraError guessingPairwiseTEST FUNCIONALHerramientas funcionales de caja blanca.Criterios de coberturaCriterios de coberturaPrueba estructuralComplejidad ciclomticaComplejidad ciclomticaMtodo del camino bsicoMtodo del camino bsicoPrueba de escritorioPrueba sintctica.Prueba estructural.Prueba funcionalReporte finalPRUEBA FUNCIONALDudas, preguntas, angustias, llantos, crisis de nervios, problemas existenciales, dramas o consultas?MUCHAS GRACIAS

Curso Testing Funcional (Alonso Carra)

Documents