Abstracta Blog

Tests de Performance en GeneXus

2012-01-27T08:14:00.000-08:00

Si alguna vez intentaron hacer pruebas de performance sabrán que no es una tarea que se haga de la noche a la mañana, y generalmente llevan mucho esfuerzo, especialmente para la preparación de las pruebas, donde lo más complejo (especialmente en sistemas desarrollados con GeneXus) es la automatización de los casos de prueba.

Finalmente estamos anunciando la liberación de una nueva funcionalidad de GXtest que permite generar pruebas de performance en tiempo record, más rápido que con cualquier otra herramienta, con las facilidades que brinda GXtest, permitiendonos así simular la realidad a la cual se quiere poner en producción el sistema con buena fidelidad.

En muchas situaciones, tales como cuando nuestro sistema debe estar accesible para muchos usuarios que trabajan simultáneamente sobre el servidor, o si ciertas operaciones deben ser resueltas en determinados tiempos de respuesta, o bajo cierta cantidad de recursos limitada, no hay otra que hacer una prueba de performance. Es la única forma en la que podemos verificar cómo se comportará nuestro sistema, mediante una simulación de la carga con el uso de las herramientas adecuadas.

Los principales motivos por los cuales nos puede interesar evaluar el rendimiento de nuestro sistema son:

Poner en producción un nuevo sistema
Cambiar la tecnología (ej. migrar de Win a Web)
Cambiar el hardware, arquitectura, DBMS o SistemaOperativo de algún componente
Liberar un cambiosignificativo en la aplicación

Los beneficios:

Determinar el hardware mínimo necesario para soportar las necesidades.
Conocer y así controlar:

Tiempos de respuesta,
Consumo de recursos (CPU, Memoria, Disco, red, etc.)
Interrupciones de servicio
Recuperación a fallos

Hasta hoy, para automatizar testing funcional de apliacaciones GeneXus usamos GXtest. Para testing de performance seguíamos teniendo un gran problema al usar las herramientas tradicionales. Dado la forma en la que trabajan las herramientas que permiten realizar este tipo de simulaciones, los scripts (casos de prueba automatizados) quedan muy sensibles a los cambios de la aplicación. Esto es: introduzco un pequeño cambio en el desarrollo o cambio la versión de GeneXus, y los scripts quedan casi inservibles (problemas de mantenimiento de scripts) teniendo que rehacerlos por completo.

GXtest Professional libera una nueva funcionalidad ya probada en varios proyectos con éxito:

GXtest2OpenSTA, que permite a quienes desarrollan con GeneXus usar una herramienta como GXtest para hacer testing de performance.

Permite preparar los scripts de pruebas mucho más rápido y fácil, brindando la facilidad de generar scripts que se alimenten de distintos juegos de datos, validen las respuestas de la aplicación, simulando las acciones del usuario, para que luego GXtest genere los scripts ejecutables en OpenSTA con pedidos http en forma automática.

El top 3 de beneficios:

Reducción de más de un 80% de construcción de los scripts OpenSTA. (para casos complejos mucho más aún)
Permitir ajustar cambios en desarrollo / tunning y volver a regenerar
Reducir drásticamente la complejidad de realizar y entender los scripts, y los diferentes pedidos de la aplicación

Les dejo un video de cómo se generean los scripts y cómo se ejecuta la prueba:

Aquí encontrarán información de para qué y cómo realizar scripts de carga para sistemas GeneXus usando GXtest.

Estamos muy contentos con este gran avance que nos permite resolver necesidades de nuestros clientes en tiempo record, solucionando problemas de performance, ofreciendo un mejor servicio, logrando que puedan liberar nuevos sistemas, nuevas funcionalidades, con mayor calidad, menor riesgo y menores costos.

Transferencia de conocimiento con el testing de regresión

2011-12-21T07:10:00.000-08:00

Quiero dejarles algunos comentarios de la forma en que nos vimos resolviendo dos cosas muy importantes que teníamos para hacer, en una combinación que creo que puede ser repetible en casi cualquier contexto:

Actualizar la información en el issue tracker
Capacitar a un nuevo integrante del equipo en aspectos varios de testing y de GXtest.

Usamos Mantis para gestionar los incidentes. La gran mayoría de los issues los reporté yo (al comienzo era el único tester), parte por clientes y otros usuarios. Por priorizar las pruebas de otros componentes o funcionalidades, muchas veces se deja de lado la verificación de la resolución de los incidentes. El ciclo que tenemos definido para los issues indica que luego que un desarrollador resuelve un incidente lo pasa a resolved y de ahí el que lo reportó lo verifica y puede pasarlo a closed o puede decir que aún no está solucionado. Entonces, teníamos muchos incidentes en estado resolved que estaban a la espera de que se verifiquen por un tester.

Hace poco incorporamos dos personas a nuestro equipo. En particular Leopoldo está más dedicado al testing funcional, y como suele suceder gran parte de su tiempo al comienzo está destinado a capacitarse, no solo en testing sino también en el producto que en este caso es GXtest.

Lo que buscamos fue una forma de que se capacite y a su vez genere valor, sintiendo además que está dedicando sus horas a algo que de frutos. Combinando estas dos cosas ¿qué nos planteamos?: revisar los incidentes en estado resolved y decidir si se podían cerrar o si se debían reabrir o revisar.

Objetivo planteado: 5 por día y verá que puede. La idea era no pasar todo el día revisando incidentes, sino que irlo haciendo en forma paulatina y con cierta constancia.
Resultados: positivos!

Sin buscarlo se superó la cantidad pensada de 5 por día. A medida pasa el tiempo se observa más agilidad e independencia para la revisión de los incidentes.

Se aprende de:

la aplicación y el dominio
de testing (en base a los reportes se pueden observar implícitamente las técnicas utilizadas, las cosas a las que se le pone foco, etc., y también lo efectivo o inefectivo de los reportes)

Otras beneficios obtenidos

se hizo una revisión por pares de los incidentes y de esa forma incluso yo terminé aprendiendo y observando mis errores, de cosas con las que no estaba siendo claro, etc.
se hicieron pruebas de regresión sobre incidentes marcados como resueltos
se prepararon reportes, los cuales nos permitió ver qué información resulta más útil mostrar para entender rápidamente el avance (en esto llegamos más que nada a cantidad de incidentes pendientes, clasificaciones por prioridades, por criticidad y por categorías)

Algunos números:
Comenzamos con 301 issues con estado resolved el 21 de Noviembre, y al 16 de Diciembre nos quedaban 169, reduciendo un 56,41%. Quedan 132 por revisar, (43,59%). De los 169 issues actualizados, 11 pasaron de Resolved a Open o Assigned, representando un 6,5% de los issues resolved actualizados, el resto (93,5%) se cerraron. Esto también muestra una efectividad en la corrección de incidentes (excelente Fabián y Matías!).

Esperemos poder seguir aportando datos desde nuestra experiencia, a medida veamos que ellos puedan ser útiles para alguien más. Genial si tienen ideas para contraponer o compartir.

Aprovechamos para desearles felices fiestas a nuestros lectores y un año nuevo de plena calidad!

Lo que fue el VLCTESTING

2011-11-17T05:31:00.001-08:00

Como les conté, fui al VLCTESTING, celebrado en Valencia.

El evento fue muuuy bueno! Unas 125 personas, mucho más de lo que habían pensado inicialmente los organizadores, en una ubicación muy buena, tanto por las instalaciones como por la ciudad.

La mayoría de las ponencias fueron sobre experiencias concretas en Testing y SQA, donde varias ponencias estuvieron muy interesantes, incluso una de usabilidad. Como hablábamos con Bea, en general muy buen ambiente, con gente interesada por el testing y con ganas de compartir conocimientos. De noche hubo un evento de networking también muy interesante (era en una cervecería, y nos invitaron con cerveza hecha ahí mismo, y con unas pizzas muuy buenas). Por las preguntas planteadas luego de las charlas, y por la gente con la que estuve conversando, adivino que en su gran mayoría eran testers, pero también habían desarrolladores interesados en mejorar sus prácticas en pro de la calidad.

Les dejo algunos links del grupo de testers de Barcelona que organizaron la parte de networking:

También agrego un link a un resumen del evento por si quieren ver de qué se trató cada charla, y aquí hay más aún, e incluso están las fotos del evento.

Un dato que me pasó Maximiliano Mannise (uruguayo, formado en testing en Uruguay, organizador del evento y director del Área de Calidad de Software del Instituto Tecnológico de Informática de Valencia) es que hubo mucha presencia de Uruguay en el evento, en la organización y en el escenario con un 20% de las ponencias. Creo que estamos dejando nuestra marca relacionada a la calidad no sólo a nivel nacional :)

