abstracta

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

2010-03-08T06:24:00.001-08:00

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.

GXtest 1.1 beta released!!

2010-03-02T04:34:00.000-08:00

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.

Nivel de abstracción de los Casos de Prueba

2010-02-11T13:26:00.000-08:00

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

2010-02-09T07:10:00.000-08:00

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.

¿Cómo comenzar con el testing automatizado?

2010-01-24T14:00:00.000-08:00

Acabamos de terminar una documentación en nuestra wiki, la cual nos resultó interesante compartirla también por este medio (fuente: http://gxtest.abstracta.com.uy/wiki/index.php?title=%C2%BFComo_empezar_con_testing_automatizado%3F)

Muchas veces se visualizan los beneficios de automatizar parte de las pruebas pero no se sabe como comenzar, o se cuenta con una herramienta de testing automatizado pero no se está seguro acerca de su implantación. Por estos motivos en este artículo se discutirán los distintos aspectos importantes a tener en cuenta para comenzar con el testing automatizado, en particular utilizando GXtest sobre aplicaciones GeneXus, aunque varios de los conceptos y consejos que se mencionan aquí aplican a cualquier intento de automatización.

Comenzar con un proyecto piloto

Al igual que la mayoría de las prácticas de ingeniería de software, es conveniente elegir un proyecto adecuado y utilizarlo como proyecto piloto para comenzar.

El hecho de utilizar un proyecto piloto tiene varias ventajas:

poder definir una metodología inicial adecuada a la forma de trabajo de la empresa
adquirir experiencia en el uso de las herramientas de automatización
medir los beneficios
evaluar las dificultades
contar con un proyecto de alcance acotado en el cual focalizar los esfuerzos por mejorar la calidad

Es deseable que este proyecto piloto pueda mostrar en el menor plazo posible el ROI que se tiene al aplicar testing automatizado, por este motivo se deben seleccionar algunas métricas (de acuerdo a la realidad de la empresa y del proyecto) que lo visualicen. Algunas métricas que se pueden utilizar para este fin son las siguientes:

horas de testing / # de errores encontrados por el cliente
# de errores encontrados por el cliente / Tamaño del sistema
Tiempo de detección de los errores (entre que se introdujo el error y se detectó)
etc

También se puede evaluar a través de un cuestionario algunos aspectos subjetivos como son la motivación del equipo de testing, la sensación de estabilidad o calidad del sistema por parte de los usuarios o la percepción de calidad en el testing de los desarrolladores.

Ahora bien, ¿cuales son las características deseadas que tiene que tener el proyecto piloto?. Algunas de estas características son:

Tamaño del equipo pequeño: es preferible que el equipo de testing y el equipo de desarrollo sean pequeños. En equipos pequeños es más fácil introducir cambios y medir su impacto. Un factor muy importante es que el equipo vea el testing automatizado como una ayuda en su trabajo y no como una carga extra.
Skills de las personas involucradas: si se va a introducir un cambio es imprescindible contar con gente dispuesta a cambiar la forma de trabajo. Si esta gente es líder o referente en la empresa mucho mejor, ya que luego será más sencillo adoptar los cambios en el resto de los proyectos.
Cantidad de ciclos de prueba: las pruebas automatizadas tienen más valor cada vez que se corren, por este motivo aquellos proyectos que involucren varios ciclos de prueba son los que sacan más valor de este tipo de pruebas. Típicamente durante la etapa de mantenimientos de los sistemas se tienen algunas correcciones del mismo y luego se corren pruebas de regresión. Estos proyectos de mantenimiento suelen ser buenos candidatos para empezar con las pruebas automatizadas
Relevancia de la calidad del sistema: si bien todos los sistemas que desarrollamos tienen que ser de calidad, hay ciertos proyectos en los cuales los clientes son más demandantes en cuanto a la calidad y valoran más los aspectos referentes a la calidad.
Tecnología a utilizar: dependiendo de la tecnología que se utilice para desarrollar existen herramientas para automatizar de menor o mayor sofisitificación y de menor o mayor precio. Para el caso en que la aplicación se realice en GeneXus con GXtest se tendrán contemplados los distintos aspectos que necesita cubrir la herramienta, con otras tecnologías hay que evaluar otras alternativas.

¿Quién automatiza?

Una vez que se decidió del portfolio de proyectos, cual será el elegido para comenzar con la experiencia de testing automatizado se deberá asignar las personas que se involucrarán en el mismo. En particular se deberá elegir quienes serán los encargados de realizar el testing automatizado. La recomendación es que las personas encargadas de automatizar sean los mismos analistas que conocen de los requerimientos y de la realidad y que realizan el testing funcional tradicional. Es importante que sea el mismo grupo por varios motivos:

que no se genere competencia entre las pruebas manuales y las pruebas automatizadas
ayudar a asegurar la correcta elección de las pruebas que se realizarán de manera automatizado
las herramientas de testing automatizado pueden servir no solo para automatizar casos de prueba sino que también para generar datos para los casos de prueba. Por este motivo conocer de la herramienta de automatización ayudará a también en las pruebas manuales

¿Cómo formar a las personas que van a automatizar?

El proceso que siga cada una de las personas que vaya a automatizar puede variar según su grado de conocimiento en testing automatizado y en herramientas de automatización. Es aconsejable que de manera paralela puedan comenzar con la capacitación en la herramienta que se vaya a utilizar (con GXtest se puede empezar por ejemplo con Tutorial de GXtest Designer) así como también leyendo material acerca de metodología y experiencias de pruebas automatizadas en general. Una lectura recomendada es la 4º Edición de la revista Testing Experience dedicada al testing automatizado.

Selección de los casos de prueba a automatizar

Una vez que se tiene elegido el proyecto y la gente que participará en el mismo el punto crítico en la automatización de las pruebas es decidir cuales casos de prueba se automatizarán. El error más común en los intentos de automatización es intentar automatizar todo, así que la recomendación aquí es NO INTENTE AUTOMATIZAR TODOS LOS CASOS DE PRUEBA. Teniendo una visión del negocio y también de la estructura interna del sistema (para lo cual se necesita involucrar a los desarrolladores) se debe decidir cuales casos de prueba que se automatizarán. Algunas de los factores a tener en cuenta son:

¿cuales casos de prueba se necesitarán correr más veces durante el proyecto? Típicamente aquellos casos de prueba asociados al núcleo de la aplicación se pueden construir al principio del proyecto y luego sirven (adaptándolos cuando sea necesario) para el resto de la vida del sistema.
¿cuáles casos de prueba conllevan mucha dedicación humana y son repetitivos? Hay veces que un caso de prueba requiere de un trabajo tedioso para configurar el ambiente de prueba y luego ejecutar el caso de prueba. Estos casos de prueba es bueno automatizarlos para liberar el recurso humano y que pueda dedicarse a otros casos más desafiantes.
¿que funcionalidades son críticas para el cliente/usuario? Aquellas funcionalidades que tienen que andar si o si en cada entrega generalmente es interesante incluirlas en los casos automatizados.
¿que costo tienen asociado la automatización del caso de prueba? Hay casos de prueba que son muy difíciles de automatizar, ya sea porque hay que realizar validaciones visuales complejas o por otras razones. Por este motivo si el costo de su automatización es grande hay veces que es mejor dejarlo para ser ejecutado manualmente.

Teniendo en cuenta estas características se puede ponderar cada caso de prueba en base a cada una de ellas para luego hacer un ranking o priorizar los casos de prueba a automatizar.

En el caso de que se vaya a automatizar en un proyecto de mantenimiento en el cual ya se están corriendo pruebas manuales, muchas veces la fuente de información más importante que tenemos para elegir los casos de prueba a automatizar es el historial de incidentes. Con este instrumento más las consideraciones vistas previamente se puede tener una idea clara de cuales son aquellos casos de prueba o funcionalidades a automatizar.

Cómo Comenzar

Luego de seleccionar un proyecto para un piloto, y seleccionar ciertos casos de prueba para automatizar, lo que recomendamos es comenzar por un subconjunto acotado de casos de prueba (no más de 10) y ponerlos a funcionar. Esto es: diseñarlos (en papel, planillas, etc.), automatizarlos (con GXtest Designer y Recorder), preparar ambiente y datos para poder probarlos, preparar la ejecución programada de estos casos (con GXtest Manager, haciendo que ejecuten todas las noches por ejemplo) y definiendo las metodologías para trabajar. Una vez que preparemos esto comenzaremos a ver los beneficios y a alimentar la máquina de pruebas automatizadas, haciéndola crecer cada vez más, obteniendo cada vez más beneficios.

Ver también

Se viene GXtest 1.1

2010-01-19T10:47:00.000-08:00

Como ya habrán leído por ahí, hace ya unos meses que se lanzó la primera versión comercial de GXtest (**). Hoy en día, nos estamos preparando para lanzar una nueva versión, poniendo a disposición más funcionalidades y mejoras.

Ejecución en Firefox

En un comienzo GXtest permitía grabar las pruebas y ejecutarlas en Internet Explorer. La ampliación en este sentido fue el haber agregado la posibilidad de ejecutar en Firefox. Entonces, las mismas pruebas las podremos ejecutar ahora en dos de los más famosos Navegadores. Estaremos trabajando en futuro para dar soporte para otros, como ser Google Chrome. También en este sentido será interesante dar la posibilidad de poder grabar las pruebas en otros Navegadores.

Integración con la BL de GeneXus X (o superior)

Si se desea automatizar pruebas sobre una aplicación es necesario brindarle a GXtest el acceso a la metadata de la KB de la aplicación. Si se trata de GeneXus 9 o inferior se puede utilizar GXpublic. También se puede utilizar el XPZ obtenido tras exportar la KB desde GeneXus, y en el caso de que estemos utilizando GeneXus X o superior era necesario hacer un export con una extensión específica que forma parte de la solución GXtest. El problema con esto es que era necesario instalar la extensión en GeneXus, entrar, abrir la aplicación, exportar generando así un archivo .GXT (similar a un XPZ), luego entrar en GXtest e indicar la ruta a este archivo. Esto cada vez que se quiera impactar los cambios del ambiente de desarrollo sobre el de testing. Por eso es que agregamos la opción de acceder a la KB a través de la BL (GeneXus Business Logic) cuando se trata de GeneXus X o superior. Esto brinda la misma comodidad para el usuario que cuando se trata de GeneXus 9 o inferior y selecciona usar acceso con GXpublic.

Organización en Folders

En un principio no se ve la necesidad, pero cuando uno comienza a automatizar pruebas y tiene cada vez más Test Cases automatizados se puede volver complejo administrarlos y organizarlos. Para ello ahora se puede trabajar en una estructura de Folders (directorios/carpetas) que nos permiten más facilidad para clasificar y localizar luego cada uno de nuestros Test Cases o Data Pools.

A futuro agregaremos la opción también de categorizar los artefactos de prueba, para poder manejar varios criterios de clasificación.

Mejoras de performance en la ejecución de pruebas

Se optimizó notoriamente la ejecución de las pruebas. Esto es muy importante para poder tener los resultados de grandes cantidades de pruebas en menor tiempo.

Gráficas para Resultados

Como dijo Scott Barber en un evento del CES una vez, "más vale números que letras, y más vale gráficas que números". Siempre que uno quiere analizar grandes cantidades de datos se simplifica mucho más pudiendo visualizarlos en forma gráfica, por este motivo se agregaron los primeros reportes gráficos en GXtest Manager (encargado de gestionar el repositorio de pruebas).

En Abstracta estamos muy contentos por los logros y el crecimiento que vemos que GXtest está alcanzando, y por el feedback positivo de los clientes que han confiado en este corto plazo de vida que tenemos. Gracias!

Estamos también pensando en definir un período de betatesting, ¿hay interesados?

(**) La misma es comercializada a través de Artech y su red de distribuidores en todo el mundo, o poniéndose en contacto con sales@genexus.com.

Automatizar el diseño de los casos de prueba

2010-01-04T11:28:00.000-08:00

Uno de los puntos fuertes que nos planteamos al comenzar con GXtest fue la generación de casos de prueba a partir de modelos. Hoy en día con GXtest se pueden expresar los casos de prueba como modelos pero no se puede generar automáticamente casos de prueba a partir de ellos.

La idea es que el tester pueda expresar el conocimiento que tiene sobre la realidad en un modelo para que luego a partir del mismo se generen los casos de prueba.

Les recomiendo que lean este artículo para entender mejor la motivación de este enfoque

Test Case Design: Manually or Automated?

Los dos modelos que siempre tuvimos en mente fueron el modelo de máquinas de estado y el modelo de casos de uso/diagrama de flujo.

¿Cómo podemos utilizar este enfoque con GXtest?

Una opción es utilizar (como dice en el artículo) una herramienta como Ms Visio para modelar nuestra realidad. Este modelado podría ser por ejemplo con un diagrama de flujo en donde en las distintas interacciones con el sistema se utilicen nombres de casos de prueba realizados en GXtest.

Luego que tenemos el modelo listo, este puede ser utilizado por una herramienta para generar distintos casos de pruebas, basándose en algoritmos conocidos de generación (realizando recorridas sobre el modelo). Estos nuevos casos de prueba generados, pueden estar en un formato "compatible" con GXtest.

Me parece que este es un mecanismo interesante para mejorar el testing en las empresas, mejorando de esta forma el alcance y cubrimiento de nuestras pruebas.

Algunas preguntas para quienes leen el blog, ¿Con que herramientas realizan el modelo de la realidad y/o de los requerimientos? ¿Ven factible aplicar algoritmos para la generación de casos de prueba a partir de estos modelos?

Seminario: Testing para Desarrolladores del CES

2009-12-07T12:30:00.000-08:00

El Centro de Ensayos de Software dictará un seminario de testing enfocado a desarrolladores.

Aquí está el resumen http://www.ces.com.uy/seminarioDesarrolladores2009/seminarioDesarrolladores.htm

aquí tienen más información sobre el contenido http://www.ces.com.uy/seminarioDesarrolladores2009/ContenidoSeminarioDesarrolladores.pdf

Está enfocado más que nada a programación Java, pero los conceptos son bien aplicables en cualquier ambiente de trabajo.

Nos vemos por ahí :)

