Desarrollando desde la trinchera.

Encontré la presentación: Model-Driven Development, the end of the test profession? View more presentations from Johan den Haan . Me senti muy identificado con los problemas y las conclusiones a las que arribaron. El problema planteado es si es necesario testear aplicaciones generadas automáticamente por generadores de aplicaciones (como GeneXus). Con un generador de aplicaciones, se hacen mucho menos importantes los testeo de bajo nivel y toman mas importancia las pruebas de mayor nivel de abstracción. Pasan a no ser tan importantes: Testeo unitario basado en el código. Testeo de vulnerabilidades de seguridad en el codigo (si todos los ingresos de datos son generados de igual forma, validando que uno de cada tipo queda bien generado, puedo asegurarme que que todos esta bien).  Pasa a ser MAS importantes, para diseñar la aplicación Testeo de requerimientos Prueba del diseño funcional de la aplicacion y patrones.  También...

En los objetos Procedure y Transaction Genexus existe la propiedad “ Commit on Exit ”, que puede tener los valores   YES y NO. La documentación del Wiki de la comunidad, explica de una forma no demasiado clara para mi lo siguiente: Values Yes : The generated program executes a commit at the end of the LUW. No: The generated program does not execute a commit at the end of the LUW. Default Value = Yes Description Programs generated by GeneXus execute commits at the end of each transaction (referring to the concept of database transaction, not the GeneXus object). This automatic commit is included in all programs that update the database . It is not included in Reports, Work Panels and Web Panels that do not update the database. Esto funciona bastante bien para la mayoría de los programas. El problema es que no es trivial saber si un programa hace o no commit con solo mirarlo, pues hay que mirar si esta haciendo algun UPDATE o INSERT en la base de datos, sobre ...

Hablando con colegas, algunos me decían que no entendían porque dedicaba tiempo a hacer betatesting de diferentes productos y que para ellos era una perdida de tiempo y que las veces que habían participado en ciclos de pruebas beta, no habían logrado que sus sugerencias fueran tomadas en cuenta. Una cosa importante a tener en cuenta, es que la etapa de betatesting es cuales son las expectativas que se pueden tener en un ciclo de pruebas en esta etapa. Cuando desarrollo un producto y el mismo esta en etapa de BETA, mi intención es tratar que el mismo se pruebe en la mayor cantidad de maquinas y usuarios posibles, de forma de chocar mis programas contra la realidad de forma de ver si se adapta correctamente. La etapa de BETA, n o es para la incorporación de nuevas funcionalides , sino para hacer los ajustes en las funcionalidades que ya están desarrolladas. Durante la etapa de Betatesting, no se van a incoporar nuevas funcionalidades?. Se pueden incorporar funcionalidades en forma paulat...

He participado en varios ciclos de betatesting de GeneXus. No recuerdo bien en que version fue la primera en que tuvimos acceso a las versiones beta de GeneXus, y es bueno ver la evolución y apertura que ha tenido. En la ultima etapa de la X y con toda la Evolution I, hemos tenido disponibles los Night Build (NB), que son la versión bastante cruda de GeneXus, que se genera en forma automática en la noche, con lo programado durante el día, para poder nosotros probar con la misma. Los productos que tenemos para testear ahora son mas y ademas son mas complejos. Por ejemplo ahora se deben testear GeneXus, GXFlow, GeneXus Server y el SDK de GeneXus. Cosas malas de los NB. Al ser una versión sin demasiado test, puede ser inestable y cosas que funcionaban ayer, dejaban de funcionar al otro dia, o funcionaban diferente. El bajar, instalar y generar todo con el nuevo NB, lleva tiempo. Dificulta un poco el reporte/reproduccion de problemas, pues hay que especificar precisamente en que NB estoy ...

En GeneXus X Evolution I, se incorporó un producto nuevo que se llama GeneXus Server . El mismo permite almacenar en un servidor la base de conocimiento de forma que un grupo de trabajo (que puede estar distribuido geográficamente) comparta la misma, haciendo mucho mas fácil y con menos errores el desarrollo de grandes aplicaciones. Si bien no hay demasiada documentación aún, me han comentado en forma no oficial que se van a poder programar extensiones para GeneXus Server , de forma que se puedan agregar funcionalidad no brindada en forma nativa. Cuales podrían ser estas extensiones? Incorporación de pruebas unitarias que estén asociados a objetos y que cada vez que se hace un COMMIT de los objetos (*) se ejecuten en forma automática las pruebas unitarias de dichos objetos y se informe si hay errores (o diferencias) con la versión anterior. Comparador de Navegaciones . Cuando se tiene una nueva versión de los objetos, se puede revisar si la navegación sigue siendo igual que la anteri...