VLCTesting 2011, Valencia, España

2011-11-07T15:27:00.000-08:00

El próximo jueves (10/11/11) se celebrará en Valencia el VLCTesting, organizado por el ITI, tratando temas de Calidad de Software y Testing. Ya hemos participado de muchos encuentros de este estilo en Uruguay, y tengo la curiosidad de ver si en España se vive de una forma similar, con las mismas interrogantes y necesidades, y ver si hay experiencias similares a las que nos enfrentamos en el día a día.

En el programa podrán ver que por parte de la UCLM va Beatriz Pérez, docente de Facultad de Ingeniería también, con la que trabajamos en el CES varios años, exponiendo sobre técnicas de testing combinatorio. Su aporte será desde la academia pero también habrán aportes de empresas, tales como Bull España o eXcentia.

Ya les contaré qué tal.

¿Cómo planificar la automatización de casos de prueba junto al desarrollo?

2011-10-28T11:15:00.000-07:00

En este post la idea es mostrar una posible forma de organizar la automatización, en base al plan de desarrollo, a modo de tener las pruebas automatizadas lo antes posible, sin perder de vista el test manual, y que las funcionalidades a automatizar ya deben estar testeadas.

Esto surgió en base a una pregunta de si tenía sentido automatizar las pruebas antes de que la aplicación esté lista. En nuestro enfoque, por ahora, no es la forma pensada de trabajo. Existen herramientas que plantean "automatizar" las pruebas antes de implementar, como para seguir algo de Test Driven Development. El tema es que esto puede llegar a ser un poco difícil de concebir, creo que aún falta mucho camino en cuanto a tomar conciencia y dedicar recursos para pruebas, y para automatización, como para priorizar este tipo de funcionalidades en GXtest. De todos modos, queremos compartir este approach que nos parece muy bueno.

Veámoslo con un ejemplo, en el que tengo un extracto del plan de desarrollo en el que se trabaja sobre 9 funcionalidades en 3 ciclos.

Lo importante a ver en el ejemplo es cuándo se hace cada tarea para un grupo de funcionalidades. Por ejemplo, sigamos las tareas para las funcionalidades F1, F2 y F3. En el primer ciclo se implementan y diseñan las pruebas. en el segundo ya se contará entonces con esas funcionalidades listas para probar, entonces las probamos, y luego las automatizamos. En paralelo con eso el equipo de desarrollo implementa las funcionalidades F4, F5, y F6, y se diseñan pruebas para ellas. En el siguiente ciclo, ya vamos a contar con las pruebas automatizadas para las F1, F2 y F3, entonces las ejecutamos. A su vez contamos con las pruebas diseñadas para las F4, F5 y F6, entonces las ejecutamos manualmente, y las automatizamos como para tenerlas para los siguientes ciclos. Observen que ya estamos ahorrando tiempo en ejecución de pruebas, y recién estamos en el ciclo 3!

Lo interesante bajo este esquema, es que quién automatiza (si son testers) podrían hacer ellos mismos el testing manual y en ese momento automatizar. Esto tiene como beneficio de que conocen la funcionalidad probándola, y luego al automatizarla les va a ir mejor. Es importante que en este punto al probarla manualmente decidan si la funcionalidad está apta para automatizar o si aún está muy "verde", dejándola para una etapa posterior, luego de las correspondientes correcciones.

Lo importante de este ejemplo es mostrar cómo planificar la implementación y la automatización de las pruebas. Acá no estoy considerando el diseño de la implementación, que tendría que ir un ciclo atrasado con respecto a la implementación. E incluso si quisiéramos seguir un modelo en V esto sería un poco distinto, las pruebas las definiríamos al mismo momento que los requerimientos, así que la parte de diseño directamente la sacaríamos de esta parte que ya sería al estar implementando.

Me gustaría conocer su opinión al respecto, y si tienen para compartir ideas, o formas de trabajo que puedan aportar al resto de la comunidad.

Mantener diseño de Test Cases lo más secuencial posible

2011-10-25T07:48:00.000-07:00

Alguien comentó en el MBTUC algo que me resultó interesante: los casos de prueba deberían ser lineales en el caso que los resultados sean deterministas, y sólo si tienen alguna variabilidad no definida de antemano agregar distintos flujos, pero lo mejor es mantener las cosas simples y secuenciales. Muchas veces los que venimos "del palo" de la programación tendemos a hacer casos de prueba tan genéricos que terminan siendo muy complejos.

En esto estamos bastante de acuerdo, y quiero comentar algunas cosas que hemos visto, como para que tengan en cuenta al momento de diseñar sus casos de prueba.

Si diseño un único caso de prueba que contempla distintas opciones, probablemente sea más difícil de entender, y para eso tenga que analizar qué se está consultando en cada decisión (bifurcación), qué se hace en un flujo u otro, etc., a menos que sea muy cuidadoso y llene el Test Case de comentarios que simplifiquen ese análisis. De todos modos, un test case secuencial con un nombre descriptivo da la pauta de qué es y qué hace.

Por otra parte, si el día de mañana agrego un nuevo caso, ¿dónde lo hago? ¿cómo agrego la bifurcación? ¿cómo manejo los datos asociados? Hacer test case nuevo, secuencial, con un datapool para ese caso, simplifica bastante esa tarea.

¿Que opinan al respecto?

GXtest Complex Flow

GXtest Simple Flow

Camino al Model-based Testing User Conference 2011

2011-10-25T00:18:00.000-07:00

En poco más de una semana dará comienzo este congreso de Testing Basado en Modelos, en Berlín, Alemania, al cual tendré la oportunidad de asistir.

Es la primera vez que se hace, así que no se puede decir que es un congreso que es importante por su historia, pero sí por el contenido del mismo. Pretende ser distinto al resto de los congresos de esta temática, ya que generalmente siempre son congresos académicos, mientras este intenta enfocar los aspectos de aplicación e ingeniería de este tipo de técnicas.

Es organizado por el European Telecommunications Standards Institute (ETSI) y por el Instituto Fraunhofer. El Instituto Fraunhofer es un instituto de investigación alemán que, como dicen en su página, tienen como fin principal orientar su investigación en las necesidades de la gente (the largest application-oriented research organization).

El programa se ve muy interesante. Hay charlas y tutoriales dados por líderes de testing de empresas como Microsoft y Nokia, de de importantes proveedores de herramientas y servicios de testing como ConformiQ y SmartTesting.

Hace unos años, en el Encuentro GeneXus del 2008, presentamos un prototipo de GXtest, y comenzamos la charla contando de qué se trataba el testing basado en modelos, como para luego mostrar cómo GXtest lograba aplicar esa filosofía en el mundo GeneXus, y por qué ese era el mejor enfoque para esta situación. El gurú que teníamos de referencia ya desde ese momento era el amigo Harry Robinson. El mismo estará exponiendo una charla en esta conferencia, y realmente es muy interesante tener la oportunidad de conocerlo y compartir el congreso con él.

Después les contaré qué tal todo.

Model-based Testing User Conference, Berlín - 2011

2011-10-21T04:31:00.000-07:00

Terminó la conferencia de MBT y lo mejor fue ver que en la industria, en grandes empresas principalmente, se está investigando e invirtiendo en estas técnicas de prueba para garantizar gran calidad de sus sistemas y reducir los costos del proceso de pruebas. El congreso fue de un gran nivel tanto en contenido como en organización, en una hermosa ciudad como lo es Berlín.

Las charlas principalmente mostraban herramientas disponibles en el mercado y casos de uso/éxito. Por ejemplo cómo Microsoft prueba Bing o Lync con estas técnicas (con su propia herramienta SpecExplorer), o cómo empresas como SAP, o Alcatel, Ericsson y Nokia, o Carmeq probando software automotriz para VW, Audi, etc. (les recomiendo ver la página que hablan de investigación en un auto que se maneja solo), o la empresa Giesecke & Devrient probando software embebido en un Cash Center (entre tanto, incluye esas máquinas que cuentan billetes a velocidad de 50 por segundo o algo así, detectando si hay falsos), etc. Estos últimos todos usando ConformiQ, modelando con máquinas de estado, implementando ellos mismos el test harness que sirva como capa de adaptación para invocar a sus sistemas, y lograr así que la misma herramienta sirva para todo tipo de interfaces. Tal vez más adelante me extienda en cada tema en distintos posts.

