PERSPECTIVA l hombre y la máquina. Esta relación siempre trajo

PERSPECTIVA
CALIDAD
¿AUTOMÁTICO
l hombre y la máquina. Esta relación siempre trajo consigo
una dicotomía. A lo largo de los años y a medida que avanzaba la tecnología, esta división se fue reafirmando y tomando
distintas formas: desde los obreros ludistas a principios del
siglo XIX que veían en las máquinas a su mayor enemigo,
hasta los que creen que en ellas reside la base de toda utopía,
pasando por todos los tipos de grises posibles.
A una escala menor y en la industria del testing de software, vemos el mismo
fenómeno. ¿Hasta qué punto es posible automatizar estos procesos? ¿Hay que
desterrar del mapa los procesos manuales? ¿Los procesos automáticos dejan de
lado posibles errores humanos? ¿Cuáles son los pros y los contras de ambos?
En este contrapunto, dos especialistas abren el debate y señalan lo mejor (y lo
peor) de cada uno de los modelos.
E
pág.
agosto 2011
44
PERSPECTIVA
CALIDAD
MANUAL?
Practia Consulting Chile
Yo, robot
Ernesto
KISZKURNO
socio Pragma Consultores Argentina
Reivindicando el testing manual
Hace un par de años, una relevante empresa del ámbito financiero
En una interesante serie de posts en el blog de testing de Google, James
Whittaker, director de Test Engineering, contó cómo se hace testing en
tenía un sistema de pago de servicios en que había comportamiento
esa empresa. Allí refleja una de las disyuntivas a las que se enfrenta todo
distinto (y, por tanto, no extrapolable a partir de pruebas similares)
responsable del área de calidad: el dilema de la automatización.
dependiendo de los datos de entrada. Según la primera estimación
Con este concepto me refiero a las dudas que comúnmente tienen los
que se hizo para ese test manual, se requerían alrededor de 20 díasequipos de pruebas a la hora de decidir qué, cómo, cuándo y dónde auhombre. Luego de un ajuste, ese número aumentó a 450 días. Este
tomatizar. Estoy pensando en automatización
plazo era impensable, ya que la fecha de puesta en producción esfuncional, principalmente, porque en pruebas
taba comprometida y Marketing ya estaba trabajando en el anuncio de modernización del
de estrés, carga o volumen la automatización es,
sistema. Así, pusimos manos a la obra. Nos volcamos hacia la automatización; en menos
en cierto sentido, ineludible.
de una semana diseñamos scripts modulares y generamos tablas de datos que simularan
Este conflicto aparece en distintos momentos:
la totalidad de los casos posibles (incluyendo resultados esperados). Ejecutamos todas
como pregunta típica en los cursos, al momenlas pruebas −con al menos cuatro iteraciones−, hasta que la cantidad de incidentes dejó
to de definir estrategias de pruebas de futuros
de ser una alarma. La aplicación salió a producción en forma, tiempo, costo y calidad.
proyectos y en el día a día del testing. Y cuando
¿Qué busco ejemplificar aquí? Que las herramientas de automatisurge la disyuntiva, siempre contesto con esta pregunta: ¿el proceso de
zación de pruebas son una tecnología habilitante ya que permiten
testing funcional manual está definido y funcionando?
hacer tareas necesarias, pero imposibles de realizar manualmenLa meta de lograr un ciento por ciento de pruebas automáticas es muy
te. Sin embargo, más allá de la evidente ventaja, creo que la autoseductora. Todos nos hemos planteado lograr algo así. El problema es
matización de pruebas funcionales en sí misma no debe ser nunca
que, en la vida real, para automatizar primero hay que poder testear
una meta, sino una alternativa.
manualmente, y antes es necesario tener claro lo que significa testear.
En mi experiencia, la decisión sobre automatizar (una parte o la totaPor otro lado, automatizar requiere más desarrollo y, por ende, más eslidad de las pruebas funcionales manuales) abarca cuestiones que
pág.
45
agosto 2011
Alejandro
NÚÑEZ GUARDIA
PERSPECTIVA
CALIDAD
van más allá del simple análisis de costo/beneficio. Y, en general, esta alternativa surge cuando aparece alguno de estos inconvenientes:
» imposibilidad de realizar pruebas manuales para la magnitud o
complejidad requerida;
» necesidad de ampliar la cobertura de las pruebas sin aumentar los
esfuerzos 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 primero
de estos puntos. Ahora, ¿qué pasa cuando
necesitamos ampliar la cobertura? La automatización de pruebas funcionales aparece
como una solución para comoditizar la ejecución de ciclos de prueba, simplificando los
esfuerzos necesarios para su realización y
dejando recursos humanos disponibles para
abarcar una mayor cantidad de proyectos o
continuar el desarrollo de scripts que permitan mejorar la razón entre
pruebas automatizadas y manuales. Esto es usual en organizaciones
que han acumulado experiencia suficiente como para entender los
beneficios de la automatización desde la operación.
El otro camino por el que las organizaciones llegan a la automatización
es el de la creencia de que la herramienta hace al proceso, pensamiento
que hace ir rápido desde el deseo hasta la compra de herramientas.
Este enfoque usualmente termina con un gasto innecesario y la misma
operación de siempre (pero con licencias olvidadas en un cajón).
Una de mis formas favoritas de llegar a la automatización es la
incorporación de automatizaciones de pruebas unitarias y funcionales como parte del proceso de desarrollo, ya sea apuntando a
esquemas de integración continua o como parte de una estrategia
que 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 beneficios
fuerzo, así que debemos estar seguros de que reutilizaremos esos casos
automáticos muchas veces (como ya decía James Bach en Test Automation Snake Oil, allá por el año 1999).
Volviendo a mi pregunta (y simplificando), las respuestas que recibo
se pueden clasificar en tres grupos: No, más o menos y sí.
Si usted se encuentra en el primer grupo, debe primero trabajar en el
proceso de testing manual, generando una base de casos de prueba, cierto
conocimiento de la funcionalidad implementada y un conjunto de casos
que realmente deban ser reejecutados siempre que sale un nuevo release.
Tener un proceso de testing manual definido y funcionando significa
tener un proceso acordado con todos los stakeholders que refleje las
actividades 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. Si
hay dudas sobre el proceso de testing será porque no lo aplicamos sistemáticamente o porque no está documentado (o porque, aun estando
documentado, se utiliza en forma reducida). Tener un proceso de testing
manual definido y funcionando significa tener un proceso (acordado
con todos los stakeholders) que refleje las actividades y entregables “de
mínima” que se deben lograr. A modo de ejemplo, hay tres registros que
siempre deben estar presentes: de pruebas, de casos de prueba y de ejecuciones e incidentes.
Son los representantes del tercer grupo los que sí pueden pensar en el
tema de control automático pleno. Sin embargo, considero que hay muy
pocos casos en los que vale la pena invertir tiempo y dinero en una
automatización total. Google podría ser uno de esos casos, ya que el
costo de un error en las aplicaciones de su tipo es muy alto, y cualquier
falla se multiplica por millones de usuarios.
En otros casos la necesidad de automatizar disminuye drásticamente. Por
ejemplo, en un entorno empresarial
donde el área de TI desarrolla sistemas
de información que serán consumidos
por una cantidad sensiblemente menor
de usuarios. En los momentos en los
que estamos desarrollando (y probando) un sistema por primera vez, el
foco de la prueba está puesto en lograr que el sistema se estabilice. En ese
contexto, casi todas las pruebas son de primera vez y el nivel de repetición
es menor. La automatización aquí suele surgir cuando requerimos hacer
algunas regresiones dentro del proceso iterativo de desarrollo; de otro
modo trabajamos primero en forma manual.
Es en los sistemas ya desarrollados, en fase de mantenimiento, donde es
más factible automatizar, siempre y cuando debamos realizar pruebas de
regresión extensas, puesto que en esos sistemas (donde las modificaciones
son quirúrgicas) automatizar la prueba tampoco repaga.
En síntesis, la estrategia a seguir debe elegirse proyecto por proyecto. No
hay 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.
En mi experiencia, la decisión sobre automatizar (parte o totalidad
de las pruebas funcionales manuales) abarca cuestiones que van más
allá del simple análisis de costo/beneficio.
pág.
agosto 2011
46
futuros por los ahorros asociados a la disminución de esfuerzos, sino
que además permite disminuir errores como subproducto de su utilización. El desarrollador debe ser capaz de comprender las entradas
y salidas de cada función o método en etapas tempranas (incluso
antes de programar) disminuyendo la incertidumbre y asegurando
consistencia entre los requerimientos y las funciones a implementar.
Realizar pruebas unitarias automatizadas al finalizar el desarrollo
de un conjunto de funciones o métodos resulta extraordinariamente rápido, y aumenta significativamente las posibilidades de
QA de recibir código medianamente testeable, ya sea para realizar
testing manual o para comenzar a generar los scripts para pruebas
funcionales automatizadas, que (adivinaron) se pueden concentrar
en temas de integración y ejercicios de punta a punta.