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.
[+/-] Read More...
[+/-] Summary only...
Entradas
