Probar lo puede hacer cualquiera… o no?

 No es extraño encontrar personas que se refieren al “testing” con frases como:

"Probar es ejecutar unas pruebas para ver que la aplicación funciona y cubre los requisitos especificados."

No se paran a pensar de donde salen esas pruebas, que es lo que contienen, como se realizan, y por supuesto no se les ha ocurrido que el cubrir los requisitos puede no ser suficiente y que no asegura un correcto funcionamiento de la aplicación.

A diferencia del resto de actividades, la ejecución es la única actividad de testing que no se puede realizar en paralelo con el desarrollo (dejando a un lado las metodologías agiles), por lo que impacta en los tiempos del proyecto y tiene que estar planificada y tenida en cuenta en el llamado "camino crítico".

Esto hace que la gente no involucrada en las pruebas asocie “pruebas” con “ejecución”.

Como muy bien señala Jeff Fry en su artículo “Testing != test execution”, testing no es solo ejecutar.

Testing se puede descomponer a groso modo en las siguientes actividades:

1.     Crear un modelo mental de la aplicación a probar para entenderla, modelo que debe incluir el valor que pretende aportar y riesgos que pueden amenazar ese valor pretendido.

2.     Diseñar buenos casos de prueba, cuyo objetivo es contestar a las preguntas surgidas tras analizar el modelo de la aplicación.

3.     Ejecutar las pruebas, actividad en la que se cuestionará a la aplicación con todas esas preguntas surgidas anteriormente obteniéndose entonces respuestas.

4.     Evaluar las respuestas obtenidas. De esta forma se valorará si el comportamiento es el adecuado o no. Entonces podremos determinar si hay un problema y como de grave es.

5.     Reporte de los resultados,  donde se ofrecerá información clara y concisa de cada “bug” o defecto detectado con la intención de que sea corregido.

Una persona que se limita a observar la ejecución de las pruebas, sobre todo en “scripted testing approach”, puede caer en el error de pensar que las pruebas son fáciles y que no se requiere ninguna capacidad especial, con saber leer es suficiente.

La ejecución es el punto culminante (sin olvidar el reporte de defectos) de las pruebas. Pero para que esta ejecución tenga algún valor, los casos de prueba deben haber sido bien diseñados.

En el diseño además de tener en cuenta factores que faciliten el trabajo en la ejecución  (contenido detallado y entendible, bien estructurado, datos bien definidos, casos lógicamente ordenados dando dinamismo a la ejecución, etc), además tienen que haber sido creados con una intención muy especifica. Para poder diseñar casos así, hay que tener una idea mental de la aplicación que nos permita tener claros todos los aspectos importantes de la misma. Este es el momento crucial; para realizar este “mind map”, hay que utilizar una serie de cualidades que hacen del buen testing algo “no tan fácil”.

Si se entiende bien la aplicación, sus valores, sus riesgos… entonces estaremos en posición de presentar una estrategia adecuada, que ayude a diseñar unos casos de prueba óptimos para detectar el  mayor número de defectos posibles en el momento de su ejecución.

Señalar también que en el “scripted testing” podemos encontrar que la fase de ejecución la lleven a cabo testers con menor experiencia, ya que en teoría, los casos de prueba han sido diseñados y revisados por testers más experimentados. En este caso se puede “aceptar” el tópico de que la ejecución la pueda hacer "cualquiera".

Ahora bien, en el otro extremo, en el caso de “exploratory testing”, donde como indica James Bach “se diseña y ejecuta al mismo tiempo”, encontramos que para que las pruebas sean efectivas, el tester debe ser muy bueno y que las cualidades que se le podría exigir al planificador, al diseñador y al ejecutor de las pruebas, se den en una sola persona.

Aquí listo una pequeña selección de cualidades que de manera más extensa presentó el Dr. Cem Kaner en su artículo “RECRUITING SOFTWARE TESTERS:

·         Atención a los detalles

·         Capacidad analítica

·         Capacidad para solucionar problemas

·         Comprometido con las personas

·         Comprometido con las tareas

·         Comprometido con la calidad

·         Creativo

·         Valiente

·         Capacidad de adaptación

·         Empático

·         Capacidad de realizar experimentos y utilizarlos

·         Creíble

·         Decidido

·         Diplomático

·         Centrado en el usuario final

·         Enérgico

·         Rápida abstracción

·         Intuición para encontrar bugs

·         Flexible

·         Humilde

·         Percepción interpersonal

·         Lector e investigador

·         Persuasivo

·         Gran capacidad de Comunicación verbal y escrita

·         Etc…

Como veis, hay unas cuantas cosas…