lunes 8 de marzo de 2010

Testing automatizado - hagamos que las máquinas trabajen por nosotros

Si recuerdan, el año pasado en el Encuentro GeneXus en Montevideo, estuvimos a cargo de dos charlas y un café (en conjunto con el CES). En una de las charlas hablamos sobre el testing automatizado, con el fin principal de mostrar los distintos desafíos que se presentan y la forma que tenemos de enfrentarlos, en particular al trabajar con Genexus, para que así se animen a comenzar a automatizar.


Como seguimos con la apuesta a que se animen a automatizar les damos dos anuncios

1ro - salió el primer build después del despegue de la beta. Les recomiendo leer aquí para que puedan descargarla, y para que vean los avances que se han logrado desde la beta. Queremos hacer énfasis en que este es el mejor momento para dar feedback sobre el producto, pues nuestro foco en este momento está ahí.

2do - transcribimos la charla a nuestra documentación, a modo de transmitir mejor las experiencias obtenidas en el transcurso de nuestra historia en el testing automatizado de aplicaciones Genexus (acceda aquí).

Entonces todos a Automatizar!
Esperamos sus comentarios.


[+/-] Read More...

martes 2 de marzo de 2010

GXtest 1.1 beta released!!

Tenemos el agrado de anunciar que la versión beta de GXtest 1.1 está en la calle!
Nuestro objetivo fue el de brindar la nueva versión con todas sus nuevas funcionalidades servidas para que les sea práctico y fácil probarlas y visualizar sus ventajas, y las mejoras que ellas le traen a GXtest. En ese sentido hemos actualizado la documentación mejorando los tutoriales y guías para comenzar fácilmente a agarrarle el gustito al testing automatizado.

¿Cómo arrancar?
Primero debes registrarte al equipo de betatesters, luego descargarte la última versión disponible, y comenzar a probar. Eso lo debes hacer aquí.
En ese momento también tendrás acceso al foro para poder intercambiar dudas y experiencias sobre la herramienta. Todo el feedback que nos aportes será bienvenido y agradecido.

¿Dónde está la información técnica?
Está todo centralizado en nuestra Wiki junto a toda la documentación de GXtest, en este link. Ahí podrás encontrar una descripción de las nuevas funcionalidades, las mejoras implementadas, y una serie de lecturas recomendadas para comenzar.

[+/-] Read More...

jueves 11 de febrero de 2010

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.

[+/-] Read More...