CALIDADPERSPECTIVA46pág.agosto 2011van más allá del simple análisis de costo/beneficio. Y, en general, estaalternativa surge cuando aparece alguno de estos inconvenientes:» imposibilidad de realizar pruebas manuales para la magnitud ocomplejidad requerida;» necesidad de ampliar la cobertura de las pruebas sin aumentar losesfuerzos de ejecución de regresiones y» sofisticación artificial del proceso de pruebas definido para la organización.El ejemplo que vimos al inicio es la mejor descripción del primerode estos puntos. Ahora, ¿qué pasa cuandonecesitamos ampliar la cobertura? La automatizaciónde pruebas funcionales aparececomo una solución para comoditizar la ejecuciónde ciclos de prueba, simplificando losesfuerzos necesarios para su realización ydejando recursos humanos disponibles paraabarcar una mayor cantidad de proyectos ocontinuar el desarrollo de scripts que permitan mejorar la razón entrepruebas automatizadas y manuales. Esto es usual en organizacionesque han acumulado experiencia suficiente como para entender losbeneficios de la automatización desde la operación.El otro camino por el que las organizaciones llegan a la automatizaciónes el de la creencia de que la herramienta hace al proceso, pensamientoque hace ir rápido desde el deseo hasta la compra de herramientas.Este enfoque usualmente termina con un gasto innecesario y la mismaoperación de siempre (pero con licencias olvidadas en un cajón).Una de mis formas favoritas de llegar a la automatización es laincorporación de automatizaciones de pruebas unitarias y funcionalescomo parte del proceso de desarrollo, ya sea apuntando aesquemas de integración continua o como parte de una estrategiaque permita simplificar las pruebas de sistemas con alta variación(estableciendo pruebas unitarias con los apoyos de jUnit, phpUnit,nUnit o la que mejor se adapte).Incorporar prácticas del tipo testing first no sólo apunta a beneficiosEn mi experiencia, la decisión sobre automatizar (parte o totalidadde las pruebas funcionales manuales) abarca cuestiones que van másallá del simple análisis de costo/beneficio.futuros por los ahorros asociados a la disminución de esfuerzos, sinoque además permite disminuir errores como subproducto de su utilización.El desarrollador debe ser capaz de comprender las entradasy salidas de cada función o método en etapas tempranas (inclusoantes de programar) disminuyendo la incertidumbre y asegurandoconsistencia entre los requerimientos y las funciones a implementar.Realizar pruebas unitarias automatizadas al finalizar el desarrollode un conjunto de funciones o métodos resulta extraordinariamenterápido, y aumenta significativamente las posibilidades deQA de recibir código medianamente testeable, ya sea para realizartesting manual o para comenzar a generar los scripts para pruebasfuncionales automatizadas, que (adivinaron) se pueden concentraren temas de integración y ejercicios de punta a punta.fuerzo, así que debemos estar seguros de que reutilizaremos esos casosautomáticos muchas veces (como ya decía James Bach en Test AutomationSnake Oil, allá por el año 1999).Volviendo a mi pregunta (y simplificando), las respuestas que recibose pueden clasificar en tres grupos: No, más o menos y sí.Si usted se encuentra en el primer grupo, debe primero trabajar en elproceso de testing manual, generando una base de casos de prueba, ciertoconocimiento de la funcionalidad implementada y un conjunto de casosque realmente deban ser reejecutados siempre que sale un nuevo release.Tener un proceso de testing manual definido y funcionando significatener un proceso acordado con todos los stakeholders que refleje lasactividades y entregables “de mínima” que se deben lograr.Resumiendo, debe trabajar para pasar a los grupos siguientes.A los que contestan “más o menos”, debería decirles que no existe el“más o menos” y que muy probablemente estén en el primer grupo. Sihay dudas sobre el proceso de testing será porque no lo aplicamos sistemáticamenteo porque no está documentado (o porque, aun estandodocumentado, se utiliza en forma reducida). Tener un proceso de testingmanual definido y funcionando significa tener un proceso (acordadocon todos los stakeholders) que refleje las actividades y entregables “demínima” que se deben lograr. A modo de ejemplo, hay tres registros quesiempre deben estar presentes: de pruebas, de casos de prueba y de ejecucionese incidentes.Son los representantes del tercer grupo los que sí pueden pensar en eltema de control automático pleno. Sin embargo, considero que hay muypocos casos en los que vale la pena invertir tiempo y dinero en unaautomatización total. Google podría ser uno de esos casos, ya que elcosto de un error en las aplicaciones de su tipo es muy alto, y cualquierfalla se multiplica por millones de usuarios.En otros casos la necesidad de automatizardisminuye drásticamente. Porejemplo, en un entorno empresarialdonde el área de TI desarrolla sistemasde información que serán consumidospor una cantidad sensiblemente menorde usuarios. En los momentos en losque estamos desarrollando (y probando) un sistema por primera vez, elfoco de la prueba está puesto en lograr que el sistema se estabilice. En esecontexto, casi todas las pruebas son de primera vez y el nivel de repeticiónes menor. La automatización aquí suele surgir cuando requerimos haceralgunas regresiones dentro del proceso iterativo de desarrollo; de otromodo trabajamos primero en forma manual.Es en los sistemas ya desarrollados, en fase de mantenimiento, donde esmás factible automatizar, siempre y cuando debamos realizar pruebas deregresión extensas, puesto que en esos sistemas (donde las modificacionesson quirúrgicas) automatizar la prueba tampoco repaga.En síntesis, la estrategia a seguir debe elegirse proyecto por proyecto. Nohay que perder de vista que el esfuerzo/costo de automatización deberápoder amortizarse con el uso de los scripts a lo largo del tiempo.
TECNOLOGÍAbusinessintelligencepor que hacerlo dificil cuando puedes hacerlo... AGILCon una sonrisa y elmayor de los respetos,acompáñennos a presenciarlas vicisitudes de este usuarioque quiere “sumarizar lasventas del mes”.PERSPECTIVALa historia como FRECUENTEMENTE es...¡¡¡PARÁ!!!NECESITO REALIZAR ESTE CAMBIOMENOR EN EL TABLERO PARA QUESUMARICE LAS VENTAS DEL MESESTO ES COMPLEJO... NOS VA A LLEVAR TIEMPO.HAY QUE VER SI NECESITAMOS EXTRAER INFORMACIÓNDE OTRO SISTEMA Y REDEFINIR LAS ENTIDADES.OJO, QUE SEGURAMENTE VAMOS A TENERQUE REARMAR LOS CUBOS.Y SI MAL NO RECUERDO, EL ETL DEL SISTEMA DEVENTAS QUE USAN USTEDES ES COMPLEJO.VAMOS A TENER QUE HACER UNA REINGENIERÍA.LO TENEMOS QUE ESTIMAR...CREO QUE SERÁN UNOS CUÁNTOS MESES,¡EH!PM BIvíctima¿SEGURO SERÁ TANTO?, MIRÁQUE ES SUMAR DOS CAMPITOS...un mes despues...AH, ¿PERO NOSABÍAS? ESTO ESBI... ES ALGOCOMPLEJOMIRÁ, ESTÁ LISTO EL ETL; PERO NO TE PUEDOMOSTRAR NADA..., ES ALGO TÉCNICO, YO CREO QUEEN UN MES TENEMOS EL PROTOTIPO... IGUAL,FIJATE QUE EL GANTT ESTÁ AL 50%.VAMOS BIEN.ESTÁ LISTO PARA LA APROBACIÓNFINAL, IGUAL CREO QUE ES UNAFORMALIDAD...¡ESTO NO ES LO QUEYO QUERÍA!PERO EN LA ERSLO DECÍACLARAMENTE…A VER…TE ESCUCHO…AH, PERO SI ES ESO,ME VA A LLEVAR DOS OTRES SEMANAS MÁS¡plop!pág.47julio 2011PM BITextos: Julián Ceci y Pablo ParnisariDibujos: Victoria Meléndez y Melisa Silvacontinua
Change language