Testing Exploratorio Vs. Diseño de Casos de Pruebas?

La principal diferencia no radica en si eres un “Testing tradicional” o un “Testing Agile”, sino en el enfoque del proceso de testing que facilita el aporte de valor al proceso de desarrollo. Ese enfoque es el testing exploratorio, que se basa principalmente en algunos aspectos que son claves para el proyecto, como la velocidad de respuesta y la generación de pruebas de valor.

Velocidad de Respuesta

El primer criterio (velocidad de respuesta) tiene que ver con la prontitud de la ejecución de pruebas para detectar fallos de criticidad, para ello el equipo debe congeniar un muy alto grado de sincronizmo y apertura a la colaboración.

Quiero decir que no debemos trazar líneas divisorias que impidan que algo se pruebe lo antes posible (considerar Fail Fast). Esto a su vez facilita un aprendizaje acelerado y continuo a cerca de las features que se desarrollan, como también la detección temprana de oportunidades de cambio.

Otro valor agregado es que como testers nos volvemos especialistas en el producto y podemos servir mejor a múltipleas áreas, no solo a los developers del equipo.

La imagen de dumies en un automovil prototipo representa la posibilidad real de probar algo sin que esté finalizado.

Pruebas de Valor

La segunda característica (pruebas de valor) radica en la inteligencia puesta en testing, lo cual deja de ser una potestad de los “probadores”, sino que por la falta de líneas divisorias que mencioné antes, todos, inclusive clientes, son responsables y partícipes de esa inteligencia aplicada a las pruebas.

Esto es un buen fundamento que explica por qué NO nos dedicamos al diseño de casos de pruebas al principio, aún cuando fuera posible, sino al diseño de sesiones exploratorias, las cuales no las puedes diseñar con solo tener un documento requerimiento frívolo o solo historias de usuarios, únicamente es posible si interactúas con todo el team para detectar escenarios de criticidad.

No olvidemos que las pruebas exploratorias, no son un procedimiento sino un enfoque y nunca deberíamos poner en riesgo el primer criterio que mencioné (velocidad de respuesta).

Consideremos un par de detalles para justificar la no cración de casos de pruebas y si el diseño de sesiones exploratorias:
Crear un set de pruebas de sistemas al inicio nos resta la posibilidad de interactuar con los productos en sus fases mas temprana, por ende nuestro aporte es menor a cada día que se avanza sobre el desarrollo. Dicho en otro términos, mientras escribo no pruebo.

Quiere decir esto que nunca más escribiremos casos de pruebas funcionales?

La verdad es que la respuesta tiende cada vez más a NO, NO LO HAGAS!.

Cada vez que sea posible busquemos la forma de automatizar el proceso de pruebas funcionales y cada vez que no sea posible automatizar, escribamos pruebas funcionales por que en algún momento a lo largo de nuestro proyecto, normalmente antes de un release, deberíamos considerar correr pruebas regresivas desde el punto de vista del cliente (Aquí es a donde le pido cordura a los desarrolladores que sostienen que las pruebas de regresión bajo CI son suficientes y deberían bastar).

El asunto importante es que no releguemos nunca la posibilida de hacer pruebas funcionales de regresión antes de un release y para hacerlo, te lo aseguro, las sesiones exploratorias podrían no servirnos y si serían útiles casos de pruebas que hayamos diseñado (escritos o automatizados).

La imagen del dumie en un automovil finalizado representa la necesidad de probar tambien en este momento. Pero ojo! lo absurdo seria que este fuera nuestro único momento.

Y cuando diseñamos casos de pruebas?

Sugiero que deben surgir luego de haber corrido cada sesión exploratoria, es decir son la salida del proceso exploratorio y son alimentadas por la inteligencia puesta en el diseño previo de esas sesiones. Nuevamente, utilicemos la inteligencia para comprender que solo debemos escribir casos de pruebas significantes para conseguir dos cosas fundamentales, verificar con caminos normal que las funciones funcionan (valga la redundancia) en su ejecución normal y verificar que las funciones funcionan (valga la redundancia) cuando la ejecución es “fuera de lo normal”.

3 thoughts on “Testing Exploratorio Vs. Diseño de Casos de Pruebas?

  1. Muy bueno el artículo, y me generó una consulta: ¿Cómo te manejas frente a proyectos en donde te exigen (a) una estimación del esfuerzo de prueba y (b) una matríz de cobertura de pruebas?

    De más esta decir, que estaré difundiendo este post en el grupo de discusión TESTING & QA y en el blog, haciendo referencia de esta dirección, como para ver si hay feed back por parte de sus miembros.

    Un abrazo

  2. Mi respuesta y la consulta que hiciste, quizás quedan al margen de lo estrictamente Agile, pero por la experiencia que ambos tenemos, sabemos que es muy posible que los requisitos de cobertura y estimación de esfuerzos de testing sean requeridos aunque estuvieramos bajo metodologías Agiles.
    Si el proyecto es exigente con esos dos aspectos primero, ten en cuenta que en Agile, al menos en Scrum, no se prohiben las estimaciones relacionadas a cualquier esfuerzo que en el proyecto se deba hacer, esto implica que podemos estimar tranquilamente el esfuerzo de testing por separado. No es lo ideal, no lo aconsejo y los más puristas me odiarán, pero si no queda otra, mejor hacer una WBS de los work items del testing y estimarlos.
    Con respecto a la matríz de cobertura, creo que en este caso no podrás evitar el diseño de casos de pruebas y la generación de una matríz de rastreabilidad para enlazar todos los items de trabajo requeridos por el esfuerzo de testing y en base a eso determinar cobertura del testing.
    En ambos casos hemos introducido prácticas que no son estándares en Agile pero que dada la naturaleza no restrictiva de Scrum, pueden ser llevadas a cabo en alguna medida.

  3. Pingback: Testing Exploratorio Vs. Diseño de Casos de Pruebas? | TestingBaires

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s