RMyA - workshop testing - v1.1
-
Upload
pilar-barrio -
Category
Technology
-
view
1.076 -
download
1
Transcript of RMyA - workshop testing - v1.1
Workshop
Testing
“fuera de la caja”
Versión 2010
Testing – Por qué “fuera de la caja”?
Pensemos sin prejuicios o ataduras
Salgamos (los testers) de nuestra cajita
Agenda
Introducción – Primeras ideas
Definamos en nuestros términos
Prueba
Tester
RiesgoRequerimiento
Testing
Calidad
Defecto
Proceso
Introducción – Scrat, la ardilla
Probemos a Scrat
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
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 -
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
… …
Conceptos básicos –
Quiénes son los INTERESADOS
Líder de Proyecto
Análisis Desarrollo Testing Tecnología Seguridad Operaciones
Sponsor Usuario Auditor
Cliente Cliente /
Usuario
Líder de Producto
Conceptos básicos – El contexto del producto
Características del producto
Criterios de Calidad
Características del proyecto
… un poco de humor…
“Nuestra meta es escribir software
libre de defectos.
Les pagaré un bono de 10 dólares por
cada defecto que encuentren y
corrijan.”
“Viva! Sí, Sí! Somos ricos!!!”
Dilbert – 1995
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”)
BUGs ??? ….
Un caso real1) Home Banking, busco movimientos entre fechas, presenta por defecto:
2) Cambio a 01/09/2009, convierte a:
4) Invirtiendo una fecha, funciona …
pero asume orden mes día:
3) Al dar aceptar:
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
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
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
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 ……..
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?
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
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?
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 ?
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?
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?
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?
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
…………
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
Cómo aportamos valor?
Reducción del Costo Total
Mejor Calidad - Mejor Imagen
Facilita el Control de Proyectos
Facilita la Integración
Ayuda a la Aplicación del Proceso
Ayuda a la Administración de la Configuración
Facilita la Capacitación
Prevención(Plan Calidad, procesos)
Verificaciones
y Pruebas
Fallas en
Aceptación
Fallas en
Producción
Prevención
Verificaciones
y Pruebas
Fallas Aceptación
Fallas Producción
Ahorro
Perfil de Costos sin QC Perfil de Costos con QC
1
2
3
4
5
6
7
Organización - QC en un Proyecto
Testers
QC Manager
Analistas
Desarrolladores
Interfaces
Analistas
Desarrolladores
Customs
Funcionales
Funcionales
Parametrización
QC
Sponsor
Líder Proyecto
Administración
Proyecto
LíderesUsuarios
Usuarios
Usuarios
Plan de Pruebas
Informe de Estado de Calidad
Proyección de Tiempos
Producto
listo para
Aceptar
Producto
listo para
Probar
DefectosCasos de Prueba
Ambiente de QC Ambiente de AceptaciónAmbiente de Desarrollo
Organización - Interacción entre GruposPlan de Pruebas
Condiciones de Prueba
Casos de Prueba
Ciclos de Prueba
1
Informe de Estado de Calidad
Proyección de Tiempos
Especificación Funcional
Especificación Técnica2
9
3
Defecto cerrado
o reabierto
7
Producto listo para probar
Informe de entrega4
Defecto corregido6
Defecto nuevo
5
Producto listo para aceptar
Informe de entrega10
Usuarios
Líder de
Proyecto
Base Datos Casos de Prueba
Base Datos Defectos
QC
Eq
uip
o d
e D
esarr
oll
o
Indicadores8
Organización – big picture
Testers
QC ManagerAnalistas Desarrolladores
Equipo
Homologación
Sponsor
Líder Proyecto
Administración
Proyecto
Funcionales
Usuarios
Producto
aprobado
para
Instalar en
Producción
Producto
listo para
Homologar
DefectosCasos de Prueba
Ambiente de QCAmbiente de
Homologación
Ambiente de Desarrollo
Testers
Proveedor
DesarrolloCliente
Evidencia
Prueba
Plan de Prueba
Informe de Estado de Calidad
Proyección de Tiempos
Líder Proveedor
Equipo
Desarrollo
Centro de Desarrollo
Planificación y Control de la Prueba
Verificación
Validación
Herramientas
El mapa completo de nuestras actividades…
• Revisión Requerimientos
• Revisión Diseño Funcional
• Revisión Diseño Técnico
• Revisión Código
• Pruebas Unitarias (desarrollo)
• Prueba Funcionales
• Pruebas de Usabilidad
• Pruebas de Integración
• Pruebas No Funcionales
(performance, etc)
•Pruebas de Aceptación (usuario)
• Defectos
• Casos de Prueba
• Automatización
• Plan de Pruebas
• Análisis de Evolución de la Prueba (comportamiento de defectos)
• Análisis de Cobertura de la Prueba (comportamiento de ciclos y casos de prueba)
• Comparación de métricas entre Proyectos
Testing
Aceptación
Diseño y Desarrollo
Análisis y Modelado
Alcance
Implementación y Liberación
Testers
QC Manager
… 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.
Estrategia de prueba
Contexto del
Proyecto
Características
del Producto
Criterios de
Calidad
Pruebas
Calidad
percibida
• Diversificación
• Costos vs Valor
• Habilidades
• Experiencia
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
……..
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
……..
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étricasQué “contar”: defectos, casos de prueba, cobertura…
Cómo interpretar los números
Uniformidad
Saber Informar – Ejemplo 1 - Defectos
Paquete
Implementación
Saber Informar – Ejemplo 2 - Defectos
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.
Pocos Defectos
PendientesMuchos
Defectos
Pendientes
Saber Informar – Ejemplo 3 –
Cobertura de la Prueba
Saber Informar – Ejemplo 4 –
Funcionalidad Completa
Saber Informar – Ejemplo 5 –
Funcionalidad Completa
Paquete
Implementación
Saber Informar – Ejemplo 6 –
Nivel de Calidad
Saber Informar – Ejemplo 7 –
Avance
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?
Preguntas… Opiniones…
¿?
FIN
Muchas gracias
www.rmya.com.ar
http://excelza.blogspot.com/