Hablando de autos, tengo que comentar que en Fraunhofer, y en Alemania en general, se investiga mucho en la industria automotriz, y por ende en el software que estos tienen embebido. Me llamó la atención entrar a la sala de conferencias y encontrarme un Ferrari deportivo ahí estacionado, teniendo en la matrícula la inscripción de Fraunhofer.

La charla de Harry Robinson fue más que nada divertida, es un buen orador, y lo presentaron como el pionero en el testing basado en modelos, contando por ejemplo que desde 1993 (creo) viene utilizando estas técnicas e incluso escribió sus primeros artículos y libros al respecto. En su charla contó que MBT no tiene que ser siempre una máquina de estados, sino que puede estar basado en otros modelos e incluso basados en heuristicas, pues algo que es cierto es que el resto de las presentaciones consideraron que el único modelo es una state machine para modelar el comportamiento esperado del sistema.

Otra reflexión que hago es que todos plantean construir un modelo de pruebas completamente independiente del sistema bajo pruebas, lo cual parece que agregara un gran costo en testing. Hoy en día creo que eso es algo que sólo las grandes empresas están haciendo (y muy pocas más por ahora), y según cuentan les da resultados sin grandes inversiones, entonces, deberíamos seguirlos, pero aún falta no se qué para terminar de convencer, o de mostrar que eso realmente funciona y que deberíamos adoptarlo.
Por otra parte, nadie considera seriamente la generación de pruebas a partir del sistema tal como lo hace GXtest Generator (que es nuestra parte de generación de pruebas con un enfoque puramente MBT). Se planteó en un momento la típica discusión de si generar pruebas a partir del sistema que querés probar te aporta, o si te estás haciendo trampa jugando al solitario, pero para eso nosotros ya tenemos una respuesta válida al menos para nuestro contexto, que es que si se encuentra un posible bug, no importa si es error del modelo de pruebas, del modelo de desarrollo, del generador de código o de la Java Virtual Machine, lo importante es detectar cada posible error que pueda llegar al cliente, corregirlo, y seguir buscando más errores.

Al final contaron estadísticas del evento muy interesantes, como que el 85% de los participantes eran de la industria y no de la academia, y también que asistieron alrededor de 200 personas, y de 4 continentes. Yo solito aporté en el 25% de esa última estadística :)
Esta fue la primera vez que se hacía este evento y por el éxito logrado planean desde ya repetirlo el año que viene. Pronto buscarán propuestas para ver dónde hacerlo, y esperemos poder asistir nuevamente pues considero que fue una experiencia muy enriquecedora.

PS: si alguien quiere algo del material que escriba un comentario y les mando

El encuentro vivido de afuera

2011-09-15T05:36:00.000-07:00

Esta es la primera vez que participo del Encuentro a la distancia, y si bien no fue lo mismo, creo que lo aproveché y disfruté bastante. Seguramente este año fue mucho mejor que si me hubiera tocado años anteriores, pues había transmisión en vivo de las principales salas (a pesar que en algunas a veces andaba muy lento), twitter está más movido que nunca (obviamente relacionado al crecimiento de SD que nombró @njodal), y que hay muchas más personas que lo viven de lejos como esta vez me tocó a mí.

Otro tema tal vez es que como no daba charla este año no estaba con el nerviosismo típico esperando a ver cómo sale, y ajustando últimos detalles. O sea, si bien colaboré a la distancia con mis amigos abstracteros, no era yo el que se paraba frente al público este año, y por eso miré más charlas más tranquilo. Lo bueno es que es más fácil moverse de una sala a la otra, lo malo es que no te encontrás amigos y colegas por los pasillos.

Estuvo genial ver el notorio crecimiento de ponencias relacionadas con testing de software. Además de las que presentó Abstracta y el CES, hubieron dos charlas de GXC (generalmente hay una) y a eso le sumamos la de GXunit y el clásico café con testing (ese sólo pude ver fotos y escuchar repercusiones al respecto --no estaría bien que también filmen ese, e incluso que haya un vocero que de vez en cuando plantee alguna cuestión interesante aportada por alguien que sigue por twitter??--).
De estas charlas me gustaron en particular dos cosas (no voy a hablar de las de Abstracta, de eso me gustó todo :P), primero la cantidad de profesionales del testing que vamos a tener gracias a la carrera del CES, excelente! mucha gente capacitada para aportar a la calidad del software que se produzca (principalmente) en Uruguay; y por otro lado GXunit, que me parece que es una idea que viene desde hace mucho y que por fin parece que se logró algo bastante bueno (no digo que los intentos anteriores fueron malos, sino que se dieron otras cosas como la estabilidad actual de la extensibilidad de GeneXus por ejemplo). Es una herramienta que permite al desarrollador automatizar pruebas implementadas en lo que sabe hacer, código GeneXus, integrada al IDE, fácil de usar, potente, y gratis! Espero la comunidad la adopte rápidamente.

El año que viene espero poder estar por ahí compartiendo y viviendo el encuentro otra vez desde cerca.

Por último les dejo links a todas las charlas relacionadas a testing, por si quieren ver los videos o las diapositivas:

Introducción a GXtest. (Fabián Baptista - Abstracta)
Automatizando Test, un año de experiencia con GXtest. (Juan Martín Anollés, Federico Alvarez - Concepto)
GXC Development Framework: Experiencias de testing y resultados obtenidos. (Matías Reina Abstracta, Carolina Torrado - GeneXus Consulting)
Roadmap de GXtest. (Fabián Baptista - Abstracta)
Todo sobre testing y más, en una Carrera. (Mariana Travieso, Mónica Wodzislawski - Centro de Ensayos de Software, Úrsula Bartram, Alejandro Blengio - Artech)
Probar GeneXus code con GeneXus code. (Nicolás Carro, Juan Pablo Goyeni, Marcos Olivera - Facultad de Ingeniería, Universidad de la República)
GXC Development Framework: Test de Aceptación, Do It! (Guillermo Skrilec - GeneXus Consulting)

Se viene el XXI Encuentro GeneXus

2011-09-09T07:07:00.000-07:00

Estamos muy cerca del comienzo, sólo a un fin de semana para le encuentro anual de la comunidad. Cada año estamos con más participación, lo cual nos gusta mucho, y por eso es que invitamos a los que van en especial a las siguientes actividades y exposiciones:

