Capacitacitación tester qa 4

1. Capacitación
Tester
QA
Junio,
2011

2. Psicología
del
Tes6ng
Mentalidad
del
Tes6ng
ü Inicialmente
el
Tes4ng
fue
considerado
como
una
forma
de
validar
si
se
sa4sfacían
los
requerimientos
del
so<ware.
ü Evolucionó
al
obje4vo
de
detectar
fallas
en
lugar
de
demostrar
la
corrección.
Un
proceso
destruc4vo.
ü Se
puedes
considerar
como
una
crí4ca
del
producto
y/o
del
autor.
ü Buscar
fallas
es
construc4vo:
v Recuperar
Tiempo.
v Reducción
de
Costos.
v Reducción
de
Riesgos.
v Mejora
de
competencias.

3. Psicología
del
Tes6ng
Es
importante
que
los
obje4vos
de
las
pruebas
se
en4endan
claramente
como
seres
humanos,
será
el
moderador
de
su
conducta
en
consecuencia
(aunque
de
manera
inconsciente):
"Si
el
análisis
se
muestra
que
el
sistema
sa4sface
sus
requerimientos,
sólo
voy
a
producir
las
pruebas
que
lo
demuestran.“
"Si
la
prueba
4ene
el
fin
de
encontrar
fallas
entonces
se
medirá
en
fallas,
así
que
voy
a
poner
esfuerzo
en
el
diseño
de
pruebas
que
4enen
más
probabilidades
de
encontrar
las
fallas.“
La
mentalidad
de
prueba
es
diferente
a
la
de
un
Desarrollador.

4. Psicología
del
Tes6ng
“La
prueba
es
una
tarea
extremadamente
crea4va
e
intelectualmente
desafiante
“
"Las
pruebas
deben
ser
escritas
para
inválidos
e
inesperados,
así
como
válidas
y
esperadas
las
condiciones
de
entrada“.

5. Psicología
del
Tes6ng
Rasgos
de
un
Buen
Tester:
Necesita:
ü Habilidad
para
la
Buena
Comunicación.
ü Habilidad
para
la
Buena
Observación.
ü Habilidad
para
la
Manipulación
Personal.
ü Curiosidad.
ü Paciencia.
ü Fiabilidad.
ü Minuciosidad.
ü Naturaleza
Inquisi4va.
ü Atención
a
los
Detalles.
ü Crea4vidad
para
la
iden4ficación
de
posibles
detalles.
ü Experiencia.
Sin
embargo,
como
con
la
mayoría
de
otras
disciplinas,
un
equipo
de
prueba
efec4va
necesitará
una
combinación
de
habilidades
por
lo
que
es
di^cil
generalizar.

