Expositor: Federico Toledo Resumen: Para que no te queden dudas de los beneficios del testing exploratorio, haremos una dinámica en la que todos lo pondremos en práctica para poder visualizar la estrategia completa y los beneficios y aplicabilidad que tiene. Lo más importante, nos divertiremos y así entenderemos cómo el testing exploratorio ayuda a romper el mito de que el testing es aburrido.

2. • Entender el concepto de testing
exploratorio y las particularidades.
• Ponerlo en práctica, desde su ejecución
hasta su gestión.
• Entender los beneficios.
• Imaginarse cómo planificar y analizar los
resultados obtenidos.

3. • Breve teórico.
• Práctico grupal.
• Discusión final.

4. • Clasificación de enfoques
– Ad-hoc
– Exploratorio
– Planificado

5. • Sin un plan, realizado en el momento sin
un objetivo en mente, sin un método
claro.
• Poco profesional. Cero control. Cero
seguimiento. Cero trazabilidad.
• No queremos hacerlo.

6. • Quiero visitar una ciudad nueva.

7. • Enfoque Planificado:
– Previo al viaje miro el mapa y una guía.
– Veo qué cosas interesantes pueden haber
para visitar.
– Los ordeno según lo que más me gusta.
– Veo cuánto tiempo tengo y planifico cuánto
tiempo voy a estar en cada lugar.

8. • Enfoque Exploratorio:
– Llevo el mapa y la Guía y los voy mirando en el
sitio.
– Ir preguntando qué visitar, en base a lo que
voy descubriendo voy definiendo qué otra cosa
quiero ver.
– Voy marcando en el mapa lo que voy visitando.
– Me defino el tiempo que tengo para recorrer, y
en base a eso me voy organizando para ver
todo lo que pueda llegar a encontrar.

9. • Ventajas Exploratorio:
– No tuve que planificar lo que quería ver.
– En el mismo lugar fui decidiendo qué ver y qué
no, y qué me gustaba más y qué no.
– Dejé registradas las cosas que visité.
• Ventajas Planificado:
– Puedo compartir el plan con otro.
– Puedo organizarme y prever cuánto voy a
necesitar, si me alcanzan los días previstos
para visitar todo lo que me gusta.

10. • Estrategia de testing exploratorio
– Definido como el diseño, ejecución y
aprendizaje de la aplicación de forma
simultánea, donde utilizamos lo aprendido
de experimentos anteriores en las
siguientes pruebas.
• Ideal para cuando:
– Tenemos poco tiempo.
– Conocemos poco el producto.

11. • Dos etapas bien definidas (al punto que lo
podrían hacer dos personas diferentes y
con skills distintos).
Diseño Ejecución
Planilla con casos
de prueba.
Planilla con resultados
de ejecución.

12. • Ejemplos
– Valores límites
– Particiones de equivalencia
– Tablas de decisión
– Árboles de decisión
– Casos de uso
– Máquinas de estado

13. “Es un estilo de testear software que
enfatiza, la libertad personal y
responsabilidad individual del tester, para
optimizar de manera continua el valor de
su trabajo, tratando al aprendizaje, diseño
y ejecución de pruebas, como actividades
que se apoyan mutuamente y corren en
paralelo a lo largo de un proyecto.”
–Cem Kaner

14. • Testing Exploratorio = Testing
• El nombre especial fue necesario por la
confusión que generó “Testing
automatizado”, el cual debería
llamarse “Checking automatizado”.
http://www.satisfice.com/blog/archives/category/testing-vs-checking

15. “Una sesión es una unidad básica de
trabajo de testing.
No es ni un caso de prueba, ni un reporte de
defectos.
Es un bloque ininterrumpido y revisable,
donde hay evidencias del trabajo en
nuestra misión de testing.”
–Jonathan Bach

16. • Se creó con el propósito de:
– Facilitar un registro sobre el progreso de los
testers.
– Proveer un medio para organizar y reportar
el cubrimiento del trabajo hecho.
– Deben ser ininterrumpidas.

17. • Cuando probamos “algo” durante cierto
tiempo, enfocados en “cierta
característica”.
• 1 o 2 horas.
• Buscando bugs en una feature nueva.
• Puede o no incluir:
– Checklists
– Casos de prueba
– Más …

18. 1. MISIÓN
2. INICIO
5. ARCHIVOS
DE DATOS
3. TESTER
4. DIVISIÓN
DE TAREAS
6. NOTAS DE
PRUEBAS
7. RIESGOS Y
DEFECTOS
8.
INCONVENIENTES

19. • Descubrir
– Conocer la nueva funcionalidad X
• Probar cierto aspecto
– ¿Cómo funciona en Chrome?
– Revisar lo qué sucede cuando el servicio X está caído
• Buscar cierto tipo de errores
– Revisar ortografía en el módulo X
– Revisar mensajes de error en X
– Considerar manejo de entradas inválidas en X
• Analizar un factor de calidad
– Revisar usabilidad de X
– Analizar accesibilidad de la aplicación Android
• Explorar las dimensiones del producto
– SFDPOT

