Por qué correr cuando puedes testear GeneXus
•Descargar como PPTX, PDF•
0 recomendaciones•865 vistas
Este documento habla sobre la importancia de probar aplicaciones para evitar costos de aplicaciones que no funcionan. Recomienda realizar pruebas funcionales, de seguridad, instalación, desempeño, disponibilidad y configuración durante la planificación, construcción y mantenimiento de una aplicación. Además, sugiere utilizar técnicas de testing basadas en riesgos, clases de equivalencia, máquinas de estado, testing automatizado y generación automática de casos y datos de prueba para mejorar la productividad y calidad. Finalmente, enfat
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a Por qué correr cuando puedes testear GeneXus
Similar a Por qué correr cuando puedes testear GeneXus (20)
Más de GeneXus Consulting
Último
Último (20)
Por qué correr cuando puedes testear GeneXus
- 1. I GeneXus Projects Day ¿Por qué correr cuando puedes testear? Matías Reina Guillermo Skrilec
- 2. ¿Su organización está dispuesta a pagar el costo de una aplicación que no funciona?
- 5. Correr ese riesgo YA NO ES UNA OPCIÓN
- 12. ¿Cómo probamos?
- 14. Testing basado en riesgos Impacto Probabilidad
- 15. Estrategias Métodos Exploratorio Basado en sesiones Libre Planificado Clases de equivalencia Máquinas de estado Ejecución Manual Automatizado
- 16. Productividad Tiempo Testing automatizado Desarrollo GeneXus Testing Automatizado Testing Manual
- 17. Generación de datos de prueba Generación de casos automáticamente Ejecución automatizada Scripts de Performance
- 21. Gestionando el testing Requerimientos Casos de prueba Resultados Incidentes
- 22. ¿Cómo medimos?
- 23. ¿Cómo medimos?
- 24. Equipo
- 26. I GeneXus Projects Day ¡Muchas gracias! Matías Reina Guillermo Skrilec mreina@abstracta.com.uy gskrilec@genexusconsulting.com
Notas del editor
- GS: Buenos días, mi nombre es Guillermo y estamos hoy acá con Matías para contarles por qué es importante el testing en los proyectos y cuál es la mejor forma de hacerlo.
- GS: Para comenzar queremos que ustedes piensen el costo que puede ocasionar una aplicación que no funciona para su empresa. Decir que la aplicación no funciona no es muy realista, así que piensen cuanto puede salir un error en alguno de sus sistemas en producción. Obviamente depende de cada negocio, el tiempo que tarde en arreglarse, y muchos otros factores. Para ejemplificar esto, les trajimos un ejemplo real.
- GS: Así se veía la página principal de unos de los principales diarios de Chicago hace 20 días. Habrán podido notar que la noticia principal es la foto de un gato y el texto dice todo test. La página principal del diario estuvo así durante 16 minutos debido a un error en la publicación de las noticias. En realidad las visitas a la página no fueron el mayor problema, porque en esos 16 minutos no detectaron un aumento en las visitas, el problema vino después.
- GS: El diario pidió disculpas por Twitter, pero otras personas también usaron Twitter para difundir este error en el sitio. No solo había gente diciendo que vayan al sitio, sino que también habían capturas de la página circulando cuando el error ya había sido corregido. Nunca faltan los que opinan de lo que paso, cuando en realidad aún no se sabe el motivo del error, pero igual aprovechan para hacerlo. Chicago Suntimes es otro diario, que también aprovechó lo sucedido para sumarse con las críticas. Lo que queremos mostrarles con este ejemplo, que un error muy simple de 16 minutos en realidad tuvo un impacto durante varios días.
- GS: Este tipo de cosas hoy en día ya no pueden suceder porque tienen un costo muy alto. Hace 10 o 15 años el testing se hacía “mas o menos”, es verdad que se probaban los sistemas, pero no con la misma rigurosidad de hoy en día. Pero hace 10 o 15 años el software se utilizaba para registrar cosas que habían sucedido. ¿Se acuerdan cuando compraban con tarjeta de crédito?
- GS: Antes las transacciones se emitían en papel y luego el comerciante debía entregar los vouchers y los mismos se ingresaban al sistema. Hoy en día las transacciones son electrónicas y el software se ha vuelto crítico, tiene que funcionar correctamente, con los niveles de aceptación requeridos, por ejemplo el tiempo de respuesta de cada transacción. Incluso hemos llegado a esto, desde un celular se puede realizar una transacción electrónica.
- Hoy en día estamos en otra situación, una venta no ocurre si hay un problema con el software, y puede llegar a detener la operativa de las empresas, por eso debemos probar los sistemas que construimos. Estamos hablando en promedio del 30% de los proyectos, el testing hoy en día se maneja en ese entorno. Juntos, GeneXus Consulting y Abstracta hemos ejecutado muchos proyectos de manera exitosa y queremos contarles como integrando el testing lo hemos podido lograr.
- MR: Que aspectos de nuestro sistemas probamos? Cuando pensamos en testing lo que la mayoría de la gente piensa es en testing funcional, sin embargo existen un montón de atributos de calidad que pueden ser comprobados mediante técnicas de testing. El testing funcional como saben es ver que el sistema se ajuste a los requerimientos, a las necesidades del negocio, de los usuarios. Este tipo de testing en general es el que se ve más en las empresas. Pero también existen otras pruebas que también pueden aportar valor y ayudar a disminuir riesgos. Por ejemplo más temprano Gerardo y Mauro nos hablaban de test de penetración para evaluar temas relacionados a la seguridad, tenemos pruebas especificas para aspectos de usabilidad, instalación, configuración, performance, etc. Ahora bien, en que momento tenemos que comenzar a ocuparnos de estos aspectos?
- MR: Si bien testear específicamente implica ejecutar el sistema, la verdad es que hay muchas tareas antes de comenzar a testear que podemos avanzar desde el principio del proyecto. En toda la evaluación de riesgos en la planificación es esencial poder medir el impacto de los mismos para planificar adecuadamente el testing. También cuando se comienzan a definir los requerimientos el equipo de testing puede aportar valor. Cuántas veces cuando estamos pensando un requerimiento nos damos cuenta que hay ciertas situaciones que sería bueno tener muy presentes en el la etapa de ejecución de las pruebas. Esas situaciones, ya sea que se de cuenta el analista o el desarrollador, es muy importante asociarla a los requerimientos. Por eso es recomendable junto a los requerimientos asociar los casos de prueba. Esto permite que el desarrollador, antes de pasar una versión a testing, pueda revisar que casos se van a probar. Para que vamos a pasar algo a testing si ya vemos de entrada que tenemos diferencias conceptuales? Por otro lado, una vez que terminamos el desarrollo y pusimos todo en producción, entramos en la etapa más importante que es cuando el sistema está siendo usado. Esta etapa tiene todo una parte de pruebas de regresión de las cuales les hablaremos más adelante, pero también tiene otra parte que es chequear de que todo este funcionando bien, como se dice chequear el estado de salud de nuestro sistemas.
- MR: El sistema es mucho más que solo nuestro software, también esta todo el software de base, todos los componentes físicos, storage, repliación, etc etc. ¿Como saben ustedes si su sistema está funcionando bien en producción? ¿Se enteran cuando el call center está que arde? Esta es una imagen que muestra los problemas clásicos de performance. Acá les quería hacer una pregunta, ¿Cuántos conocen JMX? ¿Cuántos conocen WMI? GeneXus utiliza dos protocolos estándar uno es JMX para el mundo Java y el otro WMI para el mundo .Net que permiten conocer el estado de salud de nuestro sistema. Que cosas nos muestran? Estadísticas de SQLs (pero asociadas a objetos GeneXus), estado del pool de conexiones, del caché de sentencias, estadísticas de los programas GeneXus, etc. Esta información puede ser consumida online o utiliza por consolas de administración para disparar alertas. Hay una gran cantidad de consolas compatibles con estos protocolos. Muchas veces parece que el área de desarrollo habla un idioma distinto que el área de infraestructura y este tipo de herramientas ayudan a comunicarse mejor. El otro día fue a un cliente y el gerente de tecnología me decía muy indignado, Matías lo que pasa es que la gente de desarrollo no tiene idea ni siquiera de lo que es un storage, piensan que es una caja donde se ponen discos. O un gerente de desarrollo que me llama y me dice, Matías me traducís lo que me están diciendo en este mail de infraestructura que es chino básico! El equipo de pruebas de performance, también es un excelente aliado para hacer de interfase entre las áreas ya que manejan conceptos de “fierros” y también los conceptos de software. Hay una práctica muy fácil de aplicar que nosotros recomendamos que la apliquen en sus empresas. Esto es pasar información relevante de forma periódica desde infraestructura a desarrollo. Que tipo de información: .- top de programas que más demoran .- top de sqls .- errores 500s, errores 400s Se tiene que trabajar en conjunto con todas las áreas, pero en conjunto en serio, no cada uno viendo que no haya problemas en su sector para lograr la calidad que necesitan sus organizaciones. Las pruebas de performance muchas veces ayudan, no solo a mejorar el sistema para soportar la carga que el negocio necesita, sino que también para poder entrenar al equipo en detectar y atacar problemas si estos suceden en producción. Es por eso que los proyectos de testing de performance pueden ser instancias de aprendizaje muy importante para las organizaciones.
- GS: ¿Cómo probamos en los proyectos? En todos los proyectos tenemos recursos limitados, por lo tanto probar todo el sistema exhaustivamente no es posible. La mejor forma de identificar y seleccionar correctamente lo que vamos a probar es hacer una planificación basada en riesgos. Para que comprendan de que se trata esto, existe un término “triage”, que se utiliza en las salas de emergencia médica para la atención de los pacientes, que se basa en las prioridades de atención y posibilidad de supervivencia de acuerdo a las necesidades terapéuticas y los recursos disponibles en la sala.
- GS: Este es un ejemplo de una emergencia médica donde se define con cada color el nivel de urgencia, el tipo y el tiempo de espera. Una persona que necesita resucitación por ejemplo será atendida de forma inmediata, mientras que una cortadura leve podría esperar 2 horas o más. Este mismo concepto lo podemos llevar al software, en base al análisis de riesgos del proyecto se debe realizar la planificación de las pruebas, de manera de podes asegurar que lo “vital” del sistema va a funcionar correctamente. http://www.softwaretestingclub.com/profiles/blogs/triage-what-to-fix-and-when http://es.wikipedia.org/wiki/Triaje MR: Ahora en nuestros sistemas ¿que tipo de emergencias podemos llegar a tener? Lo que hablábamos al principio, que el sistema no tenga el desempeño adecuado, que se caiga, que no funcione como esperábamos, que no se pueda instalar, etc. Dependiendo de sus negocios, cada uno de esos aspectos puede ser azul o rojo.
- GS: Impacto x Probabilidad de ocurrencia = Exposición o Nivel de riesgo La forma de hacerlo es la siguiente: Identificar riesgos, que en realidad deberían haberse identificado en el análisis de riesgos del proyecto. Trabajar con el gerente de proyecto para esto es muy bueno por la visión general que tiene. Identificar el nivel del riesgo en cada caso. Los niveles de riesgos determinarán entonces el “triage” del testing, o sea la cobertura de las pruebas, la prioridad de cada una, el orden de ejecución, entre otros aspectos. MR: Lo que es importante que ustedes consideren, más allá del nivel de exposición de cada riesgo es que hay cosas que a veces las subestimamos y sin embargo aumentan la probabilidad de que ocurra un riesgo. Por ejemplo: Uso masivo del sistema y concurrencia Volumen de datos Nuevas configuraciones de alta disponibilidad Estandares de seguridad
- MR: En general tenemos distintas estrategias para nuestras pruebas y en particular para las pruebas funcionales. Tenemos dos estrategas bien diferentes, una es el testing exploratorio y la otra es el testing planificado. En el testing exploratorio consiste en mientras vamos interactuando con la aplicación al mismo tiempo diseñar las pruebas, aprender, ejecutar y reportar. Por otro lado el testing planificado diferencia dos etapas bien marcadas, por un lado se diseñan las pruebas y por otro lado se ejecutan en otro momento. Ahora, el testing exploratorio, se puede hacer de diferentes maneras, el estilo libre, es simplemente sentarse y comenzar a tocar todo lo que se les ocurra. Nosotros recomendamos la estrategia del testing exploratorio basado en sesiones. Es bien sencillo de aplicar, antes de comenzar a testear se definen misiones, y luego se asignan cierta cantidad de sesiones de entre 30 min y 1 hora a los testers. Esta metodología permite gestionar el testing mucho más eficientemente. Por otro lado en el testing planificado, utilizamos alguna técnica para modelar la realidad y luego derivar los casos. En particular lo que más utilizamos es clases de equivalencia, combinado con valores limites y máquinas de estado. El testing planificado permite que un grupo de personas con mayor experiencia definan los casos de prueba y luego estos sean ejecutados en conjunto con gente que tiene menos experiencia. El testing exploratorio es conveniente utilizarlos en contextos en los cuales tienen poco tiempo, necesitan feedback rápido y cuentan con un grupo de gente experta en el dominio y en testing. Esto les va a permitir justamente diseñar los casos de prueba en el momento mientras ejecutan y dar feedback rápidamente. Por otro lado luego que tenemos diseñadas las pruebas, podemos ejecutar las mismas de manera manual o automática. Dejenos contarles algo más acerca de las pruebas automáticas…
- GS: Con el uso de GeneXus y patrones en el desarrollo de aplicaciones, la productividad en la construcción aumenta, pero sin embargo el testing manual generalmente es el cuello de botella en los proyectos porque no puede acompañar esta productividad. El aumento de la productividad del testing viene por el lado de la automatización de pruebas, aumentando así la cantidad de pruebas que se pueden correr en el sistema. De la misma forma que GeneXus automáticamente resuelve un montón de cosas, GXtest permite hacer lo mismo a la hora de probar las aplicaciones. MR: El desarrollo de sistemas decimos que es acumulativo, yo tengo 10 funcionalidedes, programo una más y tengo 11 funcionalidades. En testing, la ejecución de las pruebas siempre tienen que arrancar desde 0, la única forma de acumular es automatizandola
- GS: GXtest permite automatizar la ejecución de pruebas funcionales en aplicaciones web. Este sería el concepto de automatización que otras herramientas conocidas en la industria también lo realizan, por ejemplo Selenium, rational robot, etc. La diferencia es que a medida que se realizan cambios en la base de conocimientos, GXtest los detecta y realiza los ajustes necesarios en los casos de prueba para que puedan seguir ejecutando. GXtest va mucho más allá en realidad, porque también permite generar los casos de prueba de forma automática a partir de la información de la base de conocimiento. Hoy en día genera pruebas automatizadas incluso sobre patrones como K2B Tools, de manera de cubrir los ciclos de prueba básicos del alta, visualización, búsqueda, modificación, eliminación, entre otro tipo de pruebas que permite probar la aplicación con un solo clic. Pero esto no es todo, GXtest también puede generar los datos de prueba que debe utilizar para ejecutar las pruebas, logrando la potencia necesaria para comenzar con pruebas automatizadas sin mayor esfuerzo. Las pruebas más importantes y críticas de sus sistemas deberían estar automatizadas con GXtest.
- GS: Este es un caso de prueba en GXtest generado automáticamente, lo que hace es seleccionar un cliente del WW y actualizar sus datos, luego su funciona correctamente lo va a buscar por ejemplo, de lo contrario sigue otro camino. Como pueden ver el flujo del caso de prueba tiene una representación gráfica donde se pueden definir acciones y validaciones que se deben realizar. Existen distintas formas de generar los casos de prueba, como les comentaba antes de forma automática, pero también de manera más tradicional grabando las pruebas directamente en el browser. Es importante que sepan que las personas que utilizan Gxtest no tienen porque saber nada de Genexus, pueden ser expertos en el dominio, puede ser un contador por ejemplo.
- GS: Por otro lado, es importante mencionar que a diferencia de otras herramientas de automatización, GXtest asocia los elementos de las pruebas a los objetos GeneXus de la base de conocimiento. Entonces, cuando hay cambios en la KB, se realiza un impacto en GXtest como puede ver en esta imagen y se propagan los cambios en los casos de prueba automáticamente. Esto se realiza de esta forma, dado que no se pueden automatizar las pruebas en base a los nombres de los controles en el HTML, porque con cada cambio y generación en GeneXus, los identificadores de los mismos pueden variar, dejando inutilizados los casos de prueba. Esto en GXtest no sucede, disminuyendo el costo de automatización y haciendo posible utilizar este tipo de herramientas en contextos en los cuales con herramientas tradicionales no podríamos.
- MR: Gxtest también incorporó la posibilidad de generar pruebas de performance. Anteriormente era solo para aplicaciones Web, pero ahora también permite hacerlo para aplicaciones móviles. En el evento Genexus vamos a estar compartiendo estas y otras nuevas funcionalidades de la herramienta. Ahora bien, gxtest me permite automatizar las pruebas, pero como gestiono todo esto?
- MR: Más allá de las pruebas automatizadas existen otros conceptos que tenemos que poder gestionar. En particular, desde la perspectiva del testing tenemos 4 conceptos que son fundamentales: requerimientos, casos de prueba, resultados e incidentes. Cada requerimiento tiene asociado un conjunto de casos de prueba, los cuales se pueden ejecutar, dando éxito o falla. Cuando se produce una falla se tienen asociados los incidentes a dicha falla. Existen varias herramientas para gestionar estos conceptos, nosotros en particular utilizamos dos herramientas que son las más difundidas en el mundo libre y que seguramente muchos de ustedes las conocen: Mantis y Testlink
- MR: Nos pasa en el área de testing que nos preguntan y como les va? Cuánto falta? La verdad es que si no tenemos medido nada, vamos a decirle y mirá pienso que me falta poco o bastante, no se. Si tenemos herramientas en las cuales vamos marcando como van las ejecuciones damos una visibilidad tremenda al proceso de testing. De esa manera los interesados van a poder ver cuántos requerimientos vamos probando, cuántos quedan, cuántos casos de prueba se van ejecutando, cuántos quedan por ejecutar, cuántos fallaron, etc. Otra cosa que nos aporte es que si no marcamos cuando algo ejecuta bien, parece que no tenemos avance en el área de testing, y en realidad tener la tranquilidad que un conjunto de pruebas pasaron correctamente da mucha información relevante para tomar decisiones importantes.
- MR: otra herramienta que utilizamos mucho es el mantis. Nos permite diseñar nuestros procesos de manera sencilla y seguir un determinado flow. Cuando le sugerís a las empresas que implementen estas herramientas muchas veces te dicen, para que si yo con un excel estoy bien. La verdad es que a medida que el volumen de las cosas comienza a crecer, que empezamos a tener distintas versiones, diferentes personas en el equipo, etc, gestionar todo con un excel es muy muy complicado. Contar con estas dos herramientas básicas les va a permitir tener información muy útil para tomar mejores decisiones, poder mejorar sus procesos y de esta manera poder distinguir los temas rojos de los azules tal como hablábamos más temprano. Otra cosa es que si bien requieren instalar las herramientas, capacitarse, etc. luego no implican tener un sobre-trabajo importante para nuestros proyectos, sino que al contrario nos ayudan a ser más eficientes. El objetivo siempre es estar alineado con el proyecto. No todos los incidentes son “importantes”. A veces pasa que en el área de testing confundimos nuestros objetivos y pensamos que lo importante es “romper” lo más que se pueda. La verdad es que los productos tienen diferentes etapas y objetivos y nosotros tenemos que estar alineado con eso. Si es un software que se tiene que liberar en determinada fecha por primera vez, que va a ser usado por un grupo de personas capacitadas, etc concentremos el esfuerzo en encontrar los temas más importantes y dejar las pruebas que ven si el sistema es estable para más adelante. Me acuerdo cuando estábamos por largar la primera beta de gxtest en el 2008, Fabián y yo desarrollábamos y Federico se encargaba exclusivamente de probar Gxtest. En una de las funcionalidades me dice, Mati encontré este error, acá donde tengo que importar un xml, si agarro un archivo .exe y lo renombro como xml entonces gxtest falla. La prueba esta bien, pero ese no era el momento ya que la probabilidad de que eso ocurra era muy baja. Nosotros en el quipo de testing tenemos que tener una obsesión por reportar primero las cosas más relevantes. Si bien es verdad que todo lo que reportamos luego se categoriza, si el desarrollador abre el mail y tiene 50 incidentes y solo 1 es relevante y el resto son de cosmética, eso lo va a desmotivar. Por eso es mejor reportar primero solamente los temas más importantes y al final dejar los temas menores para corregirlos en una segunda etapa.
- MR: El equipo de testing tiene que tener la suficiente fortaleza técnica como para decirle a desarrollo, mira esto así como esta apesta, hay que hacerlo de nuevo, o hay que cambiar esto y aquello. Si tenemos gente que no es fuerte técnicamente, que no tiene los conceptos bien asimilados, entonces no va a aportar el valor que se tiene que aportar. Si logramos tener este equipo profesional, se van a dar cuenta que si logran involucrarlo desde las primeras etapas del proyecto (análisis de requerimientos, definición del proyecto, etc.) van a lograr aportar mucho en sus proyectos, mejorando la calidad, la imagen de sus empresas y de sus áreas de sistemas. Hoy en día existe mucha capacitación y certificaciones especificas para Testing. Existe una carrera incluso que es realmente un orgullo que sea uruguaya ya que es reconocida por los gurus mundiales de testing. Es la carrera de testing del CES. Tengan en cuenta que testing es una bolsa muy grande y que hay perfiles muy distintos dentro del equipo de testing. La persona que hace testing funcional no tiene le mismo perfil que la de performance, etc.
- MR: Que me gustaría que se lleven de esta charla, que contando con un equipo de testing profesional pueden aportar mucho valor, ayudando a disminuir riesgos que tienen asociados costos muy altos para sus empresas. También que el testing ayuda a integrar todas las áreas, generando sinergia entre infraestructura, operaciones, desarrollo, etc Otro tema importante es que GeneXus tiene instrumentos muy útiles para atacar alguno de esos riesgos que tienen que conocer y dominar. También que existen herramientas especificas como GXtest que les ayudan a aumentar la productividad y a cumplir con objetivos que de otra manera es imposible. Creemos que si testeamos de esta manera en nuestros proyectos vamos a poder estar más tranquilos y dejar de correr.