Expositores: Daniel Rojas y Héctor Norte "Conquistar sin riesgo es triunfar sin gloria" dijo Pierre Corneille escritor francés del siglo XVII. El riesgo está en todos los ámbitos de la vida, desde tiempos memorables, si no hubiéramos aprendido a asumirlos y a tomar decisiones teniéndolos identificados seguramente seguiríamos balanceándonos en los árboles. Gestionar los riesgos de un proyecto de forma efectiva es muchas veces determinante para el éxito de éste, medir su impacto, ocurrencia, tener técnicas para lidiar con ellos forma parte de la gestión que leads y managers deben asumir como una de sus tareas prioritarias. Esta charla apunta a "conquistar con gloria" gestionando inteligentemente nuestros riesgos con técnicas sencillas, deducidas por el sentido común pero normalizadas en ensayos con resultados positivos comprobados. Compartiremos experiencias y formas de lidiar con los riesgos más comunes que surgen en QA, buscando dejar a los presentes la semilla de la gestión temprana un poco más implantada.

1. El arte de prever y
gestionar
en el Testing
Senior QA Engineer: Daniel Rojas: Daniel.e.rojas@Gmail.com
QA Manager: Hector Norte:hectornorte@Gmail.com

2. Riesgo es “lo que depara la providencia”. El término
hace referencia a la proximidad o contingencia de un
posible daño.
La Gestión de Riesgos es todo el conjunto de
actividades y medidas que tienen por objeto el
control de riesgos con el fin de mantener el control
sobre un proyecto.
Definición:

3. Necesidad de la Gestión de Riesgos
surge de la incertidumbre
(Resto de)‫‏‬
Gestión de proyectos
Gestión de riesgos
Cierto
Incierto

4. Proceso de Gestion de Riesgos
Identificación del riesgo
Probabilidad y análisis
de impacto
Plan de respuesta al
riesgo
Seguimiento y control
de errores
Risk
Management

5. Tecnicas de identificacion de riesgos
Lluvia de ideas Diagrama espina de pescado
Mapas Mentales
RBS (Risk Breakdown Structure)

6. Risk Breakdown Structure

7. Los pecados de la Gestión de Riesgos
Matar al Mensajero
• Ignorar el registro histórico de riesgos
• Asignar todos los riesgos al PM/Scrum Master
• Utilizar la Estructura de Desglose del Riesgo (RBS) incompleta
• Tener subjetividad al momento de Identificar los Riesgos
Descuidar el Análisis de Costo/Beneficio de Gestión de Riesgos
• Hacerlo SÓLO una vez (inicio)

8. Identificar riesgos en QA
Entradas:
• Plan de testing
• Plan de gestion de recursos
• Infraestructura
• Test case design
• Requerimientos
• Politicas organizacionales
Herramientas:
• Revisión de
documentación
• Tecnicas de recomplilacion
de la información
• Checklist
• Analisis de suposición
Assumption
• Análisis FODA
• Juicio de expertos
Salida
• Registro del Riesgo

9. Una vez identificados los riesgos, es
necesario manejarlos
...qué debo hacer?
...qué debo hacer?
muchos riesgos ...
... cuál primero?
plan de riesgos
...¿que es eso?
….

10. Una vez identificados los riesgos, es
necesario manejarlos
Planes de Respuesta
Evitar Aprovechar
Mitigar Mejorar
Planificación de
Contigencias
Compartir
Aceptar
Transferir

11. Risk Based testing Strategy
Es una metodología que consiste en identificar riesgos y de acuerdo a esto
determinar el enfoque de las pruebas dando un uso más efectivo de los recursos
de testing
Requerimientos, diseño,etc
Identificación y Evaluación
de riesgos
Test Planning
Diseño de casos
Ejecución de casos Reportes
Bug data
Priorización de
áreas de testing

12. Identificación y evaluación de riesgos
Exposición del
riesgo
Daño
Criticidad
Visibilidad
Frecuencia
Chance de daño
Daños encontrados
anteriormente
Complejidad del área
Área con nueva
tecnología implementada
Presión de tiempo
1. Asignar de 0 a 10 pts por factor
2. Cada nivel se pondera con 0 a 3 pts
1. Asignar de 0 a 10 pts por factor
2. Cada nivel se pondera con 0 a 3 pts
3. A 5 factores con máximo total de 150 pts se
divide entre este valor para sacar promedio

13. Riesgos Visibles
Anticipar los riesgos (“malas noticias muy tarde”)
Trabajar sobre la cobertura (“no Test Cases”)
Aprendizaje Continuo = Gestión de Riesgos Continua
Comunicar y Colaborar
“Porque QA no encontró ese bug?” vs “Porque no encontramos ese bug?”