En los últimos meses he notado en varios colegas que se dedican al control de calidad  de software, su afán por tener todas las pruebas de regresión automatizadas,   con el fin de eliminar completamente las pruebas manuales; sin embargo ,tras 6 años de experiencia en dicha área, he logrado identificar que la ejecución de pruebas manuales es muy importante y trae muchos beneficios, todo depende del enfoque que se le dé.

En las pruebas exploratorias (Exploratory Testing), no se necesita una planificación tan detallada y es muy útil cuando las especificaciones de un proyecto no están claras. En el Exploratory Testing, la persona encargada de realizarlas explora el sistema utilizando el conocimiento que tiene sobre el funcionamiento, y explota sus  habilidades como agente de control de calidad.

Esta práctica se implementa  comúnmente en ambientes que trabajan bajo una metodología ágil, ya que, en períodos reducidos de tiempo, el equipo de control de calidad debe de ser capaz de proveer retroalimentación rápidamente. En un universo paralelo, los testers deberían de ser capaces de agregar pruebas automáticas en cuestión de minutos, sin embargo, en la realidad no es así. Agregar pruebas automáticas muchas veces puede llegar a ser costoso, dependiendo de la funcionalidad que se está automatizando y el equipo de QA no debería ser un cuello de botella para dar retroalimentación al equipo de desarrollo.

En un mundo ideal, cuando hablamos de las pruebas que se deben de realizar en un proyecto de software debemos observar que los proyectos tienen pruebas automáticas empezando desde pruebas unitarias, pruebas de integración, pruebas de punto a punto (también conocidas como E2E) y terminamos con un conjunto de pruebas exploratorias.

Imagen No. 1

Sin embargo, en el día a día, lo más común es encontrar todo lo contrario.  En muchos proyectos de software no se tienen pruebas unitarias o se tiene un conjunto muy pequeño, haciendo que tengamos muchas más pruebas de integración y pruebas de punto a punto, terminando con un conjunto muy grande de pruebas de regresión que se deben de ejecutar manualmente. A esto se le conoce como el ice-cream testing.

Imagen No. 2

Como mencioné al inicio, las pruebas manuales pueden ser  algo negativo o positivo en los proyectos dependiendo del enfoque que se le dé.  Si vemos en la imagen No. 2, lo que tenemos en la parte superior de la pirámide es un conjunto pruebas que se deben de ejecutar manualmente. Estas pruebas son pruebas de regresión, lo que quiere decir que son pruebas planificadas de funcionalidades del sistema ya existentes que no se tienen automatizadas en ese momento.

 Utilizando el enfoque de la imagen No. 1 podemos observar que también se van a realizar pruebas manuales. Sin embargo,utilizando la técnica de exploratory testing, el equipo no estará realizando únicamente pruebas de regresión sino que estará enfocado en explorar el sistema de una forma que contribuya a encontrar defectos que no se habían encontrado antes, proveer ideas de cómo mejorar la interfaz de usuario y también ir evolucionando el conjunto de pruebas tal cual lo dice uno de los 7 principios de testing, “The Pesticide Paradox“.

Cuando se quiere realizar exploratory testing debemos de tomar en cuenta lo siguiente:

    1. Identificar el propósito del producto.
    2. Identificar funciones básicas o más importantes del proyecto.
    3. Identificar cuáles son las áreas más inestables del proyecto.
    4. Probar cada una de estas funcionalidades y guardar los posibles errores.
    5. Verificar que los problemas son replicables.

Realizar exploratory testings traer muchas ventajas, siendo algunas de ellas:

    1. Toma menos tiempos su preparación.
    2. Los defectos más críticos son detectados rápidamente.
    3. Se encuentran nuevos defectos que luego se pueden priorizar dependiendo el nivel de criticidad de cada uno.
    4. En lo personal, cuando una nueva persona entra al equipo recomiendo que haga un exploratory testing del proyecto en el cual estará trabajando para que pueda familiarizarse con el mismo. 

Al igual que cualquier técnica para hacer testing, el exploratory testing tiene ciertas desventajas. Una de las principales y que a mi parecer es la más importante es:

    •  Los defectos son difíciles de replicar: 
      • Recomiendo que al momento de hacer exploratory testing se utilicen herramientas que nos ayuden a grabar los pasos que realizó la persona en la prueba para tener una forma de poder replicar fácilmente.

En conclusión, recomiendo no intentar eliminar por completo las pruebas manuales. Realizar pruebas automáticas para tener mayor cobertura y dar retroalimentación rápidamente a nuestro equipo de desarrollo es muy importante. Sin embargo, si utilizamos el enfoque apropiado para hacer pruebas manuales podemos llegar a tener un gran beneficio: al hacer pruebas manuales tenemos personas que razonan acerca de los escenarios que ven y prueban, mientras que las pruebas automáticas no razonan solo hacen verificaciones específicas.

Por último, recomiendo empezar a migrar poco a poco al Exploratory Testing (imagen no. 1).  Es recomendable hacer Exploratory Testing en cada sprint y en un tiempo de una a dos horas y también ir incrementando el conjunto de pruebas automáticas evaluando qué pruebas son recurrentes y cuales agregan más valores al tenerlas automatizadas.

¿Deseas aprender aún más sobre testing?

Probando API’s utilizando TestNG y Rest Assured

¡Inscríbete ahora!