0168 testing el_camino_para_que_confien_en_nuestro_software

Notas del editor

• #2: Buenos días, mi nombre es Federico Toledo, formo parte del equipo de Abstracta, la cual es una empresa que se dedica al desarrollo de productos para apoyar las tareas de testing. En abstracta estamos ofreciendo y trabajando con Gxtest, la cual es una herramienta de automatización de pruebas funcionales específica para Genexus. En lo personal estoy involucrado en esta área hace poco más de 5 años, y siempre he estado trabajando con distintas formas de automatización de aplicaciones con propósito de realizar distintas pruebas., y bueno, de un tema relacionado con eso es que vamos a estar hablando en esta charla, vamos a estar hablando de testing como un camino para que confíen en nuestro software.
• #3: Hace un par d meses encontramos por ahí un libro que nos resultó muy interesante, pero principalmente a matías. Todos los días venía con algo nuevo. Pa! No sabés lo q leí en el libro hoy! … etcPor suerte nuestros conceptos concuerdan mucho con los d este reconocido libro de testing automatizado. Nos hace ver q lo q andamos diciendo por ahí también está respaldado por esta gente.El libro es este … de fulano … y es d 1998 ?? … o sea q no son ideas tan nuevas, y les aseguro q plantean cosas más q validas … incluso algo interesante es q tienen experiencias d otras personas en proyectos concretos, muy bueno, muy recomendado. Pero a mi en particular me gustó mucho mucho una idea, un problema al q le pusimos un nombreProblema de la Acumulatividad Nula extrovertida sistemática
• #4: Acumulativo Página 494. Hay una gráfica que muestra que las features crecen cada vez más, pero el test no. Eso es un problema, pues significa que cada vez más se nos da el problema de elegir qué testear y dejamos un montón de cosas sin probar. Otra cosa con respecto a esto es que la gráfica de features va creciendo con el tiempo, la de esfuerzo en testing debería ir creciendo también proporcionalmente. De aquí sale El problema de no tener tiempo para automatizar, pues no hay siquiera tiempo para el teSt manual, y tal vez la mayoria de uds no son conscientes de que les sucede esto o de la gravedad del asuntoUn colega argentino de una consultora /Kizcurno (arg)/ Dice q lo más pesado (costoso) en testing es diseño y ejecución.Lo bueno de la automatización es que es acumulativa. La automatización tiene una curva distinta, más pronunciada al comienzo y luego sigue creciendo más lento. Es la única forma de poder que el testing se haga constante, etc. El problema es que generalmente queremos encarar esta tarea cuando ya hay mucho esfuerzo de desarrollo, entonces cuesta más, pues hay una brecha … y nos da pereza comenzar..El desafíoeshacertestingen forma eficiente, de forma que nos rinda, que veamoslosresutaldos (señalarlappt), que nos aporte valor, y q vayaacompañandolaacumulatividaddeldesarrollo.Nuestrapropuestaesautomatizar pruebasfuncionales para hacertestingen forma más eficiente, y asíganar más confianzaennuestro software.
• #5: Y bueno, qué vamos a ver en esta charla?vamos a intentar darles soluciones a muchos de los problemas que típicamente nos aquejan en esto del testing automatizado.WIIFY? En esta charla pretendemos mostrarles algunos tips, algunas soluciones a problemas comunes. Problemas que hemos visto sacados de la experiencia que tenemos de estos ya 2 o 3 años en carrera con automatización de pruebas de sistemas genexus. Y todos estos tips q les vamos a mostrar no son sólo invento nuestro, sino que han sido en su mayoría sacados de un libro llamado … …. Software test automation, (que a matias tanto le gusta)… que mientras más lo leemos más consideramos que es nuestra biblia casi … y como siempre consejos también sacados de lo que dicen alguno de los salados que seguimos en twitter y facebook, como CemKanner, y James Batch, etc.Aclaracion d gxtest. Si quieren lo q les voy a transmitir es mas q nada en cuanto a test automatizado, y no solo d gxtest. Si bien voy a usarlo d ejemplo en algun caso, yo lo q quiero es convencerlos sobre lo bueno q es automatizar pruebas, pues se q si logro eso luego uds mismos se daran cuenta q gxtest es lo más apropiado para hacerlo cuando usan genexus, de eso no me preocupa convencerlos.
• #6: Comencemos con uno de los típicos problemas que se escuchan por ahí. … es como todos sabemos un verdadero dolor de cabeza. Yo voy a considerar que ya saben q Para la calidad Hay que tomarse tiempo, pues todo sea por la Imagen! La pinta es lo de menos, mentira!!Product de calidad, empresa de calidad – otros productos serán predefinidos como de calidad pues vienen de una empresa de calidad (imagen de google o Apple, a pesar de que wave o buzz fueron una cagada, todos imaginaban q iba a estar de más; cada nuevo producto de Apple es deseado desde que se anuncia)
• #7: Entonces si saben q hay q tomarse tiempo para la calidad, algo d testing manual al menos hacen. Entonces tal vez me pueden decir q como tienen tanto para probar manualmente no tienen tiempo para hacer pruebas automáticas.Siempre nos pasa que es difícil dedicar tiempo a algo que da principalmente beneficios a largo plazo. Pero podemos hacer que nos de beneficios a corto plazo, inmediatamente!Para ver como les cuento un ejemploHace poco tenía q probar algo q ejecutaba un proceso batch y luego había q verificar 47 cuentas para verificar que había quedado correctamente el balance. Eso implicaba entrar a la aplicación, buscar por número de cliente, entrar a un workwith y ahí ver en uno de los atributos el balance. De paso había que mirar que se hayan registrado los movimientos, etc. 47 veces lo mismo! No alcanza con ver solo 1??? No!!! Pq cada cliente es un caso particular, uno con mora, otro con plata en moneda extranjera, etc, etc….Qué hizo fede? Automatizó eso una vez, cargó los datos de prueba de la planilla a la herramienta, y ejecutó las 47 veces. Todo en menos tiempo de lo que me hubiera llevado hacerlo a mano 47 veces. Lo mejor, es q mañana sale una nueva versión del sistema y queremos probar lo mismo entonces lo hago con un clic. Acumulé conocimiento en testing!!http://www.kaner.com/pdfs/autosqa.pdfTodos sabemos que mientras más tarde detectemos los bugs más costará corregirlo. Si dedicamos tiempo a hacer pruebas automatizadas tendremos menos tiempo para probar otras funcionalidades, entonces haremos que corregir esas pruebas sea más caro.Por otro lado, automatizando una prueba podremos ejecutarla con muchos datos, y de esa forma acelerar la ejecución de otros casos, que de ser ejecutados manualmente demoraríamos más tiempo… por lo que entonces estaríamos ahorrando el costo de corrección de estos bugs.
• #8: Imaginen q esa es la torta de todos los beneficios obtenibles con todos los TC automatizables…. Regla del 80/20 – se cumple de una forma muy interesante. Hay un 80% de los casos de prueba que al automatizarlos nos van a dar un 20% del beneficio obtenible, y un 20% de los casos de prueba que nos van a dar el 80% del beneficio. Entonces, pensemos y prioricemos esos pocos casos para hacerlos primeroPriorizar Buscar obtener ese 80 de los beneficios lo antes posible y a menor costo
• #11: Este es un problema bastante viejo, que se vienen quejando hace rato.
• #12: Por lo q veíamos recién hay ciertos casos en q la automatización es más barato q las pruebas manuales.Pero, antes de mostrarles cómo abaratar costos con la automatización, quiero aclarar algo! Esto aplica para todo tipo de empresas … o para la mayoría de ellas. Algo que no soporto escuchar es que el testing automatizado es algo para empresas grandes, con recursos de sobra, etc. O que es para quien tiene tiempo para eso. Es muy complejo, no tenemos recursos.Empresas pequeñasEl testing automatizado también es aplicable en empresas pequeñas. No es sólo para Google, IBM y M$ (por nombrar algún ejemplo que se que ponen mucho foco en automatización de pruebas). Por qué? Pues a mi al menos no me da el tiempo de probar todo lo que quiero antes de liberar cada versión, sería muy costoso!… entonces el tener pruebas automatizadas que ejecuten más rápidamente, me soluciona este problema.Pero vayamos más allá y pensemos en el ROI de la automatización … no quiero entrar en algo muy detallado de esto, pero al menos ver una idea q compartió cemkaner en uno d sus artículos.Costos de automatizarhttp://www.kaner.com/pdfs/autosqa.pdfKener dice que automatizar una prueba lleva entre 3 y 10 veces más tiempo que ejecutarla en forma manual.Supongamos que tenemos pruebas diseñadas y datos para probar, incluyendo su valor esperado.Una prueba manual puede ejecutarse con 1 set de datos a la vez. Una prueba automatizada con todos los que se tengan (si la herramienta soporta data-driventesting). Si ejecutamos con 11 datos ya igualamos los beneficios. Si ejecutamos con más los superamos.Este beneficio se mantiene incluso considerando los Costos de mantenimiento, en un peor caso de que lleve 10x también reparar un caso de prueba ante una nueva liberación.
• #13: Además hay otros beneficios como documentar las funcionalidadesDejar registrados automáticamente los resultados de esas pruebas. Sacar luego estadísticas en base a eso.
• #15: Esto es algo q produce dolores de cabezaMás cosas de acá Visibilidad http://www.performancetesting.co.za/visibility.html 
• #16: Si bien la queja es d q el jefe no nos asigna horas, tmb está el problema de mostrarle el valor al resto d la empresa, jefe, desarrolladores, etc.Como testers a veces cuesta q nos valoren o nos den pelota. No?Tenemos q encontrar la forma de darle valor a lo q hacemos, y de mostrarle al resto del equipo.Un ejemplo, uno de nuestros clientes está por migrar a otra versión de Genexus, a la evolution 1. cómo las pruebas automatizadas pueden dar beneficios para esta situación en particular? Si automatizamos pruebas en laapp de hoy, la q esta en gx9, estamos testeando el sistema actual, y estamos facilitando la migración, ya q estamos aportando en gran forma a minimizar los riesgos al momento d migrarnos, pues al migrar vamos a tener un montón de pruebas q en unos minutos nos van a dar información de cómo esta el sistema. Fíjense que las pruebas automatizadas nos dan gran valor acá. Seguro que si mostramos q podemos hacer eso nos van a dar horas. Y así con un montón de situaciones en particular. Comenté eso q tal vez no es algo d todos los días, pero a los desarrolladores creo q les interesa ver fácilmente el estado d calidad del sistema antes d liberar una nueva version. Y al nombrar a los desarrolladores se me ocurre entrar en otro tema muy importante q es el de testing colaborativo. O sea, lo ideal sería lograr q se genere colaboración hacia los dos lados, q el tester colabore con el desarrollador y el desarrollador con el tester (como comentaban en la charla anterior cuando hablaban de hacer software testeable)Colaboración con carmen de consulting. Cómo el tester puede colaborar con el desarrollo, pero a su vez es importante que el desarrollador colabore con el tester, y le brinde por ejemplo procGX para inicializar datos, validar resultados, etc., o que agregue cierta información en pantalla de forma tal que le sea práctico al tester verificar lo que quiere verificar (esto no es sólo para cuando se usa Gxtest o automatización, sino en general, de modo de colaborar con la testeabilidad del software --nombrar charla de MW otra vez)
• #17: Les tiro otra cuestión. Si mañana se nos va alguien, un tester o analista, que tenía el conocimiento de cómo debía funcionar determinado módulo o funcionalidades. Menudo problema, no? Es un riesgo con el que siempre estamos. He aquí una forma de disminuir los impactos de este riesgo.Intentemos registrar el conocimiento sobre el comportamiento esperado de la aplicación. Si un especialista indica que es interesante verificar que la funcionalidad se comporta correctamente en determinada situación (un cliente no existe, etc) entonces al menos eso hay que registrarlo en un papel, en un inventario de pruebas, cosa de tener la posibilidad de volver a ejecutarlo a futuro. Mucho mejor si eso lo podemos automatizar fácilmente y agregarlo a la batería de pruebas. Servirá como documentación clara y NO ambigua del resultado esperado. Documentación con casos de pruebaDejar el know-how de testing en un formato ejecutable… un tc es entendible, legible, no ambiguo Si ponemos a testear a alguien q no sabe del negocio o de testing, seguro que los bugs que reporta no tengan tanto valor.
• #19: Pasemos a Otro problema jodido….No hay herramientas que solucionen todo….Hay gente que se hace mala sangre por estas cosas .. Fa!
• #20: Acá están imaginando que voy a decir “ta, pero gxtest la rompe, soluciona todos sus problemas”Pero no, no les voy a decir eso! Porque no es verdad!Una herramienta no soluciona todos los problemas, los vendedores de herramientas generalmente intentan convencer a la gente de eso…. Lo cual muestra que como vendedor soy un buen ingeniero.
• #21: Las herramientas no nos evitan el trabajo de pensar. Porsuerte :DHay empresas que han fracasado con automatización pero no por la herramienta, sino por no haber seguido el camino correcto. O sea, hay que pensar para priorizar y seleccionar y diseñar pruebas que den valor, y no automatizar cualquier cosa. Incluso una buena práctica podría ser, tomar la lista de casos de prueba que tenemos diseñados y revisar cuáles de esos vale la pena automatizar. No tienen por qué ser todos! Tenemos que pensar cuáles van a darme más valor. Cuáles van a ser fáciles de mantener, cuáles son críticos, cuáles me interesa probar siempre. Si automatizamos así no más sin pensar… vamos muertos.Citando una frase del libro de Software test automation, automatizar el caos nos traerá más caos, más rápido. Incluso escribimos algunas de estas ideas en un post de nuestro blog, y bueno, para darle un poco más de difusión lo tiramos por twitter, … y para nuestra sorpresa rápidamente Michael Bolton (un salado en testing) nos responde que no sólo más rápido, sino que logra intensificar el caos, y hacer que aparezca caos donde antes nadie se imaginó que podía haber caos!!Entonces una de las cosas q hay q tener es una estrategia…
• #22: Y se me viene algo a la mente… se acuerdan de starcraft?? Alguno tuvo que haber jugado a este juego, o a alguno similar.Esto es una imagen de la versión dos que salió hace uno o dos meses, pero yo recuerdo que jugué bastante a la primera versión. Y bueno, para que más o menos tengan una idea, uno se va formando sus tropas a medida va obteniendo recursos. Cada nave tiene un costo, y obviamente las naves poderosas grandes, con gran poder destructivo tenían un costo muy alto, y las pequeñas un costo menor. Entonces, uno hasta que no consigue crecer y tener muchos recursos, le cuesta tener una de esas naves gigantes, y es por eso que una estrategia válida es comenzar con pequeñas naves, que se construyen más rápido, tienen menor poder destructivo pero me van defendiendo como pueden de los ataques… y con el tiempo voy teniendo cada vez más y así uno va creciendo.En esto de la automatización la misma idea. Es preferible hacer una pequeña nave de batalla, que nos de beneficios inmediatamente, por más que sean pocos, pero que yo rápidamente esté viendo los beneficios, antes que esperar a tener una gran nave de batalla superpoderosa, que tal vez llega tarde, cuando ya no hay tiempo para defenderse de los problemas, o sea, cuando estemos por salir a producción!! Es mejor hacer pequeñas naves que cuesten menos recursos, y que día a día sumemos una nueva pequeña nave que nos vayan formando un gran ejército.O sea, aplicar soluciones goodenough como decía Jodal, y no soluciones perfectas, porque las soluciones perfectas llegan tarde. Ejemplo barnes
• #24: Este tipo me dice q se aburre, se desmotiva….Por más que lucho contra eso, intento convencer a la gente que el testing está de más, que me encanta, q lo hago hace tiempo, que estoy orgulloso de ser un tester je … me siguen diciendo que es un embole, que lo ven como algo aburrido. Que nadie quiere hacer eso. Que el testing lo resuelven poniendo al nuevo, o a un pasante. Si le va bien lo ascendemos y lo pasamos a desarrollo. Eso es algo que me cuesta cambiar, transmitir.Debe ir de la mano de las experiencias de cada uno desarrollando. Hace poco alguien me contaba….Bug reportado por un cliente en un sistema de facturación que se daba en la línea de producto 17 … reproducir el caso era un embole agregarlo a las pruebas de regresión … un embole al que le tocara eso
• #25: Yo creo q Acá es donde uno debe plantearse las cosas como Desafíos, para hacerlo de mejor forma, por ejemploCon test automático, lo hago una vez y taO mejor, lo hago una vez con una línea de producto, y agrego lógica al test case automático, para que agregue distinta cantidad de líneasEl uso d una herramienta le agrega otro desafío, nos evita muchos problemas, pero no el de pensar (y volver a machacar con eso de que hay que pensar, que la herramienta no es una barita mágica)-. Ahora, como decía el artista alemán hermanhesse… en todos los comienzos reside una fuerza mágica… pero q no afloje luego!!! O sea, a veces pasa q arrancan súper entusiasmados con la idea d automatizar y le ven mucho interesante al desafío técnico, etc., y después queda ahí. El tema es lograr adquirir hábitos. O sea, lograr aceitar los mecanismos, definir algún tipo de metodología para su grupo de forma tal de hacer q cada pequeño esfuerzo perduren en beneficios. Adquirir hábitosComprar una herramienta es como anotarse a un club. Lo único que haces es pagar. Luego, para que eso rinda hay que ir al club, aprender a hacer los ejercicios, usar los aparatos, etc. Adquirir nuevos hábitos!Fuente: http://www.stickyminds.com/sitewide.asp?ObjectId=10695&Function=DETAILBROWSE&ObjectType=COL&sqry=*Z(SM)*J(COL)*R(relevance)*K(advancesite)*F(automation)*&sidx=1&sopp=10&sitewide.asp?sid=1&sqry=*Z(SM)*J(COL)*R(relevance)*K(advancesite)*F(automation)*&sidx=1&sopp=10 En todos los comienzos reside una fuerza mágica --Hermann HesseNo quedarse con el entusiasmo del comienzo y dejarlo ir luego. Hay que lograr que las nuevas prácticas se establezcan como metodologías, como hábitos.Si ejecuto las pruebas y pasan todas OK, perdí el tiempo??? -- no! Pues esa información también es valiosa, es vital! Me da seguridad de que esas pruebas pasaron y que estamos más firmes para salir.
• #27: A modo de resumen ….Me podrán decir que No tienen Tiempo! Que automatizar es muy Costoso! Que no les gusta su jefe! (digo, que no les asigna horas a automatizar), que No hay herramientas mágicas, que están desmotivados!Ya no les creo, no me como ninguna, no tienen excusas, si quieren mejorar la calidad de sus productos, si quieren hacer testing en forma eficiente, aprovechen al máximo los beneficios de la automatización!
• #28: Pueden bajar una trial aquíAgradecemos a los que nos apoyaron en el período de betatesters, en este evento estamos anunciando la salida de la versión final de Gxtest 1.1 que cuenta con más funcionalidades y más trayectoria automatizando pruebas de distintos sistemasLes recomiendo quedarse en este mismo salón ya que se viene otra charla del track de testing en la que van a poder oir testimonios de usuarios de GXtest