6. Psicología
del
Tes6ng
Relación
Tester
VS
Desarrollador
Esta
relación
normalmente
no
es
fácil
por
las
siguiente
razones:
ü El
tester
señala
problemas
con
el
so<ware.
ü Los
desarrolladores
suelen
pensar
que
su
so<ware
es
perfecto.
ü Los
tester
son
percibidos
como
factores
que
retrasan
un
proyecto.
ü Cuando
los
desarrolladores
se
retrasan
regularmente
los
tester
deben
realizar
largas
jornadas
de
trabajo
para
recuperar
el
4empo.
Es
importante
que
trabajen
juntos.
Es
m{as
importante
que
el
respeto
sea
mutuo.
La
colaboración
es
el
enfoque
correcto,
!trabajamos
para
un
obje6vo
común¡.
Comunicar
los
resultados
de
las
pruebas
de
manera
obje4va
y
no
subje4va.

7. Psicología
del
Tes6ng
Tes6ng
Independiente
El
derecho
de
pensar
podría
permi4r
a
los
desarrolladores
para
probar
el
código.
Sin
embargo,
pasar
esta
responsabilidad
a
los
recursos
de
prueba
profesionales
4ene
muchos
beneficios
(como
una
mayor
tasa
de
defectos
encontrados).
Los
autores
4enden
a
suponer
al
desarrollar
el
so<ware.
Ellos
son
menos
propensos
a
escribir
las
pruebas
para
mostrar
fallas
en
su
propio
so<ware
(la
naturaleza
humana).
Con
las
pruebas
realizadas
por
evaluadores
independientes,
el
esfuerzo
está
enfocado
a
las
pruebas
y
no
se
ve
comprome4do
por
el
esfuerzo
de
desarrollo
y
los
prejuicios.
En
general
se
cree
que
en
las
pruebas
independientes
el
obje4vo
es
más
eficaz.

8. Psicología
del
Tes6ng
Tes6ng
Independiente
Hay
varios
niveles
en
de
la
independencia
(de
menor
a
mayor):
ü Pruebas
diseñadas
por
la
persona(s)
que
escribió
el
so<ware
bajo
prueba.
ü Pruebas
diseñadas
por
otra
persona(s)
(por
ejemplo,
el
equipo
de
desarrollo).
ü Pruebas
diseñadas
por
una
persona(s)
de
un
grupo
diferente
a
la
organización
(por
ejemplo,
un
equipo
de
pruebas
independiente).
ü Pruebas
diseñadas
por
una
persona(s)
de
una
organización
o
empresa
diferente
(por
ejemplo,
la
subcontratación
a
una
empresa
o
ins4tución
externa
especialista
en
pruebas).

9. Psicología
del
Tes6ng
Tes6ng
Independiente
Hay
varios
niveles
en
de
la
independencia
(de
menor
a
mayor):
ü Pruebas
diseñadas
por
la
persona(s)
que
escribió
el
so<ware
bajo
prueba.
ü Pruebas
diseñadas
por
otra
persona(s)
(por
ejemplo,
el
equipo
de
desarrollo).
ü Pruebas
diseñadas
por
una
persona(s)
de
un
grupo
diferente
a
la
organización
(por
ejemplo,
un
equipo
de
pruebas
independiente).
ü Pruebas
diseñadas
por
una
persona(s)
de
una
organización
o
empresa
diferente
(por
ejemplo,
la
subcontratación
a
una
empresa
o
ins4tución
externa
especialista
en
pruebas).

10. Modelo
V
User/Business
Acceptance
Test
Acceptance
Requirements
Plan
Test
System
Test
System
Requirements
Technical
Specifica4on
Development
Levels
Program
System
Plan
Test
Integra4on
Integra4on
Test
Plan
Test
Unit
Test
Plan
Test
Specifica4on
Coding
Test
Unit
Levels

11. Modelo
V
Beneficios:
ü A
las
fases
de
prueba
se
les
da
el
mismo
nivel
de
atención
por
parte
de
la
administración
y
el
compromiso
como
las
fases
de
desarrollo
correspondientes.
ü Los
resultados
de
las
fases
de
desarrollo
son
revisados
por
el
equipo
de
pruebas
para
garan4zar
su
capacidad
de
prueba.
ü Verificación
y
validación
(y
diseño
de
la
prueba
an4cipada)
puede
llevarse
a
cabo
durante
el
desarrollo
de
los
productos
de
so<ware
.
ü La
planificación
inicial
y
el
diseño
preliminar
de
pruebas
ofrece
comentarios
adicionales
de
revisión
en
las
salidas
de
la
fase
de
desarrollo.

12. Modelo
V
Los
niveles
de
desarrollo
y
pruebas
que
se
muestra
en
el
modelo
varían
de
proyecto
a
proyecto.
Por
ejemplo,
es
posible
que
los
niveles
de
prueba
adicionales,
tales
como
Pruebas
de
Integración
de
Sistema,
ubicadas
entre
las
pruebas
de
sistema
y
las
pruebas
de
aceptación
de
usuario.
Los
productos
de
trabajo
que
salen
de
cualquier
nivel
de
desarrollo
se
puede
u4lizar
en
una
o
más
niveles
de
prueba.
Por
ejemplo,
mientras
que
la
fuente
principal
para
las
pruebas
de
aceptación
es
el
requisito
de
negocio,
los
requisitos
del
sistema
(por
ejemplo,
casos
de
uso)
también
pueden
ser
necesarios
para
apoyar
el
diseño
detallado
de
las
pruebas.

13. Modelo
V
"El
modelo
V
proporciona
una
herramienta
potente
de
ges4ón
y
control
del
riesgo
en
el
componente
de
prueba
de
un
proyecto.
El
proceso
de
armonización
de
la
planificación
de
pruebas
y
diseño
en
el
proceso
de
desarrollo
permite
iden4fica
los
riesgos
lo
antes
posible
y
permite
que
se
ejecuten
las
estrategias
para
eliminar
o
mi4gar
riesgos
a
su
debido
4empo."

14. Modelo
de
Desarrollo
Itera6vo
e
Incremental
El
desarrollo
itera4vo-­‐incremental:
ü Establecer
los
requisitos.
ü Diseño
del
Sistema.
ü Construcción
del
sistema.
ü Prueba
del
Sistema.
Obtenidos
con
la
evolución
de
pequeñas
-­‐
iteraciones
y
/
o
incrementos
(posiblemente
en
iteraciones).
Como
iteraciones
/
incrementos
se
han
desarrollado
y
probado
los
crecimientos
del
sistema.
Necesidad
de
más
pruebas
de
regresión
sumadas.
Por
ejemplo
RAD,
RUP
son
modelos
de
desarrollo
ágil.
Desarrollo
ágil:
ü Obje4vo
es
ofrecer
so<ware
temprano
y
con
frecuencia.
ü Producción
rápida
y
"4me
to
market
“.
ü Puede
manejar
(y
se
an4cipa
a)
las
necesidades
cambiantes
en
todas
las
fases
de
desarrollo
y
pruebas.

15. Modelo
de
Desarrollo
Itera6vo
e
Incremental
Rapid
Applica4on
Development:
Requerimientos
de Usario
Codigo
Pruebas de
Aceptación

16. Modelo
de
Pruebas
dentro
del
Ciclo
de
Vida
Caracterís4cas
de
las
buenas
pruebas
en
cualquier
modelo
de
ciclo
de
vida:
ü Un
nivel
de
pruebas
existe
para
cada
nivel
de
desarrollo.
ü Cada
nivel
de
pruebas
4ene
obje4vos
específicos.
ü Análisis
y
de
diseño
de
pruebas
para
cada
nivel
de
prueba
se
inicia
durante
el
correspondiente
nivel
de
desarrollo.
ü Par4cipación
temprana
y
ac4va
de
testers
en
la
revisión
de
resultados
de
desarrollo
-­‐
beneficia
ambas
partes.
Niveles
de
prueba
deben
ser
adaptados
en
función
de
la
naturaleza
del
proyecto.
Puede
ser
mejor
para
combinar
los
niveles
de
prueba.

17. Pruebas
de
Componente
ü Componente
-­‐
Un
arfculo
del
so<ware
mínimo
que
se
puede
probar
de
forma
aislada.
ü Pruebas
de
Componentes
-­‐
Pruebas
de
componentes
individuales
de
so<ware.
ü A
veces
se
conoce
como
pruebas
unitarias,
pruebas
de
modelo
o
pruebas
de
programa.
ü Un
Componente
se
puede
probar
de
forma
aislada
-­‐
se
pueden
emplear
controladores
.
ü Los
casos
de
prueba
son
derivados
de
las
especificaciones
de
componentes
(módulo
/
especificaciones
del
programa).
ü Pruebas
Funcionales
y
Pruebas
No
Funcionales.
ü Por
lo
general
realizadas
por
el
desarrollador,
con
la
herramienta
para
debugging.
ü Solución
de
Defectos
Rápido
e
Informal.

18. Pruebas
de
Componente
Enfoque
de
las
Pruebas
Iniciales
/
Ensayo
-­‐
crear
las
pruebas
para
el
diseño
y
la
construcción
del
código!.
En
lugar
de
crear
un
diseño
que
le
diga
cómo
estructurar
el
código,
se
crea
una
prueba
que
define
como
una
pequeña
parte
del
sistema
debe
funcionar.
Tres
pasos:
1) Diseño
de
la
prueba
es
definido
en
base
a
cómo
crees
que
una
pequeña
parte
del
so<ware
debe
comportarse
(desarrollo
incremental).
2) Haga
la
prueba
de
funcionamiento
con
la
misma
facilidad
y
rapidez
posible.
No
se
preocupe
sobre
el
diseño
de
código,
sólo
preocúpese
por
conseguir
que
funcione!.
3) Limpiar
el
código.
Ahora
que
el
código
funciona
correctamente,
de
un
paso
atrás
y
elimine
cualquier
duplicación
o
cualquier
otro
problema
que
se
presentó
para
ejecutar
de
nuevo
las
pruebas.

