Capacitacitación Tester - QA 5

1. Capacitación
Tester
QA
Julio,
2011

2. Revisiones
Propagación:
ü Los
Errores
y/o
Fallas
se
propagan
en
los
Requerimientos
al
Diseño
y
luego
al
Código.
ü Los
Errores
y/o
Fallas
en
el
Diseño
se
propagan
al
Código.
ü El
Código
8ene
sus
propios
Errores
y/o
Fallas.
ü La
corrección
de
los
Errores
y/o
Fallas
en
los
Requerimientos
también
se
transmiten
a
la
corrección
en
Diseño
y
en
el
Código.

3. Revisiones
%
de
Errores
producidos
por
etapa:
ü Requerimientos:
8%
aprox.
ü Diseño
Funcional:
17%
aprox.
ü Diseño
Lógico:
30%
aprox.
ü Codificación:
25%
aprox.
ü Otras:
20%
aprox.

4. Revisiones
Una
revisión
podría
hacerse
enteramente
como
una
ac8vidad
manual.
Si
no
hay
soporte
de
herramientas
disponibles.
La
ac8vidad
manual
principal
es
examinar
un
producto
de
trabajo
y
hacer
comentarios
al
respecto.
Cualquier
entregable
de
soTware
puede
ser
revisado,
incluyendo:
ü Requisitos
y
especificaciones
de
diseño
de
código
fuente.
ü Planes
de
prueba,
casos
de
prueba,
scripts
de
prueba.
ü Documentación
para
el
usuario.
ü Aplicación
de
administración
y
material
de
apoyo.
ü Páginas
web.
Un
entregable
de
soTware
puede
ser
revisado
una
o
más
veces
y
se
puede
u8lizar
uno
o
más
8pos
de
revisión.
Revisar
todo
lo
más
pronto
posible.

5. Revisiones
En
la
Revisiones
se
encuentran
Defectos
y
en
las
Pruebas
Dinámicas
se
encuentran
Fallas.
En
las
Revisiones
los
defectos
picos
son
fácilmente
encontrados
y
en
las
Pruebas
Dinámicas
son
encontrados:
ü Desviaciones
de
los
Estándares.
ü Defectos
en
los
Requerimientos.
ü Defectos
del
Diseño.
ü Insuficiencia
en
el
Mantenimiento.
ü Especificaciones
incorrectas
de
interfaces.

6. Revisiones
Beneficios:
ü Detectar
fallas,
introducidas.
ü Reducir
el
riesgo
de
propagación
de
errores
/
fallas.
ü Detectar
los
defectos
que
la
ejecución
de
la
prueba
dinámica
poco
pueda
encontrar,
por
ejemplo,
los
errores
de
especificación
de
requisitos.
ü Acortar
los
plazos
de
desarrollo.
ü Reducir
los
niveles
de
fallas
en
el
soTware
entregado.
ü Menor
costo
y
acortar
los
plazos
las
pruebas.
ü Menor
costo
durante
la
vida
ú8l
del
soTware.
ü Crear
mejoras
en
el
desarrollo
de
la
produc8vidad.
ü Fiable
evalúa
el
progreso
y
la
capacidad.
ü Educa
y
entrena
a
los
par8cipantes.
ü Mejorar
la
comunicación
entre
los
equipos
de
proyecto.

7. Revisión
Informal
ü No
hay
proceso
formal
de
revisión
por
empleados.
ü “Revisión
de
Escritorio",
en
busca
de
posibles
problemas.
ü El
autor
del
material
es
su
propio
control
de
calidad,
posiblemente
con
otro
compañero
(Peer
Review).
ü Es
posible
que
un
jefe
de
diseño
realice
una
revisión
técnica
del
código.
ü Por
lo
general,
indocumentada,
pero
ú8l,
barata
y
ampliamente
u8lizada.
ü Esta
técnica
puede
ser
aplicada
en
situaciones
de
bajo
riesgo.
ü No
hay
cifras
de
los
resultados
de
la
revisión.
ü Debilidades
-­‐
no
encuentra
defectos
hasta
revisiones
formales.

8. Revisión
Formal
-­‐
Tutoriales
ü Un
Tutorial
es
una
revisión
del
material
escrito
por
el
autor
y
la
par8cipación
de
un
grupo
de
compañeros
del
autor
(por
lo
general
2
a
6
pares).
El
Obje8vo
Principal
es
la
educación.
ü El
material
es
presentado
por
el
autor
para
el
grupo
de
pares,
que
se
centran
en
el
aprendizaje
de
la
materia,
mejorarla
y
corrección
de
defectos.
ü Grupo
de
pares
debe
incluir
el
desarrollo,
representantes
de
la
operación,
el
público
obje8vo,
etc.
ü Las
sesiones
pueden
ser
formales
o
informales.
ü Sesiones
de
revisión
a
menudo
abiertas.
ü Pre-­‐encuentro
de
preparación
con
los
involucrados.
ü Debilidades
-­‐
no
encuentra
tantos
defectos
como
en
las
revisiones
técnicas
y
en
las
inspecciones.