20. • Heurística "San Francisco Depot"
– Structure (what the product is)
– Function (what the product does)
– Data (what it processes)
– Platform (what it depends upon)
– Operations (how it will be used)
• http://www.satisfice.com/articles/sfdpo.shtml

21. • Explorar el producto para analizar el
mapa de cobertura.
• Identificar los principales workflows.
• Revisar la performance del proceso
principal.
• Probar todos los data entry.
• ¿Hay forma de que el archivo se
corrompa y el sistema falle?

22. • “What we are testing or what problems
we are looking for.”
– Jon Bach
• Una misión puede ser cubierta por
varias sesiones.
• Tamplate de Mike Lyles:

23. • Mi misión es “probar los casos borde”
para “la funcionalidad XX del sitema
TAL”.
• Mi misión es “revisar la precisión de los
mensajes de error” para “el tipo de
errores XXXX”.
• Mi misión es “probar la vulnerabilidad a
SQL Injection” para “el login y las páginas
de administración”.

24. • Ejecutar una session
– http://opencart.abstracta.us/

25. • Timer
• Notas con estructura de sesión
– Papel
– Blog de notas
– Pizarra

28. • Las métricas son extraídas de:
– Cantidad de sesiones que se hayan
completado (cobertura).
– Cantidad de defectos y problemas que se
hayan encontrado.
– Porcentaje de tiempo invertido en:
• Armado de la sesión,
• Diseño y Ejecución de pruebas,
• Investigación y Reporte de defectos.
– Porcentaje de tiempo invertido en:
• Misión y oportunidad.

29. • Deberíamos analizar las métricas y
definir los siguientes pasos.
• La idea es que ciclo a ciclo se vaya
mejorando el testing.

30. Sesión Fecha Hora Dur. Mis. Op. Testing Def. Armado #Def. #Inc. #Testers
ET-
S01
Fecha Hora 1h 1h 0 0.8 0.1 0.1 1 3 1
ET-
S02
Fecha Hora 2h 1.5h 0.5h 0.7 0.2 0.1 5 1 2
ET-
S03
Fecha Hora 2h 2h 0h 0.5 0.4 0.1 8 0 1
ET-
S04
Fecha Hora 2h 1h 1h 0.9 0.1 0 1 0 1

31. Sesión Fecha Hora Dur. Mis. Op. Testing Def. Armado #Def. #Inc. #Testers
ET-
S01
Fecha Hora 1h 1h 0 0.8 0.1 0.1 1 3 1
ET-
S02
Fecha Hora 2h 1.5h 0.5h 0.7 0.2 0.1 5 1 2
ET-
S03
Fecha Hora 2h 2h 0h 0.5 0.4 0.1 8 0 1
ET-
S04
Fecha Hora 2h 1h 1h 0.9 0.1 0 1 0 1

32. Sesión Fecha Hora Dur. Mis. Op. Testing Def. Armado #Def. #Inc. #Testers
ET-
S01
Fecha Hora 1h 1h 0 0.8 0.1 0.1 1 3 1
ET-
S02
Fecha Hora 2h 1.5h 0.5h 0.7 0.2 0.1 5 1 2
ET-
S03
Fecha Hora 2h 2h 0h 0.5 0.4 0.1 8 0 1
ET-
S04
Fecha Hora 2h 1h 1h 0.9 0.1 0 1 0 1

34. • Facilita la planificación:
– Time slots bien definidos.
• Mejora al tester, su motivación y
habilidades.
• Facilita el análisis de cobertura.
• Mejora continua.

35. • De mucha utilidad para:
– Brindar feedback y resultados de forma
rápida.
– Adquirir nuevo conocimiento a lo largo de
una sprint, iteración o ciclo de testing.
– Revelar nuevos tipos de defectos e
inconvenientes.
– Mejorar las habilidades y conocimiento en
la lógica de negocio del tester.

36. • Técnicas del Enfoque de Pruebas
Planificadas:
– Valores límites
– Particiones de equivalencia
– Tablas de decisión
– Árboles de decisión
– Casos de uso
– Máquinas de estado
Todas
aplicables a
testing
exploratorio
Muchas veces
de manera
inconsciente

37. Casos de prueba
Exploratorio
1 hora
2 horas

38. “Es un estilo de testear software que
enfatiza, la libertad personal y
responsabilidad individual del tester,
para optimizar de manera continua el
valor de su trabajo,
tratando al aprendizaje, diseño y ejecución
de pruebas, como actividades que se apoyan
mutuamente y corren en paralelo a lo largo
de un proyecto.”

39. http://blog.abstracta.com.uy/