GX Project Days - Charla de testing
•Descargar como PPTX, PDF•
0 recomendaciones•382 vistas
Por qué correr cuando puedes testear. Charla en la que participó Guillermo Skrilec de GeneXus Consulting y Matías Reina por Abstracta.
Recomendados
Recomendados
Más contenido relacionado
Destacado
Destacado (7)
Similar a GX Project Days - Charla de testing
Similar a GX Project Days - Charla de testing (20)
Más de Abstracta
Más de Abstracta (8)
Último
Último (20)
GX Project Days - Charla de testing
- 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.ChicagoSuntimes 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, GeneXusConsulting 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: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 400sSe 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-whenhttp://es.wikipedia.org/wiki/TriajeMR: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 riesgoLa forma de hacerloes la siguiente:Identificarriesgos, que en realidaddeberíanhaberseidentificado en el análisis de riesgos del proyecto. Trabajar con el gerente de proyectoparaestoesmuybuenopor la visión general quetiene.Identificar el nivel del riesgo en cadacaso.Los niveles de riesgosdeterminaránentonces el “triage” del testing, o sea la cobertura de laspruebas, la prioridad de cadauna, el orden de ejecución, entre otrosaspectos.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:Usomasivo del sistema y concurrenciaVolumen de datosNuevasconfiguraciones de altadisponibilidadEstandares 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: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: Que me gustaría que se lleven de esta charla, que contando con un equipo de testingprofesional 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, etcOtro 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 GXtestque 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.