Automatización de acciones de un tester: archivos de entrada

2009-12-03T03:20:00.000-08:00

En los casos de prueba se puede dar la necesidad de invocar distintos tipos de acciones. Si intentamos automatizar lo que hace un tester ahi tenemos un amplio abanico, pues un tester al probar una funcionalidad suele necesitar copiar archivos, disparar distintos programas, comandos, etc., incluso hasta verificar si le llega un e-mail generado por el sistema.

Nos tocó un caso en un cliente, el cual tiene un sistema que a partir de un archivo que se copia por FTP a un directorio hace que se generen tareas en un Flow, por lo que en ese caso de prueba automatizado se necesita copiar archivos en esa carpeta.

La primer solución que pensamos para poder hacer esto en GXtest fue generar un GeneXus Procedure que genere ese archivo en esa carpeta, ya que GXtest puede invocar procedimientos GeneXus desde los casos de prueba, por lo que podríamos automatizar este caso particular.

Una mejor solución nos la sugirió José y nos llevó a agregar un nuevo comando en GXtest el cual da mayor flexibilidad para otros tipos de situaciones. Un comando que pueda invocar un programa por línea de comandos. De esta forma en un caso de prueba automatizado se podría enviar el archivo por FTP tal como lo haría un tester o un usuario real.