19. Pruebas
de
Integración
Pruebas
de
Integración
–
Son
las
pruebas
realizadas
para
exponer
los
defectos
de
las
interfaces
y
las
interacciones
entre
los
componentes
integrados
o
sistemas.
Los
componentes
pueden
ser
módulos
del
código,
sistemas
opera4vos,
hardware,
incluso
sistemas
completos.
Hay
dos
niveles
de
Pruebas
de
Integración:
ü Pruebas
de
Integración
de
Componentes.
ü Pruebas
de
Integración
de
Sistema.

20. Pruebas
de
Integración
de
Componentes
ü Pruebas
de
Integración
de
Componentes:
Son
las
pruebas
realizadas
para
exponer
los
defectos
de
las
interfaces
y
la
interacción
entre
los
componentes
integrados.
ü Por
lo
general
realizadas
por
el
desarrollador,
pero
podrían
involucrar
formalmente
al
equipo
de
pruebas
(registros
de
diseño
de
la
prueba
y
de
la
ejecución).
ü Todos
los
componentes
individuales
deben
ser
probados
en
integración
para
hacer
después
hacer
pruebas
de
sistema.

21. Pruebas
de
Integración
de
Componentes
Planeación:
Para
considerar
-­‐
El
enfoque
de
las
pruebas
de
integración:
¿Iniciaremos
del
Nivel
Superior
de
componentes
hacia
abajo?
¿Iniciaremos
del
Nivel
Inferior
de
componentes
hacia
arriba?
¿U4lizaremos
el
método
del
big
bang?
¿Nos
basaremos
en
grupos
funcionales?
¿Iniciaremos
con
los
componentes
crí4cos?
¿Nos
basaremos
en
la
secuencia
de
negocios?
El
conocimiento
de
la
arquitectura
del
sistema
es
importante.
Cuanto
mayor
sea
el
alcance
del
enfoque
de
integración,
más
di^cil
es
aislar
defectos.
Requisitos
de
pruebas
no
funcionales
pueden
empezar
por
aquí
-­‐
por
ejemplo,
especificaciones
de
rendimiento.

