Page 30 - REVISTA 2016

En cuanto a herramientas, se suelen aprovechar las facilidades de las máquinas virtuales, así como otras más
avanzadas como Docker y Kubernetes. Para el problema de los dispositivos mobile existen varias soluciones para
evitar tener que comprar decenas de dispositivos y mantenerlas mes a mes, desde laboratorios compartidos has-
ta soluciones en el Cloud que nos dan acceso a los dispositivos que necesitemos pagando solo por uso.

Para nuestro entorno de integración continua, y apuntando a un “testing continuo”, necesitaremos tener
resueltos los ambientes y entornos necesarios para la ejecución de pruebas garantizando que no haya
problemas ajenos a los problemas que estamos buscando identificar.

El testing funcional

Este punto está asociado a la gestión de la calidad, pero enfocado en el aspecto funcional (¿hay bugs?). O
sea, enfocado en qué tan bien funciona el software ¿tengo los riesgos controlados? ¿sé lo que estoy pro-
bando, lo que ya probé y lo que me falta? ¿Qué tan “profundo” estoy probando?

Desde nuestro punto de vista, hay tres formas de hacer y gestionar el testing funcional:
Ad-hoc: equivalente a pedirle a alguien cualquiera que “pruebe un rato” el sistema. Esto es típico de aquellos
que ven el testing como algo que es sentarse frente al software y hacer clics mirando “cómo está”. Esto no tiene
control, no es posible dar seguimiento, ni conocer qué tan bien o mal nos va. El testing es información sobre la
calidad, y esto no nos da información.
Testing Planificado: primero hay que pensar qué es lo que queremos probar, lo documentamos, y luego toma-
mos ese documento y lo ejecutamos, registrando qué anduvo bien y qué anduvo mal. El jugador estrella en este
enfoque es el “caso de prueba”. Las dos etapas, la de diseño y la de ejecución, están tan separadas que podrían
hacerlas dos personas distintas, con distintas habilidades. Un experto del negocio y con conocimiento en diseño
de casos de prueba podría crear una planilla con todos los casos que resultan interesantes para probar. Luego,
otra persona que quizá no tenga tanta experiencia, toma esa planilla y ejecuta el paso a paso especificado, indi-
cando cuáles ejecutó y qué resultado dio cada uno. Es ideal para planificar, dejar registro de todo lo que se hizo,
organizar al equipo y analizar qué tan profundo se probó cada cosa. Es ideal para el test de regresión, para pasarle
conocimiento a una nueva persona de qué cosas se prueban, y es ideal para documentar el comportamiento
esperado del sistema.
Testing Exploratorio: con el advenimiento de las metodologías ágiles y el foco en la adaptación al cambio, el caso
de prueba pierde relevancia. No podemos esperar a tener documentos que nos indican qué ejecutar y cuál es
el resultado esperado para poder transmitir una idea de qué tan bien o mal funciona el sistema. Es por esto que
existe este enfoque de testing exploratorio, donde el foco está en diseñar y ejecutar al mismo tiempo, mientras
además se va conociendo y aprendiendo del sistema. El foco está en encontrar errores y riesgos lo antes posible.
Además, uno se puede adaptar más fácil al cambio, ya sea de la aplicación como del contexto. No se necesita
mantener documentos de casos de prueba y esto nos da más flexibilidad. Cada acción se toma en base al resul-
tado que se obtiene, decidiendo (y diseñando la prueba) sobre la marcha. Pero ojo, esto no es ad-hoc, hay una
metodología muy bien definida para poder seguir el esquema que nos permite organizarnos, darle seguimiento,
control y gestión a todo el proceso. Se apunta a mejorar ciclo a ciclo y a no ejecutar siempre lo mismo (ya que esto
es aburrido, propenso a errores, y es mejor que lo ejecute una prueba automática ya que es solo un chequeo).

Los casos de prueba suelen reportarse o bien en planillas de cálculo, o en herramientas específicas para esto,
como por ejemplo Testlink, por nombrar una muy popular y opensource. Las alternativas más ágiles son las se-
siones de prueba, checklists de revisión y los mind-maps, para registrar ideas de prueba más que una lista de
acciones paso a paso de qué probar. En cualquiera de las estrategias algo fundamental es tener idea de qué es el
todo (el total de casos de prueba, el total de funcionalidades a probar, las historias de usuario que hay que cubrir,
etc.), y cuánto vamos avanzando. Esto es lo que nos permite notificar la cobertura que estamos logrando. Esto por
supuesto que es necesario priorizarlo de acuerdo a la importancia y riesgo para el negocio y para los usuarios.

32 Revista de la Facultad de Ingeniería