Claro está, que esta solución resuelve otras situaciones como copiar archivos, ejecutar aplicaciones externas, etc.

¿Para que otras cosas se les ocurre que puede servir?¿Se les ocurre algo más que no esté quedando contemplado?

Automatización de "aplicaciones complejas"

2009-11-24T16:25:00.000-08:00

En un par de charlas nos han preguntado, "¿Qué pasa con GXtest si mi aplicación se comunica con otras aplicaciones legadas mediante mecanismos complejos?", "¿Qué pasa si consume servicios Web expuestos en otros servidores?" "¿Qué pasa si mi aplicación tiene lógica muy compleja?"

Imagen: a partir de un botón en la aplicación bajo pruebas se ejecuta una lógica compleja, hay comunicación con varias aplicaciones externas, y se dispara un cohete.

GXtest tiene como objetivo reproducir la interacción del usuario con el sistema, por lo tanto estas complejidades son indiferentes para GXtest. Una vez que el usuario presiona un botón, la lógica que se ejecuta a partir de esa acción pude ser simple o compleja, pero "a la vista" de GXtest es transparente (tan transparente como a la vista del usuario). Tal como se muestra en la imagen, no importa si se dispara un cohete o lo que sea, lo que "importa" para automatizar es la interfaz de usuario en este caso.

Ahora bien, hay veces que el caso de prueba requiere que se hagan otras acciones que no se pueden hacer en el navegador, por ejemplo consultar una base de datos, copiar archivos a un determinado lugar, etc. Para estas acciones GXtest (al igual que otras herramientas) brinda la posibilidad de realizarlas.

Bonus track:

El hecho de que una aplicación compleja no agregue dificultades a GXtest no implica que no agregue dificultades al momento de pensar y diseñar las pruebas automatizadas.

