TESTING EXPLORATORIO
Claudia Badell
AGENDA
INTRODUCCIÓN1
CONCEPTOS GENREALES DE TESTING
REPASO
2
TESTING EXPLORATORIO
TEÓRICO
3
TESTING EXPLORATORIO
EJERCICIO4
AGENDA
INTRODUCCIÓN1
CONCEPTOS GENREALES DE TESTING
REPASO
2
TESTING EXPLORATORIO
TEÓRICO
3
TESTING EXPLORATORIO
EJERCICIO4
TRABAJO COMO
• Senior Quality Engineer, Infragistics
ACERCA DE MÍ 
ESTUDIOS
• Ingeniera en Computación, UdelaR
• Cursos de la Association for Software Testing
(Foundations y Bug Advocacy)
• Scrum Master
• ISTQB Foundation
FORMO PARTE DE
• TestingUy (www.testing.uy)
TRABAJÉ COMO
• Docente, Instituto de Computación, Facultad
Ingeniería, UdelaR
• Test Manager, Timba Software Corporation
• Tester, Centro de Ensayos de Software
• Analista de Requerimientos, UTE
• Empresa americana de desarrollo de
software
• Oficinas en Estados Unidos, Bulgaria,
Japón, Inglaterra, India y Uruguay
• En Uruguay desde el 2008
• Somos 260 empleados en el mundo y
unas 40 personas en Uruguay
INFRAGISTICS
https://www.facebook.com/infragistics.uy
• Desarolladores (7), visual designers (1),
interaction designers (1), documentadores
técnicos (1) y testers (1)
EL EQUIPO
• Herramienta de prototipado de
aplicaciones
• Multiplataforma (Windows & Mac)
• En el mercado desde el 2012
• Tenemos 2 liberaciones grandes en el
año y también liberaciones intermedias
de funcionalidades medianas y
pequeñas
EL PRODUCTO
indigodesigned.comwww.infragistics.com/products/indigo-studio
• Definición de las estrategias de las pruebas
• Ejecución de pruebas manuales y automatizadas
• Colaboración en la priorización de bugs
• Implementación de mejoras en el workflow de los
bugs
• Evangelización de la disciplina del Testing en el
equipo
ROL DEL TESTER
EN EL EQUIPO
AGENDA
INTRODUCCIÓN1
CONCEPTOS GENREALES DE TESTING
REPASO
2
TESTING EXPLORATORIO
TEÓRICO
3
TESTING EXPLORATORIO
EJERCICIO4
¿POR QUÉ PROBAMOS?
BBST: Foundations course by the Association for Software Testing
Testing es la búsqueda de
información
Funcionales
No funcionales
SEGÚN QUÉ ASPECTO
QUEREMOS PROBAR
Caja Blanca
Caja Negra
SEGÚN EL
CONOCIMIENTO
DEL CÓDIGO
Caja Gris
Pruebas unitarias
Pruebas de
Integración
Pruebas de sistema
Pruebas de
aceptación
SEGÚN A QUÉ NIVEL
DE LA SOLUCIÓN
PROBAMOS
DIMENSIONES
Las pruebas pueden ejecutarse en
forma manual y/o automatizada
Funcionales
No funcionales
SEGÚN QUÉ ASPECTO
QUEREMOS PROBAR
Caja Blanca
Caja Negra
SEGÚN EL
CONOCIMIENTO
DEL CÓDIGO
Caja Gris
Pruebas unitarias
Pruebas de
Integración
Pruebas de sistema
Pruebas de
aceptación
SEGÚN A QUÉ NIVEL
DE LA SOLUCIÓN
PROBAMOS
DIMENSIONES
• Partición de equivalencia
• Valores límite
• Tablas y árboles de decisión
• Máquinas de estado
• Casos de pruebas a partir de casos de uso
TÉCNICAS DE
DISEÑO DE CASOS DE PRUEBAS
AGENDA
INTRODUCCIÓN1
CONCEPTOS GENREALES DE TESTING
REPASO
2
TESTING EXPLORATORIO
TEÓRICO
3
TESTING EXPLORATORIO
EJERCICIO4
• Se basa en las técnicas de diseño de
casos de pruebas
• El diseño de los casos de pruebas y la
ejecución de los mismos son
actividades separadas en el tiempo
• Cada actividad puede realizarla una
persona diferente
DISEÑO PLANIFICADO
• Las actividades de diseño y de
ejecución se realizan en forma
simultánea
TESTING EXPLORATORIO
• obtener resultados rápidamente
• detectar defectos en lugares que no
esperábamos encontrarlos
• aprender del producto
ESTRATEGIA ÚTIL PARA
Y además… es divertida de aplicar 
James Bach
El testing exploratorio es un proceso
simultáneo de exploración del
producto (aprendizaje), diseño y
ejecución de pruebas.
Cem Kaner
Es un estilo de probar software que enfatiza la
libertad personal y responsablidad 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 mutamente y se
ejecutan en paralelo a lo largo de un proyecto.
Testing exploratorio no es
probar en forma ad-hoc
TESTING EXPLORATORIO
Buenos exploradores son
generalmente los testers con
más experiencia
HABILIDADES DEL TESTER
CURIOSO
PENSAMIENTO
OUT OF THE BOX
OBSERVADOR
PENSAMIENTO
CRÍTICO
PRAGMÁTICO MANEJAR
EL TIEMPO
PRIORIZAR
PENSAMIENTO
ANALÍTICO Y LÓGICO
CREATIVO
• Conocimiento de heurísticas, técnicas de diseño de casos de prueba
• Histórico de bugs
• Conocimiento del dominio bajo prueba
• …
¿CÓMO DEFINIMOS
LOS CAMINOS A RECORRER?
Las heurísticas nos proveen una
dirección, guía y enfoque para
resolver un problema
• Fáciles de aplicar
• Ayudan a identificar inconsistencias
PROS:
• Pueden ser muy generales
• No garantizan una solución
• Dos heurísticas pueden contradecirse
CONTRAS:
HEURÍSTICAS DE TESTING
CEM KANER
Consistencia con:
• el producto
• la historia
• productos similares
• la imagen
• las regulaciones
• su propósito
http://testingeducation.org/BBST/foundations/
TESTING EXPLORATORIO
BASADO EN SESIONES
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
SESIÓN
Describe qué se probará del producto/funcionalidad
MISIÓN
Facebook
Funcionalidad bajo prueba: ”Like”
¿Qué misiones podríamos definir?
EJEMPLO
CONTENIDO DE UNA SESIÓN
ANÁLISIS DE TAREAS
• Tester/s
• Fecha y hora de
comienzo
• Tiempo
• Duración
• TBS
• Misión vs
Oportunidad
REGISTRO
• Archivos de datos
• Notas sobre los
pasos seguidos
MISIÓN
• Identificador o texto
de misión
• Áreas de cobertura
BUGS/ISSUES
• Identificador
Incidentes
encontrados
• Observaciones
Propuesta por Jonathan Bach
¿DÓNDE REGISTRO LAS SESIONES?
• Papel 
• Planillas. Ejemplo: Excel, Hoja de cálculo Goolge, etc.
• Bach Scan Tool (www.satisfice.com/sbtm)
• Mindmaps. Ejemplo: XMind
• …
Qué información registrar en
una sesión va a depender de
qué queramos trazar, medir,
reutilizar, etc.
ALGUNAS MÉTRICAS
• Cantidad de sesiones culminadas
• Cantidad de sesiones por misión
• Cantidad de bugs encontrados por sesión y misión
• Esfuerzo en tiempo por misión/funcionalidad/producto
• Se basa en las técnicas de diseño de
casos de pruebas
• El diseño de los casos de pruebas y la
ejecución de los mismos son
actividades separadas en el tiempo
• Cada actividad puede realizarla una
persona diferente
DISEÑO PLANIFICADO
• Las actividades de diseño y de
ejecución se realizan en forma
simultánea
TESTING EXPLORATORIO
DISEÑO PLANIFICADO
Y TESTING EXPLORATORIO
• Se complementan
• Nos permiten mitigar riesgos
Es necesario aplicar diferentes
estrategias de pruebas para
modelar y probar la
funcionalidad bajo prueba
AGENDA
INTRODUCCIÓN1
CONCEPTOS GENREALES DE TESTING
REPASO
2
TESTING EXPLORATORIO
TEÓRICO
3
TESTING EXPLORATORIO
EJERCICIO4
EJERCICIOS
DEFINICIÓN DE MISIONES
DEFINICIÓN DE ÁREAS DE COBERTURAEJ.2
EJECUCIÓN DE SESIONES
EJ.4 GENERACIÓN REPORTE EN BACH SCAN TOOL
EJ.1
EJ.3
Puesta a punto
MUCHAS GRACIAS
¿Preguntas?
www.infragistics.com
CONTACTO:
Claudia Badell
cbadell@infragistics.com
@claubs_uy