9. Revisión
Formal
–
Peer
Review
Se
pueden
realizar
los
Peer
Review
sin
la
par8cipación
del
gestor.
Preferentemente
dirigido
por
un
moderador
capacitado
(no
el
autor).
Pre-­‐Encuentro,
se
requiere
preparación.
Obje8vo
principal
es:
ü Discu8r.
ü Tomar
decisiones.
ü Evaluar
las
alterna8vas.
ü Encontrar
defectos.
ü R esolver
problemas
técnicos
y
comprobar
la
conformidad
con
las
especificaciones
y
normas.
Grado
de
formalidad
varía.
Revisores
traen
una
lista
de
cues8ones
técnicas
para
el
examen.
El
uso
opcional
de
listas
de
comprobación
y
un
informe
de
revisión.
Durante
la
reunión
los
revisores
formulan
objeciones,
las
ambigüedades
e
incoherencias
en
el
diseño
o
aspectos
técnicos
en
discusión.
Los
problemas
son
aclaradas
y
documentadas
-­‐
se
buscan
soluciones
después
de
que
la
revisión
ha
concluido.
Debilidades
-­‐
no
encuentra
tantos
defectos
como
en
las
inspecciones.

10. Revisión
Formal
–
Inspecciones
ü Revisiones
formales
y
sistemá8cas
de
los
materiales.
Obje8vo
principal
es
encontrar
fallas
y
mejora
de
procesos.
ü Dirigido
por
un
moderador
independiente
preparado
(pero
no
el
autor).
ü Principal
obje8vo
-­‐
encontrar
defectos.
ü Asiste
el
autor
y
sus
compañeros
(generalmente
de
3
a
6)
que
actúan
en
roles
definidos.
ü Preparación
de
la
reunión
previa,
esencial.
ü Seguir
un
formato
estricto.
ü Señalar
los
criterios
de
inclusión
y
criterios
de
salida.
ü La
búsqueda
y
registro
de
los
defectos.
ü Uso
de
reglas
estandarizadas,
listas
de
control
y
técnicas.
ü Métricas.
ü Opcionalmente
mejora
las
consideraciones
del
proceso
en
revisión.
ü Debilidades
-­‐
rendimiento
caro
y
consume
8empo.

11. Proceso
de
la
Revisión
Formal
Planeación:
ü Definir
los
criterios
de
entrada
y
salida
(para
una
revisión
más
formal).
ü Asegúrese
de
que
el
volumen
de
material
a
ser
revisado
es
apropiado.
ü Iden8ficar
los
roles,
los
par8cipantes
y
establecer
un
8empo
y
lugar
para
la
revisión.

12. Proceso
de
la
Revisión
Formal
Kick
Off:
ü Distribuir
el
material
a
los
par8cipantes.
ü Explicar
los
obje8vos,
procesos
y
materiales
a
ser
revisados.
ü Obtener
copias
de
las
plan8llas
de
revisión
per8nentes.
ü Crear
listas
de
control
de
las
áreas
a
cubrir
y
distribuir
listas
de
verificación
pueden
hacer
las
revisiones
más
eficaces
y
eficientes.
ü Por
ejemplo;
una
lista
de
verificación
sobre
la
base
de
puntos
de
vista
como
usuario,
desarrollador,
probador
o
de
las
operaciones
o
una
lista
de
los
problemas
de
los
requisitos
picos
para
centrarse
en
hacer
que
los
criterios
de
entrada
ha
sido
/
serán
recibidos.

13. Proceso
de
la
Revisión
Formal
Overview
(Opcional):
Necesidades
para
el
nuevo
material
o
de
dikcil
visión
general:
ü Educar
a
los
par8cipantes.
ü Permiten
a
los
par8cipantes
centrarse
en
el
contenido
técnico.
ü Describe
el
lugar
donde
el
material
se
integra
en
el
sistema
y
en
el
proceso
de
desarrollo.
ü Se
centran
en
la
funcionalidad
compleja.
ü Señala
los
cambios
y
explica
la
necesidad
de
estos
cambios.

14. Proceso
de
la
Revisión
Formal
Preparación:
Cada
par8cipante
revisa
el
material
para:
ü Aprender
sobre
el
material.
ü Tener
en
cuenta
la
sospecha
de
los
defectos.
ü Registro
de
las
preguntas.
ü En
algunas
circunstancias,
dependiendo
de
la
experiencia
de
los
par8cipantes,
el
moderador
puede
preguntar
a
algunos
par8cipantes
aspectos
par8culares
del
material
durante
la
preparación.

15. Proceso
de
la
Revisión
Formal
Reunión:
ü Materiales
se
leen
a
los
par8cipantes.
ü Los
defectos
son
planteados
por
los
par8cipantes
y
registrados.
ü Los
par8cipantes
pueden
tomar
decisiones
sobre
la
clasificación
y
manejo
de
los
defectos,
aunque
por
lo
general
se
evita
la
"solución”.
ü Entregables
pueden
incluir
actas
de
las
reuniones.
ü Para
Inspecciones
-­‐
Pase
o
no,
repe8r
las
decisiones
de
revisión.
ü El
8empo
de
preparación
y
el
8empo
real
puede
ser
registrado.