Dos de los temas más importantes que se pueden destacar son la preparación de los datos y la simulación de los servicios externos que se consumen. En particular en el segundo punto hay veces que es interesante que realmente el sistema bajo testing se "conecte" al servicio externo y hay otras veces que es preferible simular este servicio. El artefacto que simula el servicio externo generalmente se lo llama Mock Service.

En el caso de que ese servicio sea un web service les recomiendo la aplicación SoapUI que brinda una interfaz muy amigable para generar servicios Mock así como para testear servicios Web.

¿Qué otras herramientas utilizan para sus pruebas (automatizadas o no)? ¿qué cosas requieren sus casos de prueba (FTP, Web Services)?

GXtest por Uruguay y el mundo

2009-10-28T16:55:00.000-07:00

Con el fin de difundir GXtest, encaminamos una serie de presentaciones en distintos lugares. Aca les dejamos un resumen de las que ya ocurrieron y las que vienen...

México

Rodrigo Alvarez fue el primero (aparte de nosotros :P) en realizar una presentación de GXtest con demo incluída. Estuvo mostrando el producto a los distribuidores de ese país y vino con comentarios muy buenos.

Buenos Aires, Argentina

De la mano de Toolnology y Artech, presentamos el 21 y 22 de octubre GXtest en Buenos Aires. La verdad estuvo muy bueno ya que tuvimos la oportunidad de conocer mejor las inquietudes en el área de testing en el país vecino y nos fuimos muy contentos ya que la gran mayoría visualizaba a GXtest como una ayuda en su proceso de testing.

Montevideo, Uruguay

El 27 y 28 de octubre junto con Artech estuvimos presentando el producto acá en Montevideo. Asistieron una gran cantidad de empresas (según algún amigo de Artech eso fue porque en la invitación pusimos que había desayuno :P). Más allá de porque fue la gente, en general se mostraron muy interesados por el producto y con ganas de empezar a evaluarlo para ver como se adapta a sus realidades.

Chicago, Estados Unidos

El Fede estará mostrando el producto en el Genexus 5th USA Annual Event el 2 y 3 de Noviembre.

Chile

Ayer Rodrigo presentó GXtest en el Evento Chileno. Esperamos los comentarios del mismo...

Paraguay

Fabián estará viajando el próximo martes 3 a Asunción para presentar el producto en las instalaciones de SISA.

Brasil

Sao Paulo nos espera el 2 y 3 de diciembre para presentar GXtest a Corporativas y software houses.

Además el 17 y 18 de noviembre en el Latu estaremos brindando un curso de GXtest para que las empresas lo puedan conocer más en profundidad.

Abstracta en el XIX Encuentro Internacional GeneXus

2009-09-03T15:41:00.000-07:00

Estamos muy contentos de invitarlos al XIX Encuentro Internacional GeneXus!!

Como saben, este mes en el encuentro de usuarios liberamos la versión comercial de GXtest, y nos alegramos en invitarlos a todos al encuentro en general y a las instancias que estaremos participando en particular.

Abstracta estará participando en las siguientes instancias

GeneXus en el desarrollo, GXtest en el testing: presentaremos la primer versión comercial de GXtest.

Testing Automatizado: ¡Hagamos que las máquinas trabajen por nosotros!: estaremos compartiendo nuestra experiencia en automatización de pruebas funcionales, y todos los desafíos que involucra embarcarse en estas tareas.

Café con Testing Automatizado: junto al CES y todos los participantes estaremos charlando sobre el testing automatizado. La idea es tener un ámbito distendido en donde puedan discutirse temas relacionados al testing automatizado.

Los esperamos a todos en el XIX Encuentro Genexus!!

Inscribite en http://www.genexus.com/encuentro/

¿Quién crea los casos de prueba?

2009-08-31T08:44:00.000-07:00

Para seguir con la serie de articulos sobre preguntas del testing automatizado, es que aquí planteamos esta, ¿Quién es el que crea los casos de prueba?

Algunos casos de prueba los puede crear el desarrollador, otros los testers y otros los clientes.

Los casos de prueba pueden ser creados, ejecutados, aprovechados, por muchas personas dentro de la vida del software. Con esto me refiero a que se van a ver beneficiados desde los desarrolladores al construir el primer prototipo, hasta el último de la cadena de producción que es el usuario que va a utilizar el sistema.

Cada una de las personas que participan podrán tener distintos objetivos y desafíos, podrán obtener distintas ventajas o beneficios de la automatización de pruebas.

Desarrollador:

Seguramente un desarrollador que implemente el Objeto1 (transacción o WebPanel), o el Proc1, implementará pruebas que exploten a ese objeto en forma más unitaria, probando con casos bien concretos, viendo qué pasa con las distintas entradas.

Los casos de prueba serán cortos y generalmente no utilizarán otros objetos a menos que sea necesario.

Por lo general también sucede de que al ser la misma persona que desarrolla, las pruebas estarán pensadas con una lógica similar a la que se usó al desarrollar.

Tester:

El tester ya tendrá más vision global, vision de negocio, por lo que será capaz de probar las funcionalidades en un ciclo completo.

Los casos de prueba serán más largos y complicados, buscando las formas posibles de evidenciar las faltas más importantes de la aplicación.

Usuario:

El aporte más rico del usuario es que sabe priorizar mejor que nadie las funcionalidades críticas para su negocio, con la parametría propia de su realidad, y con el modo de uso que le da al sistema.

Los casos de prueba serán pensando en sus necesidades y no en las fortalezas o debilidades de la aplicación. Le interesa que funcione lo que a él le da más valor.

Como conclusión podemos decir que la mezcla de todas estas visiones es la que genera un verdadero mix saborizado de pruebas. Sería ideal contar con aportes desde todos estos lados a la batería de pruebas a ejecutar.