Taller en Fundación Forge: Testing Exploratorio

  • 1.
  • 2.
    AGENDA INTRODUCCIÓN1 CONCEPTOS GENREALES DETESTING REPASO 2 TESTING EXPLORATORIO TEÓRICO 3 TESTING EXPLORATORIO EJERCICIO4
  • 3.
    AGENDA INTRODUCCIÓN1 CONCEPTOS GENREALES DETESTING REPASO 2 TESTING EXPLORATORIO TEÓRICO 3 TESTING EXPLORATORIO EJERCICIO4
  • 4.
    TRABAJO COMO • SeniorQuality Engineer, Infragistics ACERCA DE MÍ  ESTUDIOS • Ingeniera en Computación, UdelaR • Cursos de la Association for Software Testing (Foundations y Bug Advocacy) • Scrum Master • ISTQB Foundation FORMO PARTE DE • TestingUy (www.testing.uy) TRABAJÉ COMO • Docente, Instituto de Computación, Facultad Ingeniería, UdelaR • Test Manager, Timba Software Corporation • Tester, Centro de Ensayos de Software • Analista de Requerimientos, UTE
  • 5.
    • Empresa americanade desarrollo de software • Oficinas en Estados Unidos, Bulgaria, Japón, Inglaterra, India y Uruguay • En Uruguay desde el 2008 • Somos 260 empleados en el mundo y unas 40 personas en Uruguay INFRAGISTICS https://www.facebook.com/infragistics.uy
  • 6.
    • Desarolladores (7),visual designers (1), interaction designers (1), documentadores técnicos (1) y testers (1) EL EQUIPO
  • 7.
    • Herramienta deprototipado de aplicaciones • Multiplataforma (Windows & Mac) • En el mercado desde el 2012 • Tenemos 2 liberaciones grandes en el año y también liberaciones intermedias de funcionalidades medianas y pequeñas EL PRODUCTO indigodesigned.comwww.infragistics.com/products/indigo-studio
  • 8.
    • Definición delas estrategias de las pruebas • Ejecución de pruebas manuales y automatizadas • Colaboración en la priorización de bugs • Implementación de mejoras en el workflow de los bugs • Evangelización de la disciplina del Testing en el equipo ROL DEL TESTER EN EL EQUIPO
  • 9.
    AGENDA INTRODUCCIÓN1 CONCEPTOS GENREALES DETESTING REPASO 2 TESTING EXPLORATORIO TEÓRICO 3 TESTING EXPLORATORIO EJERCICIO4
  • 10.
  • 11.
    BBST: Foundations courseby the Association for Software Testing Testing es la búsqueda de información
  • 12.
    Funcionales No funcionales SEGÚN QUÉASPECTO QUEREMOS PROBAR Caja Blanca Caja Negra SEGÚN EL CONOCIMIENTO DEL CÓDIGO Caja Gris Pruebas unitarias Pruebas de Integración Pruebas de sistema Pruebas de aceptación SEGÚN A QUÉ NIVEL DE LA SOLUCIÓN PROBAMOS DIMENSIONES
  • 13.
    Las pruebas puedenejecutarse en forma manual y/o automatizada
  • 14.
    Funcionales No funcionales SEGÚN QUÉASPECTO QUEREMOS PROBAR Caja Blanca Caja Negra SEGÚN EL CONOCIMIENTO DEL CÓDIGO Caja Gris Pruebas unitarias Pruebas de Integración Pruebas de sistema Pruebas de aceptación SEGÚN A QUÉ NIVEL DE LA SOLUCIÓN PROBAMOS DIMENSIONES
  • 15.
    • Partición deequivalencia • Valores límite • Tablas y árboles de decisión • Máquinas de estado • Casos de pruebas a partir de casos de uso TÉCNICAS DE DISEÑO DE CASOS DE PRUEBAS
  • 16.
    AGENDA INTRODUCCIÓN1 CONCEPTOS GENREALES DETESTING REPASO 2 TESTING EXPLORATORIO TEÓRICO 3 TESTING EXPLORATORIO EJERCICIO4
  • 17.
    • Se basaen las técnicas de diseño de casos de pruebas • El diseño de los casos de pruebas y la ejecución de los mismos son actividades separadas en el tiempo • Cada actividad puede realizarla una persona diferente DISEÑO PLANIFICADO • Las actividades de diseño y de ejecución se realizan en forma simultánea TESTING EXPLORATORIO
  • 18.
    • obtener resultadosrápidamente • detectar defectos en lugares que no esperábamos encontrarlos • aprender del producto ESTRATEGIA ÚTIL PARA Y además… es divertida de aplicar 
  • 19.
    James Bach El testingexploratorio es un proceso simultáneo de exploración del producto (aprendizaje), diseño y ejecución de pruebas.
  • 20.
    Cem Kaner Es unestilo de probar software que enfatiza la libertad personal y responsablidad 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 mutamente y se ejecutan en paralelo a lo largo de un proyecto.
  • 21.
    Testing exploratorio noes probar en forma ad-hoc
  • 22.
  • 23.
    Buenos exploradores son generalmentelos testers con más experiencia
  • 24.
    HABILIDADES DEL TESTER CURIOSO PENSAMIENTO OUTOF THE BOX OBSERVADOR PENSAMIENTO CRÍTICO PRAGMÁTICO MANEJAR EL TIEMPO PRIORIZAR PENSAMIENTO ANALÍTICO Y LÓGICO CREATIVO
  • 25.
    • Conocimiento deheurísticas, técnicas de diseño de casos de prueba • Histórico de bugs • Conocimiento del dominio bajo prueba • … ¿CÓMO DEFINIMOS LOS CAMINOS A RECORRER?
  • 26.
    Las heurísticas nosproveen una dirección, guía y enfoque para resolver un problema
  • 27.
    • Fáciles deaplicar • Ayudan a identificar inconsistencias PROS: • Pueden ser muy generales • No garantizan una solución • Dos heurísticas pueden contradecirse CONTRAS:
  • 28.
    HEURÍSTICAS DE TESTING CEMKANER Consistencia con: • el producto • la historia • productos similares • la imagen • las regulaciones • su propósito http://testingeducation.org/BBST/foundations/
  • 29.
  • 30.
    Es una unidadbá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 SESIÓN
  • 31.
    Describe qué seprobará del producto/funcionalidad MISIÓN
  • 32.
    Facebook Funcionalidad bajo prueba:”Like” ¿Qué misiones podríamos definir? EJEMPLO
  • 33.
    CONTENIDO DE UNASESIÓN ANÁLISIS DE TAREAS • Tester/s • Fecha y hora de comienzo • Tiempo • Duración • TBS • Misión vs Oportunidad REGISTRO • Archivos de datos • Notas sobre los pasos seguidos MISIÓN • Identificador o texto de misión • Áreas de cobertura BUGS/ISSUES • Identificador Incidentes encontrados • Observaciones Propuesta por Jonathan Bach
  • 34.
    ¿DÓNDE REGISTRO LASSESIONES? • Papel  • Planillas. Ejemplo: Excel, Hoja de cálculo Goolge, etc. • Bach Scan Tool (www.satisfice.com/sbtm) • Mindmaps. Ejemplo: XMind • …
  • 35.
    Qué información registraren una sesión va a depender de qué queramos trazar, medir, reutilizar, etc.
  • 36.
    ALGUNAS MÉTRICAS • Cantidadde sesiones culminadas • Cantidad de sesiones por misión • Cantidad de bugs encontrados por sesión y misión • Esfuerzo en tiempo por misión/funcionalidad/producto
  • 37.
    • Se basaen las técnicas de diseño de casos de pruebas • El diseño de los casos de pruebas y la ejecución de los mismos son actividades separadas en el tiempo • Cada actividad puede realizarla una persona diferente DISEÑO PLANIFICADO • Las actividades de diseño y de ejecución se realizan en forma simultánea TESTING EXPLORATORIO
  • 38.
    DISEÑO PLANIFICADO Y TESTINGEXPLORATORIO • Se complementan • Nos permiten mitigar riesgos
  • 39.
    Es necesario aplicardiferentes estrategias de pruebas para modelar y probar la funcionalidad bajo prueba
  • 40.
    AGENDA INTRODUCCIÓN1 CONCEPTOS GENREALES DETESTING REPASO 2 TESTING EXPLORATORIO TEÓRICO 3 TESTING EXPLORATORIO EJERCICIO4
  • 41.
    EJERCICIOS DEFINICIÓN DE MISIONES DEFINICIÓNDE ÁREAS DE COBERTURAEJ.2 EJECUCIÓN DE SESIONES EJ.4 GENERACIÓN REPORTE EN BACH SCAN TOOL EJ.1 EJ.3
  • 42.
  • 43.