6. Introducción – Qué descubrimos
Trabajamos a ciegas si no conocemos:
Nuestra misión
Contexto del producto y el proyecto
Criterios de calidad de los diferentes interesados
Qué problema espera resolver el cliente?
Y los distintos usuarios finales?
Cuál es su expectativa?
Si trabajamos a ciegas, no podemos determinar una
estrategia correcta, que ahorre costos y aporte valor
La calidad no es lo mismo para todos
7. Belleza … y calidad…
La Nación – Octubre 2009
“Beauty (quality) is in the eyes of its beholder”
- La belleza (calidad) está en los ojos del observador -
8. Conceptos básicos – Qué es CALIDAD
Que el producto haga lo que dicen los folletos o la caja, y
que el cliente lo compre
Que al usuario le guste y le permita ser productivo en su
trabajo
Cumplir los requisitos del cliente / de los interesados
Qué el cliente vuelva a comprar el producto, o lo
recomiende a otros
……
9. Conceptos básicos –
Quiénes son los INTERESADOS
Cliente Cliente /
Usuario
Líder de
Sponsor Usuario Auditor
Producto
Líder de Proyecto
Análisis Desarrollo Testing Tecnología Seguridad Operaciones
10. Conceptos básicos – El contexto del producto
Características
del producto
Características Criterios de
del proyecto Calidad
11. … un poco de humor…
“Nuestra meta es escribir software
libre de defectos.
“Viva! Sí, Sí! Somos ricos!!!”
Les pagaré un bono de 10 dólares por
cada defecto que encuentren y
corrijan.”
Dilbert – 1995
12. Conceptos básicos – Qué es TESTING
Una actividad empírica y/o investigación técnica
para ver si el producto hace lo que dicen los
folletos o la caja
Una forma de validar que el usuario pueda
utilizarlo y ser productivo en su trabajo
Actividades orientadas a validar que se cumplen
los requisitos del cliente
……
Encontrar los defectos (“bugs”)
13. BUGs ??? ….
Un caso real
1) Home Banking, busco movimientos entre fechas, presenta por defecto:
2) Cambio a 01/09/2009, convierte a:
3) Al dar aceptar:
4) Invirtiendo una fecha, funciona …
pero asume orden mes día:
14. Conceptos básicos – Qué es un defecto
Que el producto NO haga algo que dicen los
folletos o la caja
Que el usuario NO pueda cumplir con su actividad
parcial o totalmente
Que NO se cumpla algún requisito del cliente
……
Un defecto tiene que importar / afectar a
alguien, no sólo al tester
15. Nuestra misión
El testing es un servicio
Cuál es nuestra misión?
Entender objetivos de interesados y contexto del producto
Identificar criterios de calidad aplicables
Cuestionar y evaluar el producto
Focalizar los riesgos, entender los cambios
Investigar, explorar, proveer feedback
Confirmar, comunicar
Aportar valor al proceso de construcción sugiriendo mejoras
Cuál es nuestro rol?
Proveer a la gerencia información sobre la calidad
Siendo críticos con el producto y el proceso
Para permitir decisiones informadas
16. Nuestros objetivos
El testing es un servicio
Con qué objetivos trabajamos?
Encontrar defectos importantes
Lograr que se corrijan los defectos más importantes
Ayudar a clientes y usuarios a identificar y explicitar los
criterios de calidad
Evaluar la calidad del producto
Ayudar a la gerencia a determinar posibilidades de release
Impedir releases prematuros
Ayudar a predecir y controlar costos de mantenimiento
17. Nuestros objetivos (2)
El testing es un servicio
Con qué objetivos trabajamos?
Verificar interoperabilidad con otros productos
Identificar escenarios de uso seguros
Verificar cumplimiento de especificaciones
Certificar cumplimiento de un estándar determinado
Asegurar que el proceso de prueba sigue estándares
Minimizar el riesgo de acciones legales
(cliente no satisfecho, multas de un organismo
de control…)
Evaluar producto para una tercera parte ……..
18. Entrevista a candidato para tester
Dada la misión y los objetivos del trabajo del
tester, qué le pediríamos a un candidato en una
entrevista laboral?
19. Nuestras habilidades
Pensamiento crítico, reconocer errores y prejuicios
Pensamiento analítico, ser detallista, pero no perderse en detalles
(las hormigas y los elefantes)
Pensamiento sistemático, enfrentar la complejidad
Pensamiento basado en contexto, enfrentar situaciones cambiantes,
entender qué ocurre en el proyecto y en la organización
Pensamiento científico, diseñar y ejecutar experimentos
Habilidades cognitivas, aprender y observar,
en general, y sobre el negocio y el proceso
Habilidades de comunicación, informar
(CUIDADO, somos los mensajeros)
Programación, deseable, algunos testers
20. Nuestros derechos (como testers)
Recibir buenas especificaciones y código
Poder rechazar lo que no sirve
Tener una misión clara
Consensuada con los interesados
Opinar sobre el plan de trabajo
Participar en la planificación
Identificar riesgos y formas de mitigarlos
Contar con tiempo y recursos
Integrados al equipo de trabajo
Distribuida la carga de trabajo en el tiempo
Opinar sobre la calidad
En forma fundamentada y en base a evidencias
Qué pasa si salimos hoy?
21. Nuestros problemas habituales
Objeciones
Preguntas que debemos saber contestar
Los riesgos a mitigar
Cómo organizarnos para aportar valor
Identifican objeciones típicas ?
Identifican preguntas típicas ?
22. Las grandes objeciones
No necesitamos probar / No somos la NASA
No necesitamos probar a ese nivel de detalle
Cuesta mucho / Lleva mucho tiempo
No termina nunca / No tenemos tiempo / No está en el plan
Puede encontrar muchos problemas / Quedaremos mal
No podremos entregar en fecha / Demoraremos la salida del producto
El testing no aporta valor / A nadie le preocupan los defectos
Prueban los desarrolladores / Saben lo que hacen / Tienen mucha
experiencia
Los testers nunca encuentran lo importante
No tenemos tiempo de especificar los requerimientos
PERO …
Querríamos volar en un avión cuyo software no ha sido probado?
23. Las grandes preguntas
Qué es la calidad?
Para qué la necesitamos?
Qué pasa si no la tenemos?
Cómo la logramos?
Cuánto cuesta?
Es para nosotros?
24. Las siguientes preguntas
Por qué probamos?
Cómo probamos?
Cuándo comenzamos a probar?
Cuándo dejamos de probar?
Qué probamos?
Con qué probamos?
Hemos probado todo?
Podemos hacerlo mejor?
25. Los riesgos que enfrentamos
Desde la enfermedad de un integrante del proyecto…
… Hasta una acción legal a la empresa si el producto falla… y otros…
Pasando por:
Alcance o requerimientos indefinidos
Requerimientos conflictivos / cambiantes
Factores de éxito desconocidos
Calendarios y/o presupuestos irreales
Problemas de comunicación en el proyecto
Usuarios no involucrados / no comprometidos / problemas políticos
Nueva tecnología / poco conocimiento / falta de recursos capacitados
Pruebas inadecuadas
Complejidad
Dependencia de proveedores externos
No se valora el esfuerzo del equipo de testing, no se ve como algo útil, o
se quiere evitar que los problemas se hagan visibles
…………
26. Y cómo los mitigamos o transferimos
Implementación de Procesos definidos y Buenas Prácticas
Incorporación temprana de los usuarios en los proyectos,
pruebas de aceptación
Organización de Áreas de QA / QC
Equipos de Prueba en un Proyecto / Prueba en todo el ciclo de vida
Planificación de las pruebas
Capacitación a los recursos
Incorporación de Herramientas
Registración y Seguimiento de Defectos
Administración de Ciclos, Condiciones y Casos de Prueba
Métricas / Indicadores
Automatización
Administración de Cambios / Requerimientos / Configuración
Outsourcing / Tercerización
27. Cómo aportamos valor?
1 Reducción del Costo Total
Fallas en
Producción
2 Mejor Calidad - Mejor Imagen Ahorro
Facilita el
3
Control de Proyectos
Fallas Producción
Fallas en
Aceptación Fallas Aceptación
4 Facilita la Integración
Verificaciones
Ayuda a la Aplicación del
5 y Pruebas
Proceso
Verificaciones
y Pruebas
Ayuda a la Administración
6
de la Configuración Prevención
Prevención
(Plan Calidad, procesos)
7 Facilita la Capacitación
Perfil de Costos sin QC Perfil de Costos con QC
28. Organización - QC en un Proyecto
Analistas Sponsor
Defectos Administración
Interfaces Casos de Prueba Proyecto
Líder
Desarrolladores
Proyecto
Analistas Testers Plan de Pruebas
Informe de Estado de Calidad
Proyección de Tiempos
Producto
Customs listo para QC
Probar
Desarrolladores QC Manager Producto
listo para
Aceptar
Líderes
Funcionales
Usuarios
Parametrización Usuarios
Funcionales Usuarios
Ambiente de Desarrollo Ambiente de QC Ambiente de Aceptación
29. Organización - Interacción entre Grupos
1 Plan de Pruebas
Informe de Estado de Calidad Líder de
9
Proyección de Tiempos Proyecto
Especificación Funcional
2
Especificación Técnica
Producto listo para aceptar
QC 10
Informe de entrega
Equipo de Desarrollo
Usuarios
Producto listo para probar
4
Informe de entrega
5 7 3
Defecto nuevo Defecto cerrado Condiciones de Prueba
o reabierto Casos de Prueba
Ciclos de Prueba
Base Datos
Base Datos
6 Defecto corregido Casos de
Defectos
Prueba
8 Indicadores
30. Organización – big picture
Proveedor Cliente
Desarrollo
Evidencia Defectos
Prueba Casos de Prueba
Líder
Proveedor Testers Testers Funcionales
Producto
Producto
Equipo listo para
Equipo aprobado
Homologación para
Desarrollo Homologar
Instalar en
Producción
Analistas Desarrolladores QC Manager Usuarios
Centro de Desarrollo
Sponsor
Plan de Prueba
Informe de Estado de Calidad
Proyección de Tiempos Administración
Ambiente de Desarrollo
Proyecto
Líder
Proyecto
Ambiente de
Ambiente de QC
Homologación
31. El mapa completo de nuestras actividades…
Alcance
Análisis y Modelado
Diseño y Desarrollo
Testing
Aceptación
Implementación y
Liberación
Verificación
Validación
• Revisión Requerimientos
• Revisión Diseño Funcional
• Revisión Diseño Técnico • Pruebas Unitarias (desarrollo)
• Revisión Código • Prueba Funcionales
• Pruebas de Usabilidad
• Pruebas de Integración
• Pruebas No Funcionales
• Defectos
(performance, etc) Testers
• Casos de Prueba
•Pruebas de Aceptación (usuario)
• Automatización
Herramientas
QC
• Plan de Pruebas
• Análisis de Evolución de la Prueba (comportamiento de defectos)
Manager
• Análisis de Cobertura de la Prueba (comportamiento de ciclos y casos de prueba)
• Comparación de métricas entre Proyectos
Planificación y Control de la Prueba
32. … y cómo organizamos nuestro trabajo…
Estrategias y Objetivos
Estrategia: Visión integrada de:
Técnicas requeridas para lograr el objetivo.
Logística y recursos materiales necesarios durante el proyecto.
Soporte y recursos humanos necesarios durante el proyecto.
En qué basarnos?
Información sobre los objetivos del testing para los distintos
interesados.
En qué influyen?
Gestión y políticas del proyecto.
Información a proveer a los distintos interesados.
33. Estrategia de prueba
Contexto del
Proyecto
• Diversificación
• Costos vs Valor
• Habilidades
• Experiencia
Pruebas
Criterios de Características
Calidad del Producto
Calidad
percibida
34. Seleccionar Técnicas de Testing adecuadas
Según los posibles objetivos y riesgos, criterios de
calidad y contexto, diferentes técnicas:
Testing funcional
Testing basado en especificaciones
Domain Testing
Risk Based Testing
Testing de escenarios
Testing de regresión
Testing de stress
Testing exploratorio
Testing de compatibilidad (por ej., de impresión)
Testing (automatizado) de volúmenes
Testing de usabilidad
Testing de accesibilidad
……..
35. Implementar Buenas Prácticas
Lograr consenso sobre:
Gestión de cambios al proyecto
Gestión de configuraciones
Necesidad de Ambientes y su administración
Builds frecuentes
Registración y seguimiento de defectos
Priorización de corrección / triage de defectos
Criterios de aceptación
Calidad necesaria / aceptable para el producto
Participación de usuarios / pruebas de aceptación
……..
36. Saber Informar
Qué y a quiénes
Calidad percibida
Niveles de reportes
Posibles acciones,
o cómo intentamos corregir el rumbo
Cuándo
Reuniones de avance internas (testing)
Reuniones de avance del equipo de proyecto
Reuniones con otros interesados / sponsor
Métricas
Qué “contar”: defectos, casos de prueba, cobertura…
Cómo interpretar los números
Uniformidad
38. Saber Informar – Ejemplo 2 - Defectos
Pocos Defectos
Muchos
Pendientes
Defectos
Pendientes
Permite
identificar
tendencias,
en qué
momento se
prevé
terminar con
la prueba o
con la
corrección
De lo pendiente, cuál es el
estado y su impacto.
44. Conclusiones
Tenemos que aportar valor: pronto, cuantificable,
previniendo problemas, dando feedback.
Tenemos que trabajar en equipo, ser confiables y eficientes
No somos “ciudadanos de segunda”
Tampoco somos los “guardianes” de la calidad
Necesitamos capacitarnos y ganar experiencia
Podemos mejorar nuestros procesos
(y ayudar a mejorar los demás procesos)
…Otras conclusiones?
