Casuística Candidata para Automatizar Pruebas

Nota del autor: El contenido de este artículo fue extraído de partes de comentarios dejados por los miembros del grupo TESTING & QA en LinkedIn, a partir de debates generados.

Hay dos enfoques a tener en cuenta en relación con el área de software testing que se hará cargo de la selección de casos de prueba candidatos:

1. Aquella que no ha iniciado aún proyectos para automatizar sus pruebas.
2. Aquella que ha puesto en marcha proyectos de automatización y se encuentra con la intención de transitar el camino de la mejora continua.

Entiéndase por esto, a qué tan madura se encuentra el área para encarar la tarea de seleccionar la casuística candidata (es decir, los casos de prueba candidatos) para automatizar.

Para las áreas del tipo (a) se les abre todo un abanico de posibilidades que deben conocer (o deberían conocer) de antemano cómo tratarlas, más que por la relación costo-beneficio. Entre ellas:

• Identificar y reconocer los casos de prueba candidatos a partir de ciertos criterios definidos.
• Registrarlos en una herramienta para su posterior seguimiento, control y actualización.
• Gestionar la ejecución de los scripts generados, sobre la base de los escenarios candidatos seleccionados, o integrarlos con otra herramienta que los ejecute, al margen de tener muy bien planificado el proyecto en sí mismo.

Para las áreas del tipo (b) se les abre otro abanico de posibilidades porque deben reconocer de los procesos que se encuentren automatizados, aquellos escenarios de prueba que por su característica y/o resultado, deben comenzar a “separarse” como mejores candidatos para ir mejorando la performance de las corridas, de manera progresiva. A continuación enumero algunos factores que deberían considerarse a la hora de seleccionar candidatos para automatizar, dependiendo del tipo de escenario que se tenga que someter a prueba.

1. Herramienta de Automatización: la herramienta debe poder soportar la o las tecnologías sobre la que está construida la aplicación.
2. Disponibilidad de tiempo para las pruebas: el automatizar desde cero nos puede costar hacer el script hasta el doble de tiempo de las pruebas manuales.
3. Frecuencia de uso de la aplicación: Se valora si se usará constantemente, si se usará esporádicamente, o solo se usará una vez, esto para saber si conviene o no, dedicarle el tiempo para automatizar.
4. Complejidad de la aplicación: dependiendo de ésta habrá que evaluar si probar ciertos casos candidatos, ya que el esfuerzo inicial es elevado.
5. Estabilidad y variabilidad de la versión: Si se cuenta con una versión estable de cambios, es candidata a ser automatizada, sin dejar de considerar su variabilidad.
6. 100% automatización: dependerá de cuánta intervención humana tenga el escenario a probar.
7. Flujo principal: Identificar/Reconocer/Evaluar aquellos escenarios que se hayan definido como principales y sus respectivas condiciones de prioridad (críticas, importantes, urgentes) que se alinean a las reglas de negocio principales.
8. Evitar automatizar todo: es el error más común intentar automatizar todos los casos de prueba, ya que los scripts de automatización deberían ser un apoyo a las pruebas manuales y no el reemplazo de ellas.
9. Evaluar combinación 3 y 7: Aquellos casos de prueba vinculados con el core de la aplicación y que se pueden construir al principio del proyecto, para luego utilizarlos (adaptación mediante) en el resto del desarrollo y vida del software.
10. Costo de la automatización asociado al caso de prueba: evaluar su complejidad para decidir si se continúa con el proceso de automatizar o bien, se lo deja para ejecutarlo manualmente.
11. Proyecto de antenimiento: identificar historial de incidentes como fuente de información.
12. Pensar en el público: ¿Quién va a leer y a utilizar los casos de prueba seleccionados?
13. Tipos de Pruebas: considerar algunos escenarios propios de ciertos tipos de prueba (por ejemplo UAT, Regresión, Smoke).
14. ROI: el retorno de la inversión (ROI) para el negocio que tenga cada uno de los scripts, propio de cada empresa.
15. Número de pasos y verificaciones: la complejidad la da el número de pasos (acciones) y puntos de verificación (resultados esperados) que tenga cada uno de ellos.

Ahora bien, mucho tendrá que ver el tipo de proyecto en el que participemos, ya que el tratamiento a seguir no es el mismo para proyectos tradicionales (en cascada) que ágiles.

No está de más aclarar que la generación manual de casos de prueba es una tarea que se torna más compleja y costosa, a medida que el sistema a probar aumenta en complejidad y tamaño, y por ese motivo es tan importante hoy en día, más que nada por el time-to-market a cumplir, utilizar técnicas que permitan generar la automatización de los casos de prueba seleccionados previamente como mejores candidatos. Algunas posturas relacionadas a la hora de evaluar los mejores candidatos, enuncian:

• Escenarios que no pueden fallar bajo ningún concepto.
• Funcionalidades que si faltasen tendrían un impacto negativo en el cliente.
• La selección comienza con aquellos casos que cubren las funcionalidades principales.
• Casos con complejidad media de negocio, es decir, que no sea muy costoso automatizarlo.

Sin lugar a dudas, a partir de este contenido podremos profundizar en el próximo artículo acerca de situaciones un poco más concretas y “bajando a terreno”, como se suele decir habitualmente.