¿Quiénes hacen pruebas en sus organizaciones?

Cómo elegir cuando ejecutar los casos de prueba?

2009-08-11T06:00:00.000-07:00

Otra de las preguntas que surge al llevar a cabo un proyecto de automtización de pruebas es en qué momento ejecuto las pruebas?

Lo primero que uno piensa es tan frecuente como se pueda, sin embargo, los recursos son escasos y dependiendo de la cantidad de pruebas automatizadas el tiempo que se demore en ejecutar puede ser muy largo.

Generalmente se puede apuntar a tener algunos ambientes bien separados. A modo de ejemplo simple:

el de desarrollo (cada desarrollador)
el consolidado de desarrollo
el de testing (dentro del equipo de desarrollo)
el de pre-producción (testing dentro del cliente)
el de producción.

El conjunto de pruebas y la frecuencia de las mismas en cada uno de estos ambientes seguramente sea diferente.

En desarrollo se tiene la neceidad de mayor agilidad, ya que se van a querer correr con mucha frecuencia, imagino que después de cada cambio importante, antes de hacer un commit en el sistema "SVN" o "CVS" o equivalente.

Ahora para eso sería muy conveniente correr solamente las pruebas necesarias (mirar el post anterior). Estas pruebas tienen el fin de darle un feedback rápido al desarrollador.

Una vez que el desarrollador libera su módulo o cambios a la consolidación, se ejecutarían pruebas a modo de Pruebas de Integración. Acá lo ideal sería que corran en las noches así de mañana cuando llegan los desarrolladores tienen una lista de posibles asuntos a solucionar, y que tengan un feedback de los cambios que introdujeron ayer. Mientras menos tiempo pase más rápido lo van a solucionar. Esto permitiría no pasar a testing cosas que no funcionen. Serían como pruebas de humo en cierta forma.

Luego cuando se pasa la aplicación a testing, se debería correr un conjunto más grande de pruebas de regresión que intenten asegurar que los errores que se han reportado y se han marcado como solucionados no están presentes en esta nueva versión. Este conjunto de pruebas puede tardar más tiempo en correr. Estas pruebas no tienen porque ser periódicas sino que pueden adecuarse al cronograma del proyecto con las fechas previstas de liberación.

Cuando se llega a la versión entregable de la aplicación (aprobada por el equipo de testing), la misma se libera al cliente. Este por lo general la testea también en un ambiente de pre-producción, el cual debería ser totalmente simétrico en configuración al de producción (esta es la diferencia con el ambiente de testing del equipo de desarrollo). Aquí también aporta valor tener un conjunto de pruebas automatizadas.

Este conjunto de pruebas podría ser como mínimo el que se corrió en testing, e incluso se le podría entregar al cliente el conjunto de casos de prueba automatizados junto con la aplicación liberada, ya que le da mayor seguridad y confianza al cliente el saber que se testeó antes de su liberación.

Como manejan las pruebas hoy en día? que ambientes manejan?

Algunas de estas ideas aplican ya sea que se tengan pruebas automatizadas o no?

Cómo elegir qué ejecutar?

2009-08-07T10:52:00.000-07:00

Esto es un problema que se plantea al momento de tener muchos casos de prueba automatizados. Cambia la aplicación y tengo que decidir qué casos de prueba ejecutar.

Si tengo tiempo la respuesta es simple: TODOS. Esto me dará más garantías, y no me cuesta más que mandar a ejecutar una prueba.

Ahora, qué pasa si no tengo tiempo suficiente. Ahí es donde tengo que seleccionar los casos de prueba que me den mejor relación costo-beneficio, o sea, aquellos que verifiquen todo lo que pueda estar impactado por los nuevos cambios en la aplicación.

Cambiamos entonces a una nueva pregunta: ¿cómo saber qué casos de prueba verifican cosas sobre los nuevos cambios ingresados a la aplicación?

Este problema lo entendemos a dos niveles. Un primer nivel, y es el que parece más obvio, si cambian los objetos de interfaz de usuario los casos de prueba automatizados se verán impactados, y ahí se detecta fácilmente cuáles son los que tengo que volver a ejecutar.

Ahora, lo más desafiante es poder extender este análisis para que contemple también en base a cambios de la lógica.

Si tenemos la metadata suficiente para detectar esos cambios a nivel de lógica luego se puede a partir de esto ir subiendo hasta ver qué elementos de interfaz gráfica están involucrados en los cambios, y así descubrir los casos de prueba que me vale la pena volver a ejecutar, o al menos llegar a establecer cotas, dejando por fuera los que no tienen posibilidad de haber sido afectados.

Palabras tomadas de un colega:

La tendencia en integración continua es que la selección de Test Case sea guiada, ya que en aplicaciones grandes no daría el tiempo de horas máquina para simular de forma secuencial todos los TestCase automatizados.

Una propuesta de solución a este problema va a venir incluida en el nuevo Visual Studio 2010. En un componente llamado Test Impact, les dejo un par de links: link1 y link2. En pocas palabras lo que hacen es correr los casos de prueba fijándose el cubrimiento que los mismos tienen y luego en base a esto proponer qué casos de prueba ejecutar ante cada cambio. Ahora, ¿qué pasa con esto si no hay cambios en el código sino que el cambio está en el esquema de la BD o en los datos de la BD?

¿Cómo seleccionan los casos de prueba a ejecutar ante cada nueva release?

PIM y PSM en el Testing

2009-08-05T10:08:00.000-07:00

