Curso Testing Funcional (Alonso Carra)

www.alonsocarra.com info@alonsocarra.
com
Quality Assurance
Knowledge
Management
Change
Management
IT Governance
BusinessProcess
Management
Project Management
Office
Best Practices
PM.MED.21
VERSION 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
TSOFT
03 SEPTIEMBRE - 2007
18.00 a 21.00
SERIE: QA QUALITY ASSURANCE
S
O
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 info@alonsocarra.com
de67
CURSOS
PM - PROJECT MANAGEMENT
SE SOFTWARE ENGINEERING
UP SUPPORT ENGINEERING
QA QUALITY ASSURANCE
SD SOFTWARE DEVELOPMENT
SA STRATEGIC ADMINISTRATION
QM QUANTITIVE METHODS
HR - HUMAN RESOURCES
S
O
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
de67
SERIE: QUALITY ASSURANCE
IQA INTRODUCCIN A QUALITY ASSURANCE
NCO NO CONFORMIDADES
MCT MEJORA CONTINUA
ADD AUDITORA DE PRODUCTOS
ADC AUDITORA DE PROCESOS
TQM CALIDAD TOTAL
QAM ADMINISTRACIN DE CALIDAD
CDC CRCULOS DE CALIDAD
EMC ESTIMACIN Y MEDICIN EN CALIDAD
CGT CONCEPTOS GENERALES DE TESTING
CPT TEST FUNCIONAL
OPF OTRAS PRUEBAS FUNCIONALES
PDU PRUEBA DE USABILIDAD
SCP PRUEBA DE STRESS, CARGA Y PERFORMANCE
PDI PRUEBAS DE INSPECCIN
PTS PROCESO DE TESTING
Quality Assurance
Knowledge
Management
Change
Management
IT Governance
BusinessProcess
Management
Project Management
Office
Best Practices
PM.MED.21
VERSION 1.1
SERVICIOS
TEST FUNCIONAL
PRLOGO
S
O
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
de67
Recursos fsicos
Celular.
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.
I
I
.

R
E
C
U
R
S
O
S

D
E
L

C
U
R
S
O

O
F
R
E
C
I
D
O
S
O
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
de67
Recursos Humanos
I
I
.

R
E
C
U
R
S
O
S

D
E
L

C
U
R
S
O

O
F
R
E
C
I
D
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
S
O
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
de67
TEMARIO
01. CASO DE USO. ESTRUCTURA
02. CASO DE USO.
ESPECIFICACIN
03. SELECCIN DE CASOS DE
PRUEBA
04. CAJA NEGRA.
05. CAJA BLANCA
I
I
.

R
E
C
U
R
S
O
S

D
E
L

C
U
R
S
O

