Nivel de abstracción de los Casos de Prueba

Un concepto simple de testing que se utiliza en GXtest dando mucho valor a los testers que van a trabajar diseñando pruebas es el de Data Driven Testing.

Este concepto permite diferenciar entre casos de prueba abstractos (o conceptuales), y casos de prueba concretos (o con datos).

Nos ha pasado que las empresas nos plantean que en su organización se cuenta con un conjunto de pruebas de regresión formado por miles de casos de prueba, pero ¿cómo se da esto? es porque estamos contando casos de prueba con datos y no casos de prueba abstractos. Veamos con un ejemplo, si estuviéramos probando el login de la aplicación:

Test case 1: probar con un usuario vacío y verificar que no entra

Test case 2: probar con password vacío y verificar que no entra

Test case 3: probar con usuario valido y password inválido y verificar que no entra

Test case 4: probar con usuario y password válidos y verificar que sí entra

Esto lo podríamos ver como un solo caso de prueba que sea

1.- ingresar usuario

2.- ingresar password

3.- botón login

4.- verificar resultado

que luego tenga "parametrizadas" sus entradas y verificaciones. O sea, que tome usuario y password y resultado esperado de una fuente de datos donde tenga las siguientes líneas

usuario vacio, password cualquiera, no entra

usuario cualquiera, password vacio, no entra

usuario válido, password inválido, no entra

usuario válido, password válido, entra

Entonces, de esta forma separamos el caso de prueba abstracto de sus instancias. Por un lado tenemos el caso de prueba abstracto que me dice qué hace el caso de prueba, y por otro lado tengo los datos con los cuales se va a "instanciar" el mismo. Cada caso de prueba concreto es una prueba diferente para la aplicación.

Ventajas

• Podemos describir el flujo de la aplicación en el modelo independiente de los datos
• Podemos tener en forma centralizada los datos de entrada y salidas esperadas en una tabla (o Excel)
• Podemos agregar más casos de prueba simplemente agregando líneas a la tabla
• Relacionado con el post anterior los casos de prueba expresados de esta forma van a constituir una mejor documentación de la aplicación.

Entonces, seguramente cuando alguien intente diseñar casos de prueba con GXtest deberá pensar las cosas en forma un poco distinta a lo que algunos suelen hacer. Debería ser en dos etapas, primero pensar el caso de prueba a nivel conceptual, y luego bajarlo a instancias con distintos datos. El otro camino es el inverso, si ya se tienen pensados varios casos de prueba con datos, antes de automatizarlos con GXtest se debería pensar si no se pueden conceptualizar o abstraer esos casos de prueba.

Qué dicen, les resulta más simple de esa forma?

La idea es seguir la filosofía GeneXus: Simplifiquemos las cosas haciendo nuestras tareas en forma más descriptiva y abstracta.

How to write a good test case: 5 tips to write better test cases

Leyendo este artículo sobre como escribir buenos test cases, me pareció importante relacionar estos 5 consejos con GXtest.

1) Escribir un caso de prueba para todas las condiciones

Cuando estamos hablando de código GeneXus tal vez esto sea como pensar no sólo en los distintos flujos que se dan en los procedimientos, sino en que se verifiquen las regla definidas sobre un objeto (ojo, no estamos diciendo de cubrir todo el código, ni que cubrir todo el código nos garantice nada).

2) Testear solo una cosa

Si bien con GXtest nos podemos ver tentados a testear varias cosas en un mismo Test Case, es conveniente mantener aisladas las pruebas para cada parte del sistema.

3) Hacer que los casos de prueba describan cómo trabaja el sistema

En GXtest describimos las pruebas con modelos simples, y esto hace que se describa el comportamiento esperado del sistema en forma sencilla. Hay algunos elementos que ayudan con este propósito. Por un lado se pueden poner comentarios de texto en los casos de prueba. Por otro lado podemos "partir" nuestro caso de prueba en varios sub-casos para lograr que luego cuando se vea en su generalidad se pueda entender los distintos pasos que se dan de manera más fácil.

4) Organizar los casos de prueba de manera consistente

GXtest permite utilizar folders (podrán verlo a partir de la beta 1.1) para organizar tanto los casos de prueba como los datos de prueba. Es importante tal como dice el artículo fijar un criterio para toda la empresa o por proyecto y seguirlo a rajatabla.

5) Hacer casos de prueba "FIRST class"

• Fast: GXtest se encarga de ejecutar los casos de prueba lo más rápido posible. En Abstracta es un desfío constante bajar los tiempos de ejecución de cada caso de prueba sin perder en estabilidad.
• Independent: en las suites de GXtest se agrupan varios casos de prueba. Es importante que en la suite puedan correr sus casos de prueba sin importar el orden.
• Repeteable: es deseable que cada caso de prueba se pueda repetir sin tener necesidad de hacer un restore de la base de datos. Para eso GXtest proporciona mecanismos para acceder a los datos utilizando procedimientos GeneXus, los cuales se pueden utilizar para borrar datos, obtener datos, etc.
• Small: casos de prueba gigantes no pueden cumplir con el primer requsitio Fast. Si bien con GXtest nos podemos tentar a hacer casos de prueba muy grandes es conveniente siempre mantener su tamaño acotado.
• Transparent: en GXtest se puede utilizar la descripción que tiene asociado cada caso de prueba para indicar claramente su propósito.

Es bueno para nosotros, a modo de validación, ver cómo con GXtest podemos adaptarnos a los buenos tips que se recomiendan en distintas fuentes.