Hay un video de la RubyConf, que habla sobre las herejias en el testeo :  Dura 60 minutos (demasiado largo para decir lo que dice y las preguntas no se escuchan bien), pero tiene algunas cosas interesantes: Algunas frases de la charla:  El testeo es dificil, pero eso esta bien. Los trabajos faciles no pagan bien.  Testing = Velocity * Quality Hablando sobre mocking (sustituir el acceso a la base de datos o la llamada a objetos externos de mi aplicacion) habla sobre el estado que es lo que realmente importa.  Tambien se habla sobre la velocidad de los test, que en la mayoria de la bibliografia cuentan que si los test demoran mas de 30 segundos, parece que hay algo mal contigo.  Lo que dice es de sentido comun, que seria bueno que los test corrieran en menos de 30 segundos, pero en aplicaciones complicadas, van a demorar muchos minutos.  También hay una frase de Donald Rumsfeld que me dejó pensando:  There are known knowns. There are things we know that we know. There are known unknowns....

Leo un artículo interesante (introductorio)  en MSDN Magazine , donde recalcan que una de las mejoras de testear temprano y diseñar pensando en el testing, es el que se consigue codigo mucho mas facil de probar y hacerle debug. Esto parece una ventaja muy grande y es mi principal incentivo para poder incorporar metodologias agiles (TDD, DDD) en nuestro proceso de desarrollo.  En el articulo tambien mencionan los principales problemas que se tienen al testear aplicaciones como las que hoy desarrollamos en Concepto, que son:  el simular el funcionamiento de la base de datos para obtener resultados consistentes y rapidos  chequear eventos externos (como el envio y recepcion de mail, webservcies, etc) workflows Algunas de las conclusiones del articulo:  Smaller tests are cheaper to create, easier to understand, faster to run, and much simpler to debug. It sounds like more work to write a bunch of unit tests than a single integrated test, but I've frequently found it more efficient to t...

En el contexto del programa PacPymes , la CUTI decidió hacer un proyecto de ayuda a las empresas para mejorar los procesos de testing de las mismas.  Es interesante, pues participando nos pueden reembolsar  hasta un poco mas del 50% del costo del proyecto (hasta un maximo de 5000 euros). En el comunicado que nos llego dice:  "Cuti convoca a empresas interesadas en integrar proyecto asociativo y de mejora individual para la creación o fortalecimiento de sus áreas de testing.  El proyecto se enmarca dentro del programa de fortalecimiento de la gestión e innovación empresarial de pymes exportadoras, desarrollado por el Programa de Apoyo a la Competitividad y Promoción de Exportaciones de la Pequeña y Mediana Empresa (Pacpymes) , de la Cooperación Unión Europea - Uruguay. Los solicitantes deberán tener como actividad principal el desarrollo de software, cumplir con los requisitos de elegibilidad y aportar la contraparte exigida por el programa Pacpymes ( más información ).  El porcen...

Leo en Amazon Web Services Blog: SOASTA - Load Testing From the Cloud SOASTA - Load Testing From the Cloud I met Tom Lounibos, CEO of SOASTA , at the Palo Alto stop of the AWS Start-Up Tour. Tom gave the audience a good introduction to their CloudTest product, an on demand load testing solution which resides on and runs from Amazon EC2.Soasta_record Tom wrote to me last week to tell me that they are now able to simulate over 500,000 users hitting a single web application. Testing at this level gives system architects the power to verify the scalability of sites, servers, applications, and networks in advance of a genuine surge in traffic. Estuve mirando este  video , y parece muy bueno. Permite diseñar pruebas de aplicaciones web, y luego simular la carga de hasta 500.000 usuarios. Parece un poco caro , pero bueno...

Hace unos días los muchachos Abstracta nos hicieron una demostración de su (futuro) producto GxTest. Segun sus palabras: "...GxTest no es solo una herramienta de automatización sino que es una herramienta para dar soporte a varias tareas de testing funcional de sistema, específica en principio para aplicaciones desarrolladas en Genexus. Lo que busca GxTest es dejarle al tester las tareas entretenidas y creativas y automatizar todas aquellas que sean tediosas y aburridas." Hay que ver como termina la historia, pero por ahora lo veo similar a CubicTest adaptado a GeneXus, lo cual está muy bueno. Creo que contar con una herramienta de testing que trabaje al mismo nivel de abstraccion que GeneXus nos puede servir a todos... El proceso es mas o menos el siguiente: Se define un modelo de las forma de interactuar que tienen mis programas, explicitando la forma en que se producen las transiciones y las validaciones que tengo que hacer para saber si el programa funciono bien. A par...

El CES organizó la semana pasada un Seminario sobre "Técnicas de Testing Funcional". La idea básica del curso, es la de mostrar diferentes metodologías para el diseño de casos de pruebas para la verificación (manual o automatizada) de sistemas de información. Las que vimos fueron: Partición de Equivalencia Valor limite Combinación de Pares Maquinas de Estado Derivacion a partir de casos de uso Testing Exploratorio Algunas son técnicas para la ayuda a diseñar casos de prueba que permitan descubrir errores o cubrir una parte mayor del codigo. El seminario de tres días, estuvo bueno, aunque creo que hubiese sido un poco mas productivo, hacer primero este seminario (con la teoría) y luego el de automatización (con la parte practica y automatizada). Este tipo de seminarios me sirven mucho para conocer de un tema en el cual recién estoy empezando a incursionar. También veo que el tema está en pañales, y me doy cuenta lo primitivas que son las herramientas que tenemos para probar ...

