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/

pbarrio@rmya.com.ar