Betatesting de GeneXus (2011)
Desde hace unos cuantos años, me toca hacer pruebas en las versiones Beta de GeneXus. Esta bueno hacerlo para ir aprendiendo y entendiendo que es lo que tiene la próxima versión de la herramienta que utilizamos para desarrollar.
Esto nos permite adaptar las metodologías de desarrollo para poder aprovechar las nuevas funcionalidades y ofrecer cosas nuevas a nuestros clientes.
También permite calcular los riesgos de la migración de nuestras aplicaciones a las nuevas versiones, de forma de poder hacerlas con un costo razonable.
Que evolución ha tenido el proceso de betatesting en GeneXus?
Agilidad.
Hoy tenemos disponibles Night Build que permiten tener la ultima versión desarrollada. Tiene el riesgo que algo que ayer funcionaba, hoy deje de funcionar, pero también tiene la ventaja de poder tener arreglos muy rápido.
Estabilidad.
Se nota que el proceso de desarrollo interno de GeneXus ha madurado, pues las cosas se rompen menos que en ciclos anteriores. Hoy se puede desarrollar con la version Ev2, en aplicaciones WEB de forma muy aceptable, cosas que no sucedia en otros ciclos de betatesting.
Documentación.
Existe documentación (escasa, pero existe) de los cambios que se realizan a cada uno de los Night Build, donde se enumeran brevemente los cambios realizados (arreglo de errores y nuevas funcionalidades). Tengo la sensación que la documentación siempre sera insuficiente, pero en esto estamos mucho mejor que antes.
Pruebas.
Es claro que se ha mejorado en como se prueba GeneXus y en la cantidad de pruebas que se ejecutan. También da la sensación que la cantidad de betatester ha aumentado, lo que ayuda a que las nuevas versiones vengan mas probadas que antes.
Entre las pruebas automatizadas, las pruebas internas y las pruebas externas creo que estamos muchísimo mejor que en tiempos pasados, aunque es algo en lo que todos deberíamos seguir traajando para mejorar.
Que me gustaría cambiar?
Si fuera gratis y estuviera en mis manos, me gustaría hacer algunas mejoras.
Acceso a resultados de pruebas automatizadas.
Que los betatester puedan acceder a los resultados de las pruebas automatizadas, puede ayudar a entender que es lo que esta roto en este build y evaluar si puedo o no instalarlo.
Ademas podría sugerise agregar nuevas pruebas para que errores comunes no vuelvan a repetirse.
Abrir el resultado de las pruebas al grupo de betatester puede poner nervioso a mas de uno, pero creo que es un paso bueno para lograr mayor estabilidad y va a ser inevitable en un futuro cercano.
Acceso a problemas conocidos o que aun no esta desarrollado.
Los betatester deberíamos tener acceso a la lista de problemas conocidos de la version, de tal forma de saber a que nos atenemos cuando probamos una versión. Por ejemplo, saber que algo que funciona en Android y aun no esta implementado en iOS, es fundamental para saber si lo probamos o no.
Guía en las pruebas.
Seria bueno que se sugirieran que casos se quieren probar o que casos serian buenos tener en cuenta pues han realizado cambios importantes.
Por ejemplo, si se cambia el paginado de las grillas, se cuente en que casos aplica y como seria el resultado esperado, para que podamos probarlo con nuestros desarrollo, sabiendo lo que probamos.
Roadmap.
Tener un roadmap claro de cuales son las fechas y los principales mojones en el desarrollo. Estas fechas y el alcance van a poder modificarse (siempre hay que adaptarse a la realidad!) pero ayuda a planificar a mediano plazo.
En los últimos días se ha enviado algo al foro, pero seria bueno tenerlo en el Wiki y a mayor largo plazo.
Rapidez de respuesta.
El foro sigue teniendo problemas de velocidad en la respuesta, pues hay problemas que se plantean y que nunca se responden. Los temas relacionados con el foco de este betatesting (Generador SmartDevices) se responden rápido, pero otros quedan en el olvido.
Esto no debería suceder y alguien debería tomar la posta en manejarlos pues creo que aportan valor.
Foro por mail.
El mail debería ser un método de notificación, pero creo que hay herramientas mejores para el manejo de preguntas y respuestas como las que se dan en el foro.
Bueno, hasta aqui mi impresiones. Me gustaría conocer otras opiniones.
Excelente Enrique, acabas de hacer un buen resumen de temas que se han tratado con respecto a "cómo mejora el proceso" y qué cosas vemos que se podrían mejorar (Foros, Mails, Twitter y cosas charladas en GUG's).
ResponderBorrarAlgo que yo veo es que falta algo de "transparencia", por lo menos para los Betatesters.
En otras comunidades tienen procesos asociados a un "BugTracker" que en realidad suman no solo bugs sino sugerencias, y asignan "targets" de esos temas a versiones o build.
De la misma forma que hoy se manejan SAC's, también quedará documentado los motivos por lo que se acepta o se aplaza o se rechaza un bug, una sugerencia o lo que sea.
Luego esos "temas" podrán tener seguimiento, de si quedaron o no solucionados para ese build/version (si se reabre o no), con lo que pueden tener una idea global de progreso.
Muchas otras comunidades "atan" test a esos "temas" y tienen un sistema casi automático para conocer el estado de las cosas (e ir a la documentación origen que generó el testo o los test).
Algunas comunidades usan ese sistema como "roadmap", o sea, plasman en esa herramienta las funcionalidades o arreglos para un determinado build, y se puede ir haciendo seguimiento de cómo va lo planificado e inclusive día a día ver qué cosas se solucionaron y cuales fueron "rotas".
Sería cuestión de enchanchar esos temas con la documentación en la wiki de cada uno de ellos y tendriamos más cerrado el tema de qué cosas origina qué y qué cosas se deben de arreglar en la documentación.
Sobre el tema del Foro, creo que debería de seguir existiendo, yo permitiría poder manejarlo via web y no mail.
De la misma forma se podría enganchar el "bugtracker" con un hilo en el foro, un sitio de preguntas y respuestas y la propia wiki.
Sobre el tema de los mails sin respuestas. Estaría bueno generar un "Digest", algo que analice "los temas" del foro y sea posible notificar cuales no obtuvieron una respuesta o manejar un tema de estado de "cerrado" o "abierto".
Si a quien abre un tema en el foro a determinado tiempo le llega un mail automático para preguntarle si el tema quedó cerrado, pienso que si la gente de forma simple indica "si" o "no" ya con eso tenemos un método de tener seguimiento que cosas están "colgadas" y perdidas en la inmensidad del foro. (de todas formas, alguien, tendría que participar hasta lograr que el tema sea cerrado)
David:
ResponderBorrarEstamos pasando de una forma de desarrollo de GeneXus totalmente cerrado a una forma un poco mas participativa.
Cada uno de estos cambios lleva tiempo e implica cambiar la forma de pensar (tantos de Artech, como de nosotros), lo cual es lo mas dificil.
Hay que seguir mejorando paso a paso.
Gracias por el coment