22. Pruebas
de
Integración
de
Componentes
Pruebas
Top-­‐Down:
A
B
D
C
E
F
G

23. Pruebas
de
Integración
de
Componentes
Pruebas
Top-­‐Down:
Pro’s
Contras
ü Proporciona
un
sistema
limitado
para
ü T a l o n e s
s ó l o
p r o p o r c i o n a n
trabajar
al
inicio
en
el
proceso
de
s i m u l a c i o n e s
l i m i t a d a s
d e
diseño.
componentes
de
nivel
inferior
y
ü L a
p r i m e r a
i n t e g r a c i ó n
d e
podría
influir
en
los
resultados
falsos.
profundidad
muestra
las
funciones
de
ü La
extensión
significa
que
los
niveles
extremo
a
extremo
al
inicio
en
el
del
sistema
deben
ser
ar4ficialmente
proceso
de
desarrollo.
obligados
a
generar
una
salida
para
ü La
detección
temprana
de
errores
de
las
validaciones
de
prueba.
diseño
hasta
la
implementación
al
inicio
de
la
estructura
del
diseño.
ü Las
pruebas
de
control
de
los
puntos
de
decisión.
ü Este
enfoque
puede
permi4r
a
un
e m p a l m e
c o n
p r u e b a s
d e
componentes.

24. Pruebas
de
Integración
de
Componentes
Pruebas
BoSom-­‐Up:
A
Igualmente
B
y
C
son
D r i v e r s
d e
o t r o s
componentes.
D
B
A
es
el
Driver
para
los
componentes
B
y
C.
C
E
F
G

25. Pruebas
de
Integración
de
Componentes
Pruebas
BoSom-­‐Up:
Pro’s
Contras
ü Los
Drivers
que
u4lizan
en
lugar
de
ü Puede
que
un
componente
no
este
módulos
de
nivel
superior
para
disponible
desde
un
inicio
y
no
nos
simular
el
medio
ambiente
para
los
demos
cuenta
a
4empo.
módulos
de
nivel
inferior.
ü Detección
tardía
de
errores
en
la
ü Necesarios
para
los
componentes
estructura
del
sistema.
crí4cos,
de
bajo
nivel
en
el
sistema.
ü En
las
pruebas
se
puede
observar
en
los
componentes
a
probar
desde
el
principio.