Hace unos días, intercambiábamos ideas con algunos amigos sobre aplicaciones y otros temas relacionados con testeo. La mayoría de los que participábamos en la charla, trabajamos con GeneXus y veíamos el problema de no contar con algún tipo de metadatos o información relacionada con como dicha aplicación fue generada. En el proceso de generación de código se "pierde" gran cantidad de conocimiento. En realidad ese conocimiento no se pierde sino que queda en un formato muy difícil de ser utilizado por aplicaciones. El código generado contiene gran cantidad de ésta información, pero para poder recuperarla, hay que poder extraer del código los datos que nos interesan, lo cual es una tarea que produce inflamación en diversas partes el cuerpo (al menos a mí). El código generado es diferente para cada uno de los generadores, lo cual multiplica el trabajo a realizar. Este proceso, puede ser visto como un re trabajo, que tiene sentido cuando algún humano escribió el código a mano, pe...

Subi a GXOpen , los proyectos GXUnit del Grupo I y Grupo II de Facultad de Ingenieria de la Universidad de la Republica. Son el resultado del trabajo de algunos meses de estudiantes de la carrera de ingeniero de sistemas en computación, del cual participé como tutor (o cliente) junto con Alejandro Araujo y Uruguay Larreborges. Para hacerlos funcionar, hay que bajarse el proyecto, leer la documentacion y hacerle CAMBIOS, para adaptarse a los cambios que surgieron desde diciembre a la fecha. Hay algunos namespaces que cambiaron y tambien se agregaron unos controles a las GeneXus extensions. A pesar de no ser un desarrolo mio, lo subo para que quede disponible por si alguien quiere seguir la tarea. Los links son: Grupo I Download del Proyecto Video de uso de la extension Grupo II Download del Proyecto Video de uso de la extension UPDATE: En menos de 2 horas, se consumió todo el ancho de banda que brinda (1GB) screencast.com, para todo un mes, para ver los videos. Si alguien esta interesad...

Anoche el CES organizó una jornada para hablar del testeo. Primero dos importantes empresas de plaza hablaron sobre como están manejando sus procesos de testeo y despues se organizó un intercambio de experiencias e ideas entre los participantes. Me llamaron la atención varias cosas: 1) Mas gente de la que esperaba y muchos jovenes 2) Por las charlas veo que somos varios que estamos en la misma, trantando de encontrarle la vuelta al proceso de testeo y de poder automatizar la parte aburrida y simultaneamente darle mas importancia a las pruebas realizadas por humanos. 3) Muchos se presentan como "Encargados de Pruebas", "Tester", "una de la cucarachas de testing", "Gerente de QA". Hace poco tiempo no estaban tan claro estos roles en las organizaciones de desarrollo. La profesionalización y especializacion del testeo es algo deseable, rentable e inevitable. 4) Creo que la relacion programador/tester esta mejorando, tanto en numero y tam...

En WebTest vs. Selenium: Real and Simulated Browser Testing dicen: Functional testing tools for web applications come in a variety of styles, but one of the most fundamental differences between the choices are between the tools that drive one or more real web browsers in order to fully recreate a realistic environment, like Selenium, and tools that simulate the way a web-browser operates, like Canoo WebTest. Marc Guillemot compared the two, and in his opinion, WebTest wins, with a score of 13-5. Via: InfoQ.com

En el último numero de la revista Software Test & Performance , hay un árticulo de como usar JMeter y Selenium. Se que hay varios que están empezando a usar Selenium, por lo que pienso que puede interesarles. No es demasiado detallado, pero ayuda.

Ayer fui al evento " A las pruebas me remito " del Centro de Ensayos de Software . No pude ir a todo el evento, porque tenia una jornada un poco complicada, aunque me hubiera gustado poder asistir a todas. Llegue a ver: BENCHMARKING. Ing. Gustavo Vázquez. Siempre es bueno saber cuanto puede rendir nuestro sistema informático, tanto a nivel de software como de hardware. Medir la performance de nuestro sistema contra otros, puede ser utilizado como una herramienta de mejora e incluso de marketing. Este proceso se conoce con el nombre de Benchmark. En esta charla, veremos los diferentes tipos de benchmark que pueden realizarse, así como aquellos que se utilizan actualmente en la industria. TESTING EN EL CICLO DE VIDA DEL SOFTWARE. Ing. Beatriz Pérez, MSc. Se presentarán cómo los distintos tipos de prueba (unitaria, integración, funcional, del sistema, de aceptación) y las técnicas de prueba ocurren a lo largo del ciclo de vida del producto de software. Se describirán las ...