16. Proceso
de
la
Revisión
Formal
Re-­‐trabajo:
ü El
autor
debe
resolver
todos
los
defectos
encontrados
durante
la
revisión
para
re-­‐trabajar
el
material
según
las
recomendaciones
del
informe
de
revisión.
ü Tenga
en
cuenta,
el
costo
de
reproceso
no
está
incluido
en
el
costo
de
las
revisiones.

17. Proceso
de
la
Revisión
Formal
Seguimiento:
ü Comprobar
la
corrección
del
material
y
dar
cuenta
de
todos
los
defectos
registrados.
ü Si
es
necesario,
haga
una
nueva
revisión
del
material
corregido.
ü Informar
a
la
dirección
del
material
corregido.
ü Agregue
los
defectos
en
la
base
de
datos
de
estadís8cas
del
proyecto
-­‐
permite
la
mejora
del
proceso!.
ü Completar
y
firmar
el
informe
de
revisión
y
formularios
(inspecciones).
ü Garan8zar
los
criterios
de
salida.

18. Proceso
de
la
Revisión
Formal
Otros
Qpos:
ü Revisiones
por
la
dirección
-­‐
Los
comentarios
de
los
planes,
programas,
avances.
ü Auditorías
-­‐
evaluación
independiente
de
conformidad
con
las
normas,
planes
y
procedimientos.
ü Posteriores
a
la
implementación
-­‐
revisión
del
enfoque
del
proyecto
(incluyendo
el
enfoque
de
la
prueba).

19. Análisis
EstáQco
Es
el
Análisis
de
los
artefactos
de
soTware,
por
ejemplo,
requisitos
o
código,
llevado
a
cabo
sin
la
ejecución
de
estos
artefactos
de
soTware.
ObjeQvo
-­‐
encontrar
defectos
en
el
código
fuente
del
soTware
y
modelos
de
soTware.
El
análisis
está8co
se
realiza
sin
ejecutar
el
soTware,
siendo
examinado
por
la
herramienta,
mientras
que
las
pruebas
dinámicas
se
ejecuta
el
código
del
soTware.
El
análisis
está8co
puede
localizar
los
defectos
que
son
dikciles
de
encontrar
en
las
pruebas.
Como
con
las
revisiones,
el
análisis
está8co
encuentra
defectos
en
vez
de
las
fallas.
Las
Herramientas
de
análisis
está8co
analizan
el
código
del
programa
(por
ejemplo,
gráficos
con
control
de
flujo
y
técnicas
de
análisis
de
flujo
de
datos),
así
como
la
salida
generada
como
HTML
y
XML.

20. Análisis
EstáQco
ü La
detección
temprana
de
los
defectos
antes
de
la
ejecución
de
las
pruebas.
ü Alerta
a
8empo
sobre
los
aspectos
sospechosos
del
código
o
el
diseño.
ü Cálculo
de
los
indicadores
como
una
medida
de
alta
complejidad.
ü Iden8ficación
de
los
defectos
que
no
se
encuentran
fácilmente
en
las
pruebas
dinámicas.
ü Dependencias
de
la
detección
e
inconsistencias
en
los
modelos
de
soTware,
tales
como
enlaces.
ü Mantenimiento
mejorado
de
código
y
de
diseño.
ü Prevención
de
los
defectos,
si
las
lecciones
se
aprenden
en
el
desarrollo.
ü Rentable
-­‐
los
problemas
encontrados
anteriormente
son
más
baratos
para
arreglar.
ü El
análisis
está8co
es
más
eficaz
y
menos
costoso
que
la
prueba
dinámica.
ü El
análisis
está8co
demuestra
encontrar
el
45%
de
errores
esperados
antes
de
que
la
prueba
realmente
inicie.

21. Análisis
EstáQco
ü La
detección
temprana
de
los
defectos
antes
de
la
ejecución
de
las
pruebas.
ü Alerta
a
8empo
sobre
los
aspectos
sospechosos
del
código
o
el
diseño.
ü Cálculo
de
los
indicadores
como
una
medida
de
alta
complejidad.
ü Iden8ficación
de
los
defectos
que
no
se
encuentran
fácilmente
en
las
pruebas
dinámicas.
ü Dependencias
de
la
detección
e
inconsistencias
en
los
modelos
de
soTware,
tales
como
enlaces.
ü Mantenimiento
mejorado
de
código
y
de
diseño.
ü Prevención
de
los
defectos,
si
las
lecciones
se
aprenden
en
el
desarrollo.
ü Rentable
-­‐
los
problemas
encontrados
anteriormente
son
más
baratos
para
arreglar.
ü El
análisis
está8co
es
más
eficaz
y
menos
costoso
que
la
prueba
dinámica.
ü El
análisis
está8co
demuestra
encontrar
el
45%
de
errores
esperados
antes
de
que
la
prueba
realmente
inicie.