Estos días estuve leyendo el artículo de Bea (pueden encontrar una breve descripción en la página del CES (dentro de Proyectos de Investigación/Pruebas en Líneas de Producto de Software (ProTest)) , y ahí recordé algo que aplica a Genexus, que es lo de Platform Independient Model y Platform Specific Model.

O sea, en el mundo GeneXus, la KB sería el PIM y la aplicación generada el PSM.

En nuestro caso, vemos que GXtest es una herramienta que maneja modelos PIM, y tiene las ventajas típicas de estos modelos en comparación a las herramientas tradicionales que se acercan más a un PSM, pues van directo al HTML del Java generado, o del .Net generado.

Además fui a una charla de un amigo español (Dr. Ruiz) la cual me resutló muy interesante como para profundizar el tema.

Algo que nos preguntábamos es si en alguna forma GeneXus se puede definir como un Lenguaje especifico de Dominio? Cual sería el dominio en ese caso? Qué opinan?

Mantenimiento de Pruebas de distintas Versiones de la misma KB

2009-08-03T08:30:00.000-07:00

Supongamos que hoy tengo una versión de la aplicación Carrito.v.1. Todos los casos de prueba funcionan sobre esa versión. Tal vez esa versión de Carrito.v.1 está congelada e instalada en un par de clientes.

Ahora bien, supongamos también que sigo desarrollando y se produce una nueva versión que le llamaremos Carrito.v.2. Es probable que hayan cambiado algunas funcionalidades, se hayan agregado una nuevas, etc. Entonces es importante actualizar todos los casos de prueba (ya sean manuales o automáticos) para que se adapten a esta nueva versión.

Cómo manejan ustedes esto hoy en día? Una opción es tener dentro de la "línea base", con un tag del SVN o en algún lugar separado, no sólo las distintas versiones de la KB (u código), sino también las distintas versiones de los casos de prueba, no?

Luego cuando el cliente de Carrito.v.1 reporta un error hay que ir a arreglarlo a Carrito.v.1 y fijarse si ese bug aplica también a Carrito.v.2. Luego hay que correr los casos de prueba de regresión de ambas versiones. Y si luego tengo Carrito.v.N, cómo hago para correr los casos de prueba asociados a las N versiones??

Pensando en esta problemática GXtest ofrece hoy en día dos facilidades. Por un lado una funcionalidad para impactar los casos de pureba automatizados con la nueva versión de la aplicación (KB). Por otro lado lo que permite es duplicar todo un proyecto de pruebas (casos de prueba, datos de prueba, etc.) a modo de "Taggearlo" para que de esa manera pueda conservar los casos de prueba en distintas versiones del producto. Entonces se puede ejecutar pruebas actualizadas sobre la última versión del producto, pero interesa que si se hacen cambios sobre la versión del cliente aún se puedan correr las pruebas de regresión sobre esa versión previa congelada.

Resumiendo. La infraestructura final de pruebas contará con N instancias de la aplicación bajo prueba, una para cada versión que interese correr pruebas de regresión. Por otro lado tendremos N proyectos de prueba en GXtest con los distintos casos de prueba, cada uno correspondiéndose con las versiones de la aplicación.

Se Busca una idea original!!

2009-07-28T05:48:00.000-07:00

Estamos buscando una idea original para promocionar GXtest en el evento GeneXus. Por ese motivo y con plena confianza en quienes leen este blog, es que lanzamos el concurso de "Ideas Originales para Promocionar GXtest en el Evento GeneXus".

Cualquier lector en cualquier parte del mundo puede participar del concurso dejando su comentario en este post (si Simon, estamos pensando en vos también que sabemos que te sobran ideas originales :P).

El objetivo de la idea original debe ser lograr que la gente conozca GXtest y sepa para qué los puede ayudar. Cualquier tipo de juego, concurso o lo que se les ocurra sirve.

La semana pasada surgió una idea muy buena, pero por lástima solamente a mi me pareció grandiosa. La idea consiste en mandar a hacer unos matamoscas inflables (con el logo de GXtest). La idea entonces era regalar estos matamoscas y que la gente luego pueda matar bichos (Bugs) con el super matamoscas.

Luego se le sumaron otros complementos a la idea como por ejemplo regalar también punteros láser en forma de bicho. Uno de las objeciones a la brillante idea es que la gente va a ir a otras charlas y va a ocasionar disturbios para los cuales se presta tanto el puntero láser como el matamoscas :P

Se agradecen todas las colaboraciones!!

PD: las mejores 5 ideas llevarán como premio una mención y agradecimiento especial en el blog de Abstracta :D

DataPools

2009-07-27T04:30:00.000-07:00

Los DataPools (en donde se guardan los datos de entrada de los casos de prueba) le dan un gran poder a los casos de prueba, pero cuando empezamos a construir casos de pruebas relativamente grandes nos hace falta ese "poder" que sentimos los desarrolladores al escribir sentencias tales como JOIN (en SQL), foreach (en Genexus) y otros, para manipular datos en estructuras tabulares.

En un lenguaje "gráfico", o en un modelo, es más difícil expresar este tipo de realciones en forma simple para el usuario. De todos modos la necesidad existe, y muchas veces queremos "mantener el contexto" del conjunto de datos que estamos utilizando en cada ejecución.

Para esto construimos un mecanismo que le llamamos "DataPools estructurados".

Aquí están las diapositivas que intentan explicar el funcionamiento de DataPools:

GXtest - DataPools Estructurados

View more presentations from guest7f6eaae.

Necesitábamos brindar un mecanismo lo más intuitivo para el tester. En general, cuando un tester construye un caso de prueba, piensa por un lado las acciones que se tienen que ejecutar en la aplicación, y por otro lado varios conjuntos de datos para utilizar en esas acciones.

Por ejemplo, para un caso de prueba de "alta de países", nos puede interesar primero probar con el conjunto de datos 1, que referido a Uruguay, con los departamenteos Salto, Paysandú y Montevideo, etc., y luego el conjunto de datos 2 para Argentina, con las provincias de Río Negro, Corrientes y Santa Fe.

Eso es lo que intenta expresar cada "Set Id": todos los datos, en los distintos datapools, se agrupan por el identificador de conjunto de dato.
Es similar a cuando uno piensa los datos de prueba para cada caso. Se agrupan, se definen e identifican.

¿Se entendió la idea? Se aceptan sugerencias!!

Composición de Comandos

2009-07-24T06:10:00.000-07:00

El amigo Marcos nos sugirió una idea que está muy interesante: dar la posibilidad al usuario de componer comandos.

Como sería esto? Por ejemplo si siempre para hacer login en mi aplicación ingreso dos campos (usuario y password) y luego presiono el boton de ingresar, sería deseable poder llamarle a esas tres acciones Login y utilizarlas donde quiera como un comando común.

Hoy en día, si quiero hacer esto, lo más práctico es hacer un caso de prueba similar al de la figura, llamado login, que haga estas tres acciones y luego incluirlo en el caso de prueba que desee (en la imagen las acciones estarían asociadas a la arista login).

La ventaja que tiene poder componer comandos (aparte de la puerta que abre para crear cosas bastante sofisticadas) es la posibilidad de dejar más compactos los casos de prueba sin necesidad de tener que incluir casos de prueba para representar acciones comunes en la aplicación.

Formalizando un poco el planteo, el requerimiento sería poder definir nuevos comandos (esto implica nombre y tipo de comando -evento, accion o validación-) el cual recibe una lista de N parámetros, los cuales se mapean a una lista de M comandos. Los parametros de los M comandos podrán ser parte de los N de entrada o simplemente tener valores fijos.

Que les parece la idea? A nosotros nos pareció muy interesante y ya la anotmos en la wiki de Abstracta para implementarla más adelante.

Se aceptan sugerencias.

Nuevo socio de la CUTI: Abstracta

2009-07-23T07:10:00.000-07:00

Abstracta es ahora socio de la CUTI

Nos hicimos socios aprovechando un nuevo programa que tiene la CUTI para emprendimientos nuevos. La CUTI en conjunto con varios actores de gran peso están apoyando de diversas maneras los emprendimientos en Uruguay. Esto es muy bueno para todos, no solo para los emprendedores sino también para todo Uruguay. Esperemos en unos años ver el fruto de toda esta movida.

La CUTI además de brindar una lista extensa de servicios a los socios, nos permite contar con un apoyo importante a la hora de salir a vender nuestro producto.

Otros beneficios importantes son: el pertenecer al programa Bizpark de Microsoft, del que hablamos hace un tiempo en este post, y también FengOffice gratis por 3 años!

Habrá que sacarle jugo a todas estas cosas!!

Nuevas Oficinas (II)

2009-07-13T21:00:00.000-07:00

El título de este post no significa que ya nos mudamos de nuevo! sino que tenemos noticias con respecto a lo que propusimos en "Nuevas Oficinas". A partir del mes de julio tenemos roomates.

Se trata de algo que no nos imaginamos en un comienzo. Nosotros buscábamos una pequeña empresa que esté en la misma que nosotros. No es exactamente así, los que se vienieron al apto son tres freelancers.

Bienvenidos Nacho, Gerva y Nando!

De todos modos estamos con la ambisión de conseguir algún otro interesado, ... el apto es grande y se presta para más!

De paso aprovechamos y nos pusimos a pintar :)