O
F
R
E
C
I
D
O
Quality Assurance
Knowledge
Management
Change
Management
IT Governance
BusinessProcess
Management
Project Management
Office
Best Practices
PM.MED.21
VERSION 1.1
SERVICIOS
TEST FUNCIONAL
CASO DE USO. ESTRUCTURA
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
Alternativas
Otros escenarios posibles del caso de uso.
Una alternativa es un escenario posible, no
es un if.
Las alternativas pueden encontrarse
negando post condiciones
No todo escenario posible, es alternativa del
caso de uso.
Existen alternativas de alternativas.
Las alternativas tienen condiciones y triggers
propios
S
O
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
de67
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.
S
O
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
de67
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
Knowledge
Management
Change
Management
IT Governance
BusinessProcess
Management
Project Management
Office
Best Practices
PM.MED.21
VERSION 1.1
SERVICIOS
TEST FUNCIONAL
CASO DE USO.
ESPECIFICACIN
S
O
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
de67
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
S
O
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
de67
UC: Alta de proceso
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.
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.5
Luego de verificar su inexistencia se desplegar la
interfaz 1.1.2 y se proceder a ...
Especificacin libre
(no estructurada)
S
O
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
de67
Especificacin con template
(estructurada)
Cdigo: UC02.01.02
Nombre: Alta de proceso
Actor: 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
S
O
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
de67
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.
S
O
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
de67
Especificacin con template
(estructurada)
Escenario de alta
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.
Escenario
El sistema despliega la interfaz 1.1.1
El usuario ingresa el cdigo de proceso
El cdigo de proceso se busca en la tabla
La tabla devuelve el resultado de la
bsqueda
...
S
O
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
de67
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.
S
O
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
de67
Casos de uso poco o mal vestidos
Atributos
Objetivo
Actor
Trigger
Pre y post condiciones
Qu casos de pueden anticipar?
Funcin esperada
Negacin de las pre condiciones
Validacin del trigger
Postcondiciones como resultado esperado
S
O
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
de67
Casos de uso muy o bien vestidos
Atributos
Los mismos que el caso mal vestido
Alternativas
Variaciones
Inclusiones
Extensiones
Se 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
Knowledge
Management
Change
Management
IT Governance
BusinessProcess
Management
Project Management
Office
Best Practices
PM.MED.21
VERSION 1.1
SERVICIOS
TEST FUNCIONAL
SELECCIN DE CASOS
S
O
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
de67
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 proceso
Esfuerzo de testing involucrado
Pruebas mitigantes
Costos de esas pruebas
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
Los riesgos
No 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.
S
O
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
de67
Como asignar el tipo de riesgo
Factores de riesgo:
Requerimiento
Severidad
Probabilidad
Costo
Visibilidad
Tolerancia
Factor Humano
Cada uno de los factores sern de
la misma escala y permitirn el
N/A.
S
O
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
de67
Costo
Se 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?
S
O
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
de67
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, inaceptable
Cantidad de pruebas previstas para el caso:
17.
Pregunta: Se deben hacer todos los 17
casos, mas o menos?
S
O
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
de67
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.
S
O
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
de67
Probabilidad y costo del riesgo
Los casos efectivamente tomados sobre
la cantidad de casos previstos nos
indica la cobertura de riesgo que
estamos tomando
Ejemplo:
Se tenan 17 casos previstos
Se ejecutarn 13 casos
Se 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.-
S
O
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
de67
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
Knowledge
Management
Change
Management
IT Governance
BusinessProcess
Management
Project Management
Office
Best Practices
PM.MED.21
VERSION 1.1
SERVICIOS
TEST FUNCIONAL
CAJA NEGRA
S
O
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
de67
Herramientas funcionales de caja
negra
Clases de equivalencia
Anlisis de frontera
Error guessing
Pairwise
S
O
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
de67
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.
S
O
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
de67
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).
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
Cero
Nmeros negativos
Valores significativos
Valores con significado cultural
Valores organizacionales
S
O
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
de67
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
Knowledge
Management
Change
Management
IT Governance
BusinessProcess
Management
Project Management
Office
Best Practices
PM.MED.21
VERSION 1.1
SERVICIOS
TEST FUNCIONAL
CAJA BLANCA
S
O
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
de67
Herramientas funcionales de caja
blanca.
Cobertura
Complejidad ciclomtica
Prueba de escritorio.
Prueba sintctica.
Prueba estructural.
Prueba funcional.
Revisin entre pares.
S
O
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
de67
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 !!!
S
O
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
de67
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.
S
O
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
de67
Prueba estructural
La cobertura de caminos es el
criterio mas completo
Cada camino debe ser probado
Caminos de prueba: ejecutar
cada bucle por lo menos una vez
Utilizando caminos de prueba se
puede cuantificar la cantidad de
caminos (permite asignar
correctamente los recursos)
S
O
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
de67
Indicador del nmero de caminos
independientes que existen en un grafo.
Ejecucin de un conjunto de caminos
independientes
La 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
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
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.
S
O
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
de67
Prueba de escritorio
Planear la prueba de escritorio.
Prueba sintctica.
Prueba estructural.
Prueba funcional.
Reporte final.
S
O
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
de67
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?.
S
O
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
de67
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?
S
O
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
de67
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?
S
O
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
de67
Reporte final
El reporte final es opcional.
Debe quedar claro quien y cuando
encontr el error.
Debe determinar si el error es
reproducible
Debe 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
Knowledge
Management
Change
Management
IT Governance
BusinessProcess
Management
Project Management
Office
Best Practices
PM.MED.21
VERSION 1.1
SERVICIOS
PRUEBA FUNCIONAL
EPLOGO
S
O
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
de67
E
P
L
O
G
O
Dudas, preguntas, angustias, llantos, crisis de nervios,
problemas existenciales, dramas o consultas?
S
O
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
de67
MUCHAS GRACIAS
CURSO BRINDADO POR:
ALONSO CARRA S.A.
SOLER 4418 4to. 17
(C1425BWZ) - BUENOS AIRES
www.alonsocarra.com
info@alonsocarra.com
ARGENTINA
EXPOSITOR
DANIEL E. ALONSO
(011)15-5104-0165
daniel.alonso@alonsocarra.com
E
P
L
O
G
O

Curso Testing Funcional (Alonso Carra)

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Curso Testing Funcional (Alonso Carra)

Încărcat de

Drepturi de autor:

Formate disponibile

www.alonsocarra.com info@alonsocarra.

S-ar putea să vă placă și