Introducción a GXtest. Lunes de 14.30 a 15hs. en el salón 2C (ballroom C). A cargo de Fabián Baptista, especialmente orientada a los que se quieren iniciar en el uso de la herramienta para automatización de pruebas funcionales para GeneXus. (#GX2405)

Laboratorio de GXtest. Lunes de 15.45 a 16.45hs. en el salón 4P (sala Picasso). A cargo de Leopoldo Flanagan, se verán en práctica las funcionalidades de GXtest. Porque probar ayuda a entender. (#GX2553)

Café con Testing. Martes de 12.15 a 12.45hs en el salón 25TG (Torres García). Estaremos participando junto a colegas del CES, GeneXus Consulting, Artech y K2B, conversando sobre distintas inquietudes del testing. Los invitamos a probar un café :) (#GX2551)

Automatizando Test, un año de experiencia con GXtest. Miércoles de 10.30 a 11hs. en el salón 2C (ballroom C). Por parte de Juan Martín y Federico, colegas de Concepto, escucharemos sus experiencias de uso de GXtest, luego de un año de trabajo en automatizar pruebas a sus sistemas. (#GX2424)

GXC Development Framework: Experiencias de testing y resultados obtenidos. Miércoles de 11 a 11.30hs. en el salón 2C (ballroom C). Matías Reina junto a Carolina Torrado de GeneXus Consulting, estarán hablando de testing de performance en proyectos de GeneXus Consulting, mostrando los resultados obtenidos. (#GX2457)

Roadmap de GXtest. Miércoles de 12.15 a 12.45hs. en el salón 2C (ballroom C). Fabián Baptista comentará sobre las últimas novedades y lo que se viene en GXtest. Hay mucho para contar! (#GX2491)

Relacionado con testing también recomiendo:

Todo sobre testing y más, en una Carrera, para conocer más sobre la carrera de testing del CES. (#GX2425)
Probar GeneXus code con GeneXus code, para conocer sobre los avances de GXunit este año, donde se podrán ver los resultados de un proyecto de grado de Facultad de Ingeniería tutoreado en conjunto por Abstracta y el CES. (#GX2417)
GXC Development Framework: Test de Aceptación, Do It! Guillermo de GeneXus Consulting estará contando la claves para hacer pruebas de aceptación exitosas. (#GX2412)

Para mi imperdibles todas! pero esta vez será la primera que lo miraré por Internet, una pena no estar por ahí para compartir todo esto.

Beneficios del testing automatizado, ¿realidad o ficción?

2011-09-09T04:46:00.000-07:00

Este es el título que le dimos a la charla dada en el pasado TechDay, el cual está basado en un paper de Paul Grossman, publicado por un importante proveedor de la industria del SW y HW. En este post haremos un resumen del contenido de la charla, ya que realmente nos parece importante mostrar los verdaderos beneficios en términos financieros, más que nada para dar más argumentos a alguien que quiere visualizar, o mostrar el valor que tiene este tipo de inversiones (ya que verán al final que no se trata de un gasto, sino en una inversión para ganar no sólo en calidad sino en ahorro de dinero).

¿Costo o inversión? Generalmente se dice que el testing automatizado permite ampliar el cumbrimiento y alcance de las pruebas, reducir costos, poner el foco de las pruebas manuales en lo que realmente interesa, encontrar defectos más temprano, etc., etc., etc., y de esa forma reducir costos y riesgo. Todo esto parece ser siempre la misma basura que plantean los vendedores de herramientas, sin justificación suficiente.

En cierta forma lo pondremos en duda.

El problema es que cuando se quiere "invertir" se analiza generalmente cuánto dinero me voy a ahorrar con cada peso que invierto en esto, para saber si es un costo que tiene la calidad, o una inversión que me ahorrará otros costos asociados a la falta de calidad, que es lo que siempre se dice. Es por esto que tenemos que mostrar estas cosas en números.
En esta charla intentamos analizar un poco más este tipo de planteos que se hacen siempre, como para que tengan criterios mejor fundamentados cuando quieran analizar si automatizar las pruebas funcionales.

Para probar funcionalmente un sistema se ejecutan pruebas diseñadas para ejercitar las funcionalidades probadas. Una vez que las pruebas ejecutan correctamente hay que volver a ejecutar los conjuntos de pruebas cada vez que hay cambios en el sistema, ante cada nueva liberación de una versión. Esto es lo que se conoce como test de regresión. En algunos casos además las mismas pruebas deben ser ejecutadas en distintos ambientes, considerando sistemas operativos, bases de datos, integración con distintos componentes, distintos navegadores, etc. No necesitamos mucho para darnos cuenta de los beneficios prácticos si logramos que esto sea ejecutado por una máquina.

Se requiere cierto esfuerzo para automatizar las pruebas y mantenerlas. Casi todas las herramientas de automatización brindan la posibilidad de "grabar" las pruebas y luego poder ejecutarlas, lo que se conoce como enfoque de record and playback. Esto generalmente sirve para pruebas simples y para aprender a usar la herramienta, pero cuando se quieren hacer pruebas más complejas generalmente es necesario conocer un poco más a fondo la forma en que trabaja la herramienta, manejar juegos de datos de pruebas, administrar los ambientes de prueba, las bases de datos de pruebas, etc. Una vez que tenemos solucionado esto, podemos ejecutar las pruebas tantas veces como queramos con muy poco esfuerzo.

Las mejores aplicaciones para aplicar testing automatizado son entonces las que tienen mucha repetitividad, y las que será necesario ejecutar muchas veces las pruebas (ya sea porque es un producto que tendrá muchas versiones, que se continúe con el mantenimiento haciendo fixes y parches, o porque se debe probar en distintas plataformas).

Si se automatizan las pruebas de un ciclo de desarrollo, para el siguiente ciclo las pruebas automatizadas podrán retestear lo que ya se automatizó con bajo esfuerzo, permitiendo que el equipo de pruebas aumente el tamaño del conjunto de pruebas, aumentando el cubrimiento. Si no fuera así, terminaríamos teniendo ciclos de pruebas más grandes que los ciclos de desarrollo (y cada vez más grandes) u optaríamos por dejar cosas sin probar, con los riesgos que eso implica. Esto es lo que una vez supimos llamarle el problema de la acumulatividad nula extrovertida sistematica (esto fue en la charla del Encuentro Genexus del 2010).

No todo se debe automatizar, y no hay que intentar remplazar el test manual por el automático, pues hay cosas que no se pueden automatizar (más que nada si necesitan verificación visual y determinación por parte del usuario), y en ocasiones es más fácil ejecutar algo manualmente que en forma automática.

¿Qué tanto automatizar? En cada caso será diferente, pero el paper dice que es bueno intentar comenzar con un objetivo del 10 o 15% de las pruebas de regresión, y a medida se va avanzando se podría llegar hasta un 60% aproximadamente.

Tampoco es la idea reducir el personal dedicado a testing. Pues el test manual aún se necesita, y las pruebas automatizadas requieren cierto mantenimiento, además de las que se sigan automatizando. Entonces, ¿dónde están los beneficios financieros? Lo más importante es que al automatizar podemos expandir dramáticamente el alcance de las pruebas con el mismo costo (con la misma inversión), y eso es algo que financieramente da ventajas claras: conservar los costos y aumentar el beneficio.

Veamos con un ejemplo hipotético que sea más entendible por alguien que decide sobre las finanzas de una empresa:

Un tester manual ejecuta pruebas 8 horas por día, y se va a su casa. En ese momento el testing se detiene. Con el test automatizado se puede estar ejecutando pruebas 16 horas más por día (en el mejor caso claro...), bajo el mismo costo, lo cual reduce el costo de las horas de test. El paper plantea que un tester en promedio cuesta 50u$s la hora (ojalá en Uruguay fuera igual!) y si es senior cuesta 75u$s (divino!). Siendo así serían 400u$s o 600u$s respectivamente por día, pero en el segundo caso serían 16 horas más que en el primero (esto es porque considera que el senior es el que sabe automatizar, el otro sólo se considera para test manual). Además los test automatizados corren más rápido que los test manuales, en promedio digamos que 5 veces más rápido (generalmente es más, pero no exageremos). Si hablamos de un equipo de 10 personas, 5 senior y 5 para test manual, tenemos un costo mensual de 105.000u$s (168hs por mes, o sea 8 horas por 21 días, 42.000 en test manual y 63.000 de testers senior). Esto en principio nos da un total de 1.350 horas a un costo de 78u$s la hora (acá se está considerando que de las 168 horas mensuales de trabajo, se estará ejecutando 135, lo cual podría suponerse como razonable si se considera cualquier overhead como enfermedad, vacaciones, capacitación, etc.). Si ponemos a 3 de los senior a automatizar, el costo seguirá siendo el mismo pero tendríamos 16hs x 3 ing x 21 días x 5 veces más test por hora, lo que nos da un agregado de 5.040 horas mensuales equivalentes a horas de test manual. Si consideramos el resto del equipo haciendo pruebas manuales (7 x 135) son 945 horas más, lo que da en total 5.985hs de test con un costo de 17,5u$s la hora (105.000u$s / 5.985 horas). Esto es un beneficio expresado en términos financieros, que se entiende fácilmente. Pasamos de pagar la hora de test de 78u$s a 17,5u$s, o visto de otro modo, aumentamos las horas de prueba de 1.350 a 5.985 bajo el mismo costo.

Ahora, esto nos muestra claramente que hay mejoras en cuanto a las horas de ejecución de pruebas, pero seguramente nos agregue más costo pues encontraremos más errores!!!! ¿Queremos eso?? Claro que SÍ, y veremos ahora cómo encontrar más errores nos ahorra costos a pesar que nos da más trabajo (es algo obvio, pero hagamos más cuentas para visualizarlo mejor).

Es conocida en ingeniería de software la gráfica que muestra el costo de corregir un defecto detectado según en la etapa que se haya encontrado (desarrollo, integración, beta testing, producción). Se muestra un estudio de cuántas horas en promedio cuesta corregir un defecto según la etapa, y considerando costo por hora, cuánto cuesta en dólares. Esto no está considerando siquiera los costos ocultos que hay como la pérdida de imagen, confianza, e incluso el desgaste del equipo.

Esta tabla está hecha en base a un estudio hecho con empresas de desarrollo de software de intercambio financiero electrónico (Planning Report 02-3, "The Economic Impacts of Inadequate Infrastructure for Software Testing," Prepared by RTI for National Institute of Standards and Technology, May 2002, p 7-12.). Muestra el costo en horas de reparar un bug según la fase en la que se encuentra. Luego se aplicó como para visualizar en dinero un costo por hora de 75u$s.

Lo que se ve claramente de esto es algo ya muy conocido, que es que cuanto antes se encuentren los bugs mejor! Y como vamos a tener testers que trabajan 24hs al día, ejecutando más rápido, es más probable que se encuentren más errores antes de pasar las versiones a betatesting o a producción. Es difícil estimar cuántos, pero por cada bug que se encuentre más temprano se ganará al menos 200u$s…. nada mal!!! Esto lo pueden ajustar al precio que les cuesta la hora de sus desarrolladores, y seguirá valiendo la pena.

En estos números se llega a la conclusión de cuánto cuesta un defecto encontrado en cada una de las distintas etapas.

Pregunta al margen: ¿están llevando registro de qué incidentes, y qué complejidad y prioridad cada uno, encuentran en cada fase? Si aún no lo están haciendo, les aconsejo que comiencen a utilizar algún sistema de gestión de incidentes como Mantis Bug Tracker o cualquiera similar, que son gratuitos, muy buenos, y dan la posibilidad de tener esta información en todo momento y hacer un correcto seguimiento de cada asunto.

También se plantea que la automatización permite encontrar errores que no serían fáciles de encontrar manualmente. Por ejemplo errores de memoria que se dan luego de ejecutar muchas veces una funcionalidad, y ni que hablar si nos referimos a pruebas de concurrencia o performance.
Hay muchas cosas que sólo un tester manual puede ver, y otras que tal vez es más probable que las vea una prueba automatizada. Por ejemplo si queremos verificar que cada elemento pedido retorne un código de respuesta sin error (en el caso de http sería que no devuelva ningún 404 o 500 por ejemplo), o si queremos ver que todas las URL están configuradas con https, eso se puede programar y automatizar para que en todas las pruebas se verifique, y en cambio un tester manual tal vez no le presta atención en cada ocasión, dejando pasar por alto en alguna oportunidad por algún despiste.

A modo de resumen podemos decir que hay dos cosas a las que da valor el test automatizado:

Business value
IT value

Da valor al negocio mejorando la calidad, evitando problemas de operativa, pérdida de imagen de clientes, e incluso evitando problemas legales, y mejora el trabajo del grupo de IT ya que le simplifica las tareas rutinarias, permitiendo que con el mismo costo hagan mucho más y mejor.

TechDay 2

2011-08-23T06:43:00.000-07:00

Este año tenemos la oportunidad de participar del TechDay que se realizará en Zona América el 30 y 31 de agosto. Esperemos puedan acompañarnos.

http://www.zonamerica.com/techday

Estaremos dando una charla mostrando los beneficios financieros que se pueden obtener con la automatización de pruebas, intentando desmitificar el tema.

Efficient Regression Tests for Database Applications

2011-07-28T06:19:00.000-07:00

Desde el abstract de este trabajo se plantea algo que es muy cierto, no hay casi investigación en cuanto a pruebas de regresión en sistemas que utilicen bases de datos, el cual plantea problemáticas particulares, para nada triviales.

En este caso el paper aborda un problema que hemos tenido que enfrentar varias veces, y sobre el cual nos han preguntado más de una vez: ¿cómo manejar los casos de prueba y la base de datos?

Para explicar un poco mejor la problemática: siempre se dice que los test deben ser independientes, y deberían ser diseñados de forma tal que puedan correr en cualquier orden. Esto es válido para aplicaciones state-less, pero en el caso de aplicaciones con bases de datos, esto no es nada fácil, generalmente al ejecutar un caso de prueba se modifica el estado de la base de datos, perturbando el estado inicial sobre el que trabajarán el resto de los casos de prueba que ejecutarán luego.

Primero veamos unas definiciones, y luego discutamos la propuesta que plantea.

Test Database (D): usan esta nomenclatura para referirse al estado de la aplicación antes de comenzar el caso de prueba.

Reset (R): operación que nos permite recuperar el estado inicial de la base de datos, lo cual sería hacer un restore de un backup previo. Esto es necesario para poder ejecutar los tests desde un mismo estado inicial, y por eso la necesidad de hacer un backup de un estado inicial conocido. Un problema con esto es que es una operación de cómputo muy costosa (del orden de minutos a horas, de acuerdo al tamaño de la base de datos).

Test Run (T): ejecución de un test.

False Negative: un test run que a pesar de que el sistema bajo pruebas ejecuta correctamente, el test nos dice que hay un error. Esto agrega mucho costo pues el tester ante el resultado buscará (sin sentido) dónde está el bug.

False Positive: un test run que no muestra un fallo a pesar de que la aplicación tiene un bug. Tanto esto como el falso negativo pueden darse por un estado inicial incorrecto de la base de datos.

Entonces, el problema es poder programar los Test Runs y los Resets de forma eficiente y minimizando los falsos positivos y negativos.

Se plantean distintas estrategias, y comienza explicando la más básica, que consiste en reiniciar el estado de la base luego de ejecutar cada test, como para que el estado inicial de los test sea siempre igual.

R.T1.R.T2.R.T3........R.Tn

Obviamente, esta es la opción más costosa. De aquí que se plantea analizar qué casos de prueba afectan el resultado de otros, y de esa forma ir modificando el orden de ejecución y minimizar la cantidad de Reset que se apliquen. Para esto es que construyeron un prototipo de una herramienta, que les permitió decidir qué algoritmo era el más apropiado para su objetivo.

Nosotros a esto también le hemos encontrado otras dos soluciones.

Debido al conocimiento del tester sobre el negocio de la aplicación, podemos implementar una estrategia similar a uno de los métodos que plantean los autores (pero manual). La misma implica agrupar los tests en suites en los que estén ordenados adecuadamente.

Seguramente si un test falla, hará que fallen el resto pues estos tienen como precondición que los test cases previos hayan ejecutado correctamente. Esto tiene como ventaja la posibilidad de probar ciclos funcionales completos, pero como contrapartida, si un test falla, entonces falla toda la suite, y de esa forma quedarán algunas funcionalidades sin probar hasta que no se solucionen los problemas de los tests anteriores.

Esto también puede ser visto como una ventaja, ya que se está notificando de que no se va a poder ejecutar esa funcionalidad, pues una funcionalidad previa no está funcionando. Lo que hay que intentar tener cuidado en este caso, es de hacer que una suite no afecte a otras, o sea, que trabajen sobre distintos juegos de datos.

Otra opción es minimizar el costo de las operaciones de Reset. En lugar de utilizar un restore de un backup se podrían tener operaciones, o procedimientos, sqls, etc, que sean capaces de borrar el contenido de una tabla, o de volver a copiar el contenido inicial, etc. Incluso podría ser un caso de prueba automatizado que borre instancias de una entidad luego que el caso de prueba previo las crea.

¿Alguna vez se enfrentaron a un problema similar?

¿Cómo han intentado resolverlo?

¿La calidad está siendo un problema?

2011-07-14T08:54:00.000-07:00

Leyendo un paper llamado "Surviving the Top 10 Challenges of Software Test Automation" de Randall W. Rice, me encontré una frase que me gustó la cual dice

The cost of a single defect in most organizations can offset the price of one or more tool licenses.

O sea, que el costo de un defecto en la mayoría de las organizaciones compensa el costo de una o más licencias de herramientas. Esto a modo de dar hincapié en la importancia de automatizar las pruebas, el por qué valen la pena, aunque creo que está basado en una creencia y no en un estudio, pero también creo que tenga grandes chances de ser próximo a la realidad.

El artículo lo pueden leer aquí, pero más allá de los puntos específicos que trata, lo que me interesa es el enfoque de intentar analizar cuáles son las fallas que se pueden dar al intentar automatizar las pruebas de un sistema, y atacar cada una buscando cómo lograrlo. Me hizo acordar un poco a la charla que dimos en el pasado encuentro GeneXus. Destaco a continuación solo algunos puntos del artículo.

Entre otras cosas menciona cosas que siempre hemos dicho, tal como que automatizar algo que es caótico, sin organización suficiente, lo único que logra es hacer que ese caos sea más veloz (If you do not know which tests are the most important and which tests are the most applicable for automation, the tool will only help perform a bad test faster). Esto además lo muestra con un ejemplo muy práctico, sobre cómo construir bibliotecas de madera. Para esto una de las cosas a hacer es cortar madera, y como estaba cansado de hacerlo a mano (con una sierra de mano) y eso le lleva mucho tiempo, va con un vendedor y este le convence de comprar una sierra eléctrica. Ahora, sin conocimientos en carpintería lo único que logra con la sierra eléctrica es cometer errores más rápido!

Recomienda también tener un experto en "la herramienta" dentro de la empresa, donde "la herramienta" podría ser cualquiera de las que se esté utilizando para automatizar o dar soporte a cualquiera de las actividades de testing, que no tiene por qué ser una sola. Esto con el objetivo de tener un referente, alguien que administre la plataforma, y se encargue de hacer las cosas lo mejor posible, y transmitir al resto del equipo estas oportunidades de mejora.

Como conclusión del artículo destaco la necesidad de analizar si la falta de calidad en nuestras entregas, en nuestras liberaciones de nuestros desarrollos, está siendo un problema, algo que nos agrega costos (en ocasiones no hace falta analizar mucho, "salta a la vista"). En ese caso, ¿por qué no intentamos hacer algo para cambiarlo? Esto podría ser considerar herramientas, ya sea para automatizar la ejecución de pruebas, así como también para gestionar incidentes, gestionar requerimientos y sus pruebas (manuales o automatizadas), etc., aprendiendo como usarlas, e institucionalizando las buenas prácticas. Tal vez esto también se logre planificando mejor nuestros esfuerzos (no sólo con nuevas herramientas), pero seguro que este tipo de análisis, estas preguntas, las deberíamos hacer de vez en cuando.

Generación automática de datos de prueba

2011-06-06T05:11:00.000-07:00

Me vine hace 4 meses a España (a la UCLM en Ciudad Real) a hacer un doctorado en informática, especializándome en testing, con lo cual espero poder contribuir a las metas que tenemos.

En el primer año la idea es hacer los cursos de máster, y avanzar en lo que será la tesis doctoral. En este post les quiero compartir la idea inicial sobre la que voy a estar trabajando. Vale aclarar para comenzar que el objetivo principal era investigar en un tema que combine dos cosas muy importantes: que esté dentro del área de investigación del grupo al que me incorporé, y que sea algo que tenga aplicación real, práctica, que sea útil especialmente en mejorar la forma en que hacemos testing de aplicaciones en Uruguay, y si había chance de yapa, que el caso de estudio esté aplicado o vinculado de alguna forma a GeneXus, GXtest o GXunit.

Viéndolo en forma simplificada (o abstracta), los grandes rasgos a desarrollar (prototipando) de un sistema de información son:

la estructura de datos
las reglas de negocio (validaciones de datos, restricciones, etc.)
los procedimientos que procesan estos datos y las pantallas que los muestran

¿Cómo se prueba esto?

Se genera la aplicación, se instala (con los entornos modernos esto es apretar F5)
Se accede a la aplicación y se cargan datos para probar manualmente que lo que uno programó se esté verificando y funcionando (estructura y lógica)

Cargar estos datos manualmente puede ser bastante tedioso y error prone (como se suele decir para todas las tareas aburridas), y si las reglas implementadas son complejas o tienen muchas condiciones, seguramente no se consideren todos los casos importantes y queden así sin verificar. Lo mismo con los procedimientos, seguramente no se prueben con suficiente cobertura, verificando las distintas condiciones, y en ocasiones eso puede ser por el tiempo que llevaría cargar datos a mano para disparar las condiciones adecuadas para que se ejecute determinada regla. Incluso queda generalmente sin probar cosas tan simples como ver que el tipo de input utilizado en la pantalla sea el apropiado para el tipo de datos usado a nivel de la base de datos (si es un string que sea del largo apropiado, pues se pueden generar excepciones no controladas o pérdida de información en caso que se pueda ingresar un string más largo del que se puede almacenar).

Propuesta

Facilitar la generación de datos de prueba tomando información del modelo de desarrollo en tres niveles

Estructura de datos y pantallas
Reglas de negocio
Procedimientos

Los datos deben generarse para dos cosas, para poblar la base y para los datapools a utilizar en los test cases (ya sean a ejecutar automáticamente o en forma manual).

¿Cómo?

De las estructuras, con la metadata, generar valores límite para las clases de equivalencia que se puedan definir sobre los variables. Técnicas de combinación de valores. Todo automático a partir del modelo de desarrollo.
De las reglas, generar valores límite para las condiciones. Técnicas de combinación de valores. Todo automático a partir del modelo de desarrollo.
De los procedimientos, aplicar técnicas de caja blanca, modelar manualmente o generar automáticamente máquinas de estado que representen la lógica, aplicar técnicas de MBT (model-based testing). Técnicas de combinación de valores a partir de operaciones entre valores. Todo automático a partir del modelo de desarrollo, opcionalmente agregar modelos específicos para la prueba.

Ejemplos:

Estructura de datos: Si definimos un atributo tipo string de largo 10, en el datapool voy a poner valores de largo nulo, largo 9, 10, 11, 200, para ver qué pasa en el alta o modificación del dato que estoy verificando.
Reglas de negocio: Si indico que un número no puede ser menor que cero, entonces probaré con valores positivos, negativos, con el 0, etc. De esta forma verificar que las reglas se están verificando tal como es deseable.
Procedimientos : Si el código de un procedimiento realiza una evaluación de una variable, yendo por un flujo si es positiva y por otro si es menor o igual a 0, entonces se podrían definir valores de prueba que hagan que esas condiciones sean evaluadas a true y a false, incluso considerando los valores límites que siempre son situaciones típicas de error. Considerando otras situaciones típicas de error se podrían generar pruebas para para evitarlas. Por ejemplo, si dos valores aparecen sumados y asignados a otra variable, sería interesante considerar una prueba donde esos valores sean los máximos soportados por el tipo de datos, como para ver si no se produce un overflow o algo similar.

El objetivo más interesante a cumplir es que uno si programa algo (independiente de que sea en GeneXus) define estructuras de datos y procedimientos sobre esto. Entonces para probar una funcionalidad tiene que generar datos de prueba en forma manual, con código o por la interfaz de la aplicación, e incluso hay que pensar en las distintas situaciones que se intentan contemplar y ver de que al ejecutar se cumple lo que uno quería hacer. Lo que se facilita con esto es que al programar y armar las estructuras de datos, se llenarían datos automáticamente que te permiten probar fácilmente los casos interesantes en base a lo que programaste, en base a las estructuras, a las reglas de negocio, y en base a los procedimientos.

En el caso de GeneXus, podría pensarse no sólo en generar datos sino generar pruebas automáticas que usen estos datos, visto que ya logramos con GXtest Generator generar pruebas automáticamente a partir de la información disponible en la KB (actualmente para GXtest, a futuro tal vez también para GXunit). En principio con probar el CRUD de las entidades ya es algo que agrega valor. Luego (nivel tres) probar los procedimientos. No se si esto se puede extender fácilmente para probar un ciclo funcional completo, pero ya se verá al ir avanzando.

Cualquier aporte o sugerencia será bienvenida, pues como dije al comienzo, el objetivo de esto es sacar algo que nos sirva.

Testing Day 2011

2011-05-25T02:10:00.001-07:00

Ayer jueves 26 de mayo de 2011 se celebró en el KDC del LATU el Testing Day 2011.
Estamos muy contentos de haber participado y compartido con la comunidad de testing de Uruguay.

Más info en el grupo Linked-in de Centro de Excelencia en Testing.

Yo acá a la distancia me quedé con ganas de asistir, espero que por ahí lo hayan podido aprovechar! Es una alegría ver lo que fue la Agenda del Evento ya que estuvo llena de excelentes propuestas, todas alrededor de este tema que a nosotros tanto nos apasiona. Me interesaron muchas las charlas, en particular las del CES y el anuncio sobre la carrera de testing. La mesa redonda me dijeron que estuvo muy buena. Otra charla que me resultó muy interesante fue la que planteó Pragma, sobre la cual leí hace poco en la revista InfoTesting que aprovecho a compartir. Es una iniciativa argentina donde se pretende difundir material de testing en castellano.

Cómo crece la comunidad de testing!

BrokenTest pattern para refrescar la memoria

2011-05-05T05:50:00.000-07:00

Dicen que si estamos trabajando en automatizar pruebas, una buena práctica para volver el día de mañana y recordar más fácil en qué habíamos quedado, es dejar un test que falle. Esto nos hará pensar el por qué falla, qué estaba intentando probar, y así recordar el resto.

Puede ser útil incluso para el programador el dejar en su máquina código que no compila, e incluso para cuando se va a almorzar.

http://c2.com/cgi/wiki?BrokenTest

Knowledge Management en Testing (parte 4)

2011-03-25T06:36:00.000-07:00

Como para terminar con esta serie me queda comentarles sobre una metodología desarrollada en un doctorado acá en la UCLM para mejorar la gestión del conocimiento de una empresa. Se las cuento en forma resumida, pero ya adaptada a lo que sería lo que nos interesa transmitirles, enfocada a testing y a GeneXus.

Lo primero consistía en identificar las fuentes de conocimiento disponibles y categorizarlas:

Documentación

De sistema, técnica, especificaciones
Casos de prueba
Metodologías

Sistema o producto

Código fuente / KB
Base de datos (incluyendo datos de producción, o datos de prueba)
El sistema ejecutando

Personas

Desarrolladores
Testers
Clientes

Herramientas de apoyo

Wikis
Issue trackers
las que mencionamos en el post anterior

Luego pasaríamos a identificar cuáles son los flujos de conocimiento que se dan en la organización, de qué manera las fuentes interactúan en los distintos procesos y actividades. Incluso plantean una forma de extender el modelado de procesos (con SPEM) como para poder representar esto.

Una vez que tenemos claro el esquema la idea es identificar fallos en el flujo de conocimiento, y para esto presentan una checklist de situaciones a revisar para evitar

Hubs: punto que llegan muchos flujos (congestión, cuello de botella)
Black holes: proceso que no origina flujos (nunca es consultado)
Springs: se originan flujos pero no entra ninguno (el problema es que no recibe feedback)
Missing links: no hay flujo, o no funciona correctamente

Este es un resumen muuuy breve de todo lo que plantea la metodología, pero creo que al menos estos puntos que puse aquí pueden ser puestos en la práctica a bajo costo, y pueden hacernos mejorar la forma en la que gestionamos lo más importante que tenemos, el conocimiento de nuestra empresa.

Knowledge Management en Testing (parte 3)

2011-03-25T06:34:00.000-07:00

Hay varias herramientas (gratuitas y pagas) para ayudarnos con la gestión del conocimiento, específicamente en lo que refiere a testing. En este post quiero compartir algunas que me resultaron interesantes, y espero les puedan ser útiles:

CMap Tools para mapas conceptuales, dibujar modelos que nos puedan servir para expresar ideas.
Mantis Bug Tracker para gestionar incidentes
Sharepoint (de Microsoft), Mindtouch o Alfresco (opción open) para gestión de documentos, wikis, portal corporativo, etc.
Mediawiki / GXwiki - para generar documentación fácil de acceder, mantener y versionar.
GXtest para gestionar las pruebas y sus resultados.
Google Desktop - Buscar contenido dentro de un PC. De aquí surge una duda ¿Cómo resolver encontrar contenido cuando los archivos estan distrbuídos en las distintas máquinas? ¿existirán herramientas del estilo Google Desktop para máquinas remotas que quieran compartir sus documentos? Sería como una herramienta P2P pero capaz de leer e indexar el contenido de los archivos y no sólo los nombres.
Hay herramientas que si se las "engancha" al servidor de mails, son capaces de identificar expertos. O sea, leen el mail, y van asociando conceptos a los usuarios, de acuerdo a qué tanto hablan de ello. Por ejemplo, si se repite mucho "data provider", en cadenas de conversación con una persona, entonces es posible realizar la búsqueda de expertos en el tema "data provider" y aparecerá esta persona. Incluso podrían vincularse temas relacionados a partir del análisis que estas herramientas logran hacer sobre los emails. Me resulta un poco delicado el brindar acceso para análisis sobre el email de los empleados, pues da lugar a que luego el jefe se le ocurra buscar al experto de "sábado a la noche" o "fútbol" y vea la cantidad de emails que nombran este tema :)
EPF Composer - para documentar procesos siguiendo el estándar SPEM y publicándolo en una web, fácil de compartir y mantener, pudiendo así captar y difundir las metodologías y procesos utilizados en la organización. El escenario ideal en este tipo de cosas es que luego haya una herramienta capaz de tomar la especificación del proceso como para "ejecutarla". O sea, que administre el workflow de trabajo, gestione las entradas y salidas, notifique a los usuarios, etc. En este sentido (pero bajo un proceso definido) se está trabajando con XPM, el cual apoya la gestión del conocimiento del desarrollo con GeneXus, y a futuro gestionará incluso la de las pruebas en forma integrada con GXtest.

En este enlace http://sites.google.com/site/toolsgsd/ hay un listado de herramientas (hecho en el Grupo Alarcos, de la UCLM) para el desarrollo global, y entre tantas se listan herramientas que apoyan la gestión de conocimiento en distintas áreas.

En el próximo y último artículo les contaré de una metodología desarrollada en un proyecto de doctorado para detectar problemas y mejorar la gestión del conocimiento en una empresa.

Knowledge Management en Testing (parte 2)

2011-03-24T15:17:00.000-07:00

Continuando con la línea del post anterior, queríamos compartir algunas ideas más sobre KM (gestión del conocimiento), específicamente aplicado al área de las pruebas de software. En particular, algunas técnicas para mejorar los distintos pasos de la gestión del conocimiento (recordar que eran creación, captura, organización, acceso y uso):

CREACIÓN

Lluvia de ideas (Brainstorming): ¿Cómo probamos una determinada funcionalidad? ¿cómo organizamos las pruebas? Hay muchas cuestiones, muchos nuevos desafíos que tal vez pueda "generar conocimiento" a partir de reuniones de equipo en donde se expongan todas las ideas que surjan en una lluvia de ideas (o tormenta de ideas como estamos acostumbrados a llamarle nosotros).

Comunidades de práctica: expertos en un área (tecnología, negocio, etc.) exponiendo información sobre determinado tema, lo cual podría ser sobre el dominio de la aplicación bajo pruebas, técnicas de diseño, herramientas de apoyo, etc.

CAPTURA / ORGANIZACIÓN / ACCESO

Mapas conceptuales: fáciles de hacer, permiten compartir y entender ideas en forma muy fácil (usando por ejemplo CMaps Tools).

Mini artículos: contando experiencias, problemas resueltos (se puede llevar a cabo en una wiki o foro por ejemplo).

Repositorio de conocimiento: archivos y cualquier tipo de material, ordenado y categorizado.

Foros de discusión internos: a modo de poder consultar luego lo discutido, y que no quede en chats o emails que no son accesibles por el resto de la organización.

Páginas amarillas: la idea es documentar quién sabe de qué cosa. Esto tal vez aplique más que nada a organizaciones muy grandes, en las PyMEs digamos que nos conocemos todos.

Issue tracker: esto es de los puntos más importantes a gestionar con respecto a las pruebas. Saber qué problemas hay detectados, resueltos, resueltos cuándo y por quién, etc. Si puede estar integrado con el SVN y otras herramientas que manejan información sobre el código, y más cosas, mucho mejor.

¿Conocen o usan alguna herramienta para ayudar en estas tareas?

Foto: Frosted Fantasies

Leer más: Knowledge Management en Testing (parte 3)

Knowledge Management en el Testing (parte 1)

2011-03-21T07:31:00.000-07:00

Algo que no puedo evitar al estar estudiando cualquier tema, es vincularlo inmediatamente con el mundo GeneXus, y obviamente todo lo posible con GXtest, con la forma en la que trabajamos nosotros o nuestros colegas. En este post en particular les quiero dejar algunos apuntes de un tema muy interesante que es el de gestión del conocimiento, pero en particular aplicado al entorno del testing, y en algunas cosas en particular a las empresas que trabajan con GeneXus.

De las definiciones dadas las que más me gustó fue: Conjunto de estrategias y procesos para identificar, capturar y aprovechar el conocimiento para ayudar a la corporación a ser más competitiva (American Productivity and Quality Center).

Se pueden distinguir dos "tipos" de conocimiento:

Conocimiento tácito: todo conocimiento que está en las personas
Conocimiento explícito: conocimiento que está expresado en documentos, código, etc.

Ahora, ¿por qué es importante gestionar el conocimiento?

Rotación del personal (pérdida de expertos). Esto es algo que se da cada vez más en la industria del software.
Cambios de tecnologías. Por más que con GeneXus esto se reduce muchísimo, tenemos que estar atentos a las nuevas tendencias y entender cómo funcionan y cómo funcionar con ellas.
Necesidades de contacto más estrechas con los clientes.
Necesidad de reducir tiempos de respuesta. Es inaceptable que por falta de información, o por una mala gestión de la misma nuestros tiempos de reacción sean malos.

Entonces concluimos que esto nos ayuda a:

Mejorar calidad
Minimizar costos

La Gestión del conocimiento sigue los siguientes pasos:

Creación
Captura
Organización
Acceso
Uso

Es necesario "aceitar" cada uno de ellos para que todo funcione correctamente. Es necesario compartir el conocimiento, hacer que fluya. Generar conocimiento, tanto explícito como tácito (o sea, no es suficiente con documentar cosas, sino también que hay que hacer que el personal adquiera conocimiento, tanto de fuentes internas como externas).

Tengo más apuntes para compartir pero no quería agobiar con todo junto, por lo que por ahora con esto les dejamos la pregunta: ¿Gestionan el conocimiento generado en el testing? ¿Cómo?

Leer más: Knowledge Management en Testing (parte 2)

Encuentro GeneXus España 2011

2011-02-16T01:05:00.000-08:00

Aprovechando que estoy por España, vamos a tener participación en el Encuentro a celebrarse el 15 de marzo, en Logroño (La Rioja, España), impartiendo un taller de GXtest, donde mostraremos el producto funcionando.

Pueden ver información del encuentro por aquí.

Como es de esperar en todo encuentro GeneXus, se abordarán los temas de punta en tecnologías, así como también las últimas novedades de GeneXus, y temas no tan técnicos de interés, teniendo la oportunidad de compartir experiencias con la comunidad que viene creciendo como en todos lados.

GXtest Generator: Generador automático de casos de prueba ....

2011-02-11T08:12:00.000-08:00

¿Qué tal si a partir de una transacción se generan casos de prueba automáticamente? ¿Qué tal si estos casos de prueba se pueden ejecutar automáticamente con GXtest, o desde el propio IDE de GeneXus?

Hace un tiempo decidimos dejar abierta la posibilidad para que se pueda con herramientas externas generar casos de prueba que luego puedan ser visualizados, modificados y ejecutados desde GXtest.

Por junio del 2009 planteamos algunos post sobre interoperabilidad con GXtest y por abril del 2010 estuvimos conversando en el GUG sobre como se podría utilizar la información de la KB para generar casos de prueba.

Hace unos meses desde GeneXus Japón, tras comenzar a utilizar GXtest decidieron apostar a la generación automática de casos de prueba para mejorar la productividad en testing y ayudar en la calidad de sus aplicaciones. En esta tarea se embarcó Luciano y Yokoi, que desarrollaron una herramienta muy interesante que creemos va a marcar un hito muy importante en el testing de aplicaciones GeneXus, esta herramienta la denominaron GXtest Generator.

GXtest Generator permite crear casos de prueba a partir de una transacción y si dicha transacción tiene el WorkWith aplicado entonces también genera casos que utilizan los distintos objetos creados en dicho pattern. Estos casos de prueba no solo realizan las acciones más comunes sobre la transacción y sobre los objetos generados, sino que también se pueden alimentar con datos que ingrese el usuario para poder crear una variedad importante de casos de prueba. A su vez, estos casos de prueba son una unidad fundamental para componer luego nuevos casos de prueba más complejos.

Para explicarles mejor como funciona, Luciano hizo un video sencillo que lo muestra en acción. También pueden encontrar la documentación en la wiki de Abstracta.

Este año queremos potenciar el trabajo que han hecho en Japón. Queremos que se puedan ejecutar estos casos de prueba generados directamente en el IDE de GeneXus y que se puedan ver los resultados ahí mismo. El objetivo es sacarle más jugo de manera más rápida. Imaginen que tengan la opción de apretar F5, se genere la aplicación, se generen las pruebas, y al abrir el Browser con la aplicación se comiencen a ejecutar las pruebas generadas automáticamente.

También queremos agregarle más cosas como generar datos en base al tipo de dato, permitir customizar más los casos de prueba generados, etc.

Una de las cosas más importantes de GXtest Generator es que sus creadores han decidido dejarla libre para la comunidad, por lo tanto todo aquel que quiera jugar o extenderlo puede bajar los fuentes desde assembla, o el pattern pronto para utilizar desde GeneXus Marketplace.

Para ejecutar los casos de prueba se pueden bajar una versión trial de GXtest.

Queremos agradecer a todo GeneXus Japón, y en especial a Luciano y Yokoi.

Creemos que esta herramienta es útil en varios contextos y que va a ser la primera de varias herramientas que generen casos de prueba volviendo el testing en aplicaciones GeneXus cada vez más productivo, siendo este también un diferencial importante para quienes trabajen en esta plataforma.

Buenas prácticas de automatización con GXtest

2011-02-01T04:14:00.001-08:00

Hace poco terminamos un proyecto inicial (unas 70 pruebas) de automatización de pruebas de XPM.
XPM es un herramienta muy completa para gerenciamiento de proyectos y trabajo en equipo.
El proyecto fue exitoso ya que logramos cumplir con todos los objetivos planteados inicialmente.

Durante el transcurso del mismo utilizamos varias prácticas que, si bien las hemos mencionado y las recomendamos a nuestros clientes, nunca las habíamos integrado en un artículo de buenas prácticas. Son temas sencillos pero que a la larga o a la corta hacen una gran diferencia.

Nomenclatura
Es importante definir una nomenclatura de casos de prueba y carpetas. Esta práctica si bien es simple redunda en muchos beneficios. Una recomendación para los nombres de los casos de prueba es distinguir aquellos que son pensados como componentes de otros casos de prueba de que son pensados como ciclos que incluyen los componentes. A los casos de prueba integradores (ciclos) se los puede nombrar con Ciclo
Por otro lado es útil definir una estructura de carpetas que permita separar los casos de prueba generales (típicamente login, acceso a los menúes, etc) de los casos de prueba de los distintos módulos.
Muchas veces también surgen casos de prueba temporales a los mismos se los puede nombrar con un prefijo común como pru o tmp.

Comentarios y Descripciones
Cada caso de prueba y datapool puede tener una descripción que diga en líneas generales cuál es su objetivo. Por otro lado dentro de los casos de pruebas podemos incluir comentarios que ilustren los distintos pasos dentro del caso de prueba. Dentro de los datapool es conveniente agregar una columna más que sea comentarios en la cual en caso de que se quiera se agregue un comentario para cada dato que se utilizará en las pruebas.

Componentes Reutilizables
Una de las ventajas principales de GXtest es la facilidad para reutilizar casos de prueba. Para poder explotar al máximo esta cualidad es importante definir cuáles son los casos de prueba que serán reutilizados, que variables de entrada y salida tendrán y que datapools utilizarán. Luego se construyen los casos de prueba principales simplemente anidando otros casos de prueba.

Descripción de las validaciones
Cada validación en GXtest tiene un campo extra en el cual se le puede incluir una descripción a ser mostrada en caso de que falle. Esta descripción es sumamente útil a la hora de analizar los resultados de una ejecución.

¿Que otras buenas prácticas utilizan ustedes con GXtest?

Upgrade de GXtest liberado (v. 1.1.4)

2011-01-21T04:58:00.000-08:00

Desde la liberación de la versión 1.1 hemos continuado desarrollando y mejorando el producto. Hace muy pocos días dejamos disponible una nueva versión (v. 1.1.4) y no queríamos dejar de hacer mención de los principales avances que tiene, más allá de las mejoras y bugfixes:

Simplificación del modelo

Simplificación en el uso de datapools relacionados, ya no se necesita el datapool datasets para relacionar datos de distintos datapools. Por otro lado se brinda la posibilidad de relacionar datos con distintos niveles de anidación.
No es necesario usar el dummy event, se permiten aristas sin eventos. Al ver que esto era algo común, optamos por no requerir agregar un evento en cada arista.

Mejor interpretación de resultados

Se mejora la visualización de resultados en el Designer, sin abrir las responses obtenidas en otro tab, sino en un cuadro abajo, en forma mucho más práctica (ver ejemplo).
Se renderizan los css y las imágenes en las html guardadas como responses de las ejecuciones (eso se puede ver en el ejemplo anterior).

Generación de casos de prueba

Hace mucho tiempo comentamos que dejamos disponible una interfaz por la cual se podrían generar casos de prueba en forma externa, tal que se puedan cargar luego en GXtest y ejecutarlos desde ahí. Esto permite que por ejemplo, a partir de la KB, o de una recorrida por la aplicación o modelos de alto nivel, se generen casos de prueba que luego se puedan usar en GXtest. En esta nueva versión se incluyeron mejoras en esta interfaz, permitiendo expresar muchas más cosas en forma más simple y funcional.
Con este fin también se facilitó el formato con el que se exportan e importan los datapools (csv en lugar de xml).

Facilidad de instalación

Para brindarle la metadata de la KB a GXtest es necesario instalar una extension (en el caso de que se esté trabajando con GX X o superior). Ahora esta extension está en el GeneXus Marketplace, lo cual hace más fácil su instalación.

Esperamos que puedan probarlas y darnos su opinión. Desde ya gracias!