Test cases resistentes a parametrizaciones

2009-07-07T14:46:00.000-07:00

Problema:

Tengo un Test Case para el caso de uso de "Alta de producto". Este caso de prueba debe funcionar y testear correctamente el caso de uso para cada una de las parametrizaciones deseadas.

Esto significa, hacer un Test Case que sea resistente a las parametrizaciones.

En las aplicaciones desarrolladas con GeneXus es muy típico que se permitan muchos tipos de parametrizaciones, y esto trae asociado ciertas complicaciones: las respuestas esperadas válidas varían según cómo esté parametrizada la aplicación, incluso el flujo a recorrer. Esto implica que al modelar un Test Case se tengan que agregar bifurcaciones en el flujo, las cuales se guíen por decisiones basadas en los valores de estas parametrizaciones. El tema es que hay que ver cómo averiguar (dentro del Test Case) cuáles son los valores de esas parametrizaciones al momento de estar ejecutando.

¿Cómo hacer Test Cases soportando parametrizaciones? ¿cómo tomar estos valores de parametría al momento de la ejecución, sin tener que indicárselos manualmente? Voy a sugerir algunas soluciones, alguna es aplicable en distintas herramientas, otra (la más eficiente) es más específica para GXtest, aunque se puede hacer algo similar en otros ambientes también.

El objetivo es tomar los valores de los parámetros que afectan al caso de uso.

Solución #1: hacer un Test Case por cada una de las combinaciones de parámetros. Esto evidentemente tiene la desventaja de que se duplica trabajo y se aumentan los puntos de falla.

Solución #2: diseño Test Cases auxiliares que sirvan para consultar esos parámetros y estos se cargan en variables (o lo que maneje la herramienta), y entonces de esa forma en el Test Case de "Alta producto" ejecuto primero los Test Cases auxiliares que consultan parámetros, y luego se hacen las decisiones en base a las variables cargadas. La principal desventaja es que esto hace que se vaya por muchas pantallas innecesariamente, consumiendo más tiempo de ejecución para cada Test Case que requiera consultar parámetros. Además, es necesario automatizar Test Cases que tal vez no son incluidos en el conjunto de pruebas de regresión, o sea, que no estaban planeados en la automatización.

Otra desventaja es que si llega a fallar uno de los Test Cases que toman parámetros, entonces no se podrá ejecutar el Test Case principal.

Solución #3: la que creemos más eficiente es con ProcGX, los cuales se desarrollen específicamente para devolver los valores de los parámetros que se necesitan. Desde GXtest es posible cargar en variables el resultado de la invocación a un ProcGX y luego tomar bifurcaciones en base a estas variables (pero esto es útil as well en otras herramientas en las que se pueda invocar a Web Services). La ventaja es que en tiempo de ejecución es más eficiente, así como en tiempo de desarrollo. La desventaja es que el tester "depende" del desarrollador para esta tarea.

Un comentario al margen es que las parametrizaciones en los casos de prueba es un tema ligado con a Líneas de productos de lo cual hemos hablado en el blog. Ese enfoque nos podría permitir derivar los casos de prueba a partir de la línea de producto específica que tengamos, permitiendo de ese modo no solo crear sistemas más sencillos y específicos sino también casos de prueba más prolijos.

¿Alguien más se ha chocado con este problema? ¿alguna otra solución que se les ocurra?

Testing is not a phase!

2009-06-22T15:43:00.000-07:00

Cómo aprendemos sobre testing? cómo usamos el testing en nuestros desarrollos?

Estará eso vinculado?

En nuestro caso en la facultad vivimos un proceso un poco estricto, que se refleja bastante en la industria:

primero matemáticas y materias formativas, nos ayudan a crear el pensamiento abstracto y lógico

programación básica, estructurada y usando constructores fundamentales

programación con tipos abstractos de datos

programación con algoritmos sobre estructuras de datos

programación orientada a objetos (en c++)

un lenguaje con más abstracción (java)

mechado por ahí tenemos sistemas operativos, arquitectura, y otras yerbas

luego, un proceso pesado como lo es el RUP, poniéndolo en práctica en un grupo de 12 a 14 personas. Recién en estas materias se ve algo de testing.

para 4to o 5to año hay una electiva (en la que participamos como docentes Diego Vallespir, Mónica W. del CES, Matías y yo) llamada TVS.

Qué nos deja esto? que el Testing es algo que queda para el final, ... oh vaya casualidad! no es esto lo que pasa generalmente en el desarrollo? Por eso se habla tanto de la "etapa de testing", cuando en realidad debería ir más de la mano con el desarrollo en sí.

Hace poco participé de una reunión en facultad (con integrantes del CES también) en la que se demostraba el interés por cambiar esto, y comenzar el cambio desde la enseñanza, mostrando que el testing no es una etapa, no es algo que se hace al final, sino que es una tarea que acompaña y retroalmienta al desarrollo desde un principio.

A nosotros nos interesó hablarles de esto para contarles de una funcionalidad de GXtest en realidad, que tiene como objetivo en gran medida permitir que las pruebas automatizadas se lleven en conjunto con el desarrollo. Si bien esto no es lo único importante para acompañar el desarrollo con el testing, es nuestro granito de arena.

Ya por usar Genexus tenemos la posibilidad de ir probando nuestros "prototipos", que en realidad son la aplicación en sus orígenes. La idea con Genexus (tal como lo dicen los manuales) es ir desarrollando una serie de prototipos que van creciendo y tomando forma hasta tener la aplicación. La gran ventaja es que podemos testear desde los primeros días de desarrollo.

Con GXtest pretendemos que sea posible automatizar las pruebas desde lo antes posible.

Qué problemas pueden ocurrir con esto? los obvios, de que automaticemos pruebas, y al continuar el desarrollo de la aplicación nuestras pruebas se rompan por los propios cambios introducidos al evolucionar el desarrollo.

Ya que GXtest está "atado" o "enganchado" a la KB de Genexus, es posible tener pruebas automatizadas para una versión de la KB y que al momento en que se haga un nuevo deploy en el ambiente de testing, también se actualice la KB que maneja GXtest en sus TestCases, para que estos se ajusten a los cambios ingresados. El objetivo es que esta tarea de "impactar la nueva KB sobre GXtest" sea lo más automática posible, aunque para algunos casos particulares requerirá de la asistencia del usuario.

Ejemplo

rename de objetos referenciados en TestCases

rename de controles referenciados en TestCases

delete de objetos o controles referenciados en TestCases

nuevos objetos o controles, cambios en objetos no utilizados

También entra en juego el buen criterio para la planificación de la automatización de cada prueba. Consideramos que está bueno automatizar e incluir lo antes posible en el set de pruebas de regresión automatizadas una funcionalidad, pero también hay que ver que esté estable enough como para que no me implique tanto trabajo hacer el mantenimiento a ese TestCase.

Esta necesidad de planificación la contamos también desde la experiencia por las pruebas automatizadas que armamos para GXtest en su desarrollo.

Es importante por comenzar al menos por un conjunto simple de Test Cases, pero comenzar temprano! Luego que tenemos la "infraestructura de pruebas" aceitada, es más fácil agregar nuevas pruebas al conjunto de pruebas de regresión. En cambio si esperamos para tener un conjunto más amplio de funcionalidades para automatizar, demoraremos más en obtener los beneficios.

De lo que estamos seguros también es que no consideramos al testing como una fase, o como algo que hay que dejar para el final, ... tal vez eso por la experiencia que nos ha dado trabajar en el CES y la preocupación por la calidad del producto que nos ha inculcado esa "escuela" que tuvimos.

Gracias David por el link a la revista M&T de donde nos inspiramos para este post!

GXtest Avant Premiere - en el GUG

2009-06-16T13:53:00.000-07:00

El próximo sábado 20 de junio a las 11 horas en la Pizzería armenia Nairi (Agraciada 3560 y Buschental) tendremos el agrado de presentar en el primer GUG Montevideo de este año.

El título de la charla es "GXtest Avant Premiere", y ya que se acerca la fecha de su liberación, la idea es mostrar los avances en el desarrollo de GXtest y las funcionalidades que tendrá la primer versión que estará disponible para el próximo evento GeneXus.

Habrán otras charlas muy interesantes las cuales se listan en el blog del Grupo.

Esperamos verlos por ahi.

Qué bueno que vamos de nuevo con los lehmeyunes de Gustavo!