La Navaja Suiza de las Pruebas Automatizadas y El Factor Humano.

Dentro de los ciclos de desarrollo de software las pruebas automatizadas toman un papel cada vez más relevante como un mecanismo de aseguramiento de calidad durante la construcción del valor incremental de las distintas soluciones, y es que, no es de extrañar si consideramos los múltiples beneficios que este tipo de prueba trae consigo:

- Mayor confiabilidad de las pruebas: evita los posibles errores humanos en la ejecución de los pasos a seguir para llegar a un resultado esperado.

- Son altamente re-utilizables: Escribes una prueba, la ejecutas N veces.

- El tiempo; si bien inicialmente la construcción de las pruebas automatizadas puede demorar en contraste de una prueba manual, a mediano y largo plazo este gasto temporal se ve retribuido con tiempos de ejecución breves, re-test mucho más rápidos y la capacidad de realizar regresiones a un costo mucho menor. Debemos considerar además que mientras mayor es la cantidad de pruebas automatizadas que se construyen sobre un producto, el tiempo de estas va disminuyendo gracias a la reutilización de código.

- La escalabilidad de las pruebas: Las pruebas de performance son un buen ejemplo de cómo la automatización permite construir casos escalables (en cantidad, tiempo, recursos, etc…) que utilizando pruebas manuales serian imposibles de conseguir.

Estos son solo algunos de los beneficios de las pruebas automatizadas, podría mencionar una lista más completa que puedes encontrar en sitios como “Javatpoint”.

Dentro de los requisitos para realizar pruebas automatizadas se encuentra el conocimiento que el propio QA-Tester-Ingeniero de Calidad (llámese como más le acomode, de aquí en más le diré QA Automation) debe tener de las herramientas a utilizar, dentro de estas podemos mencionar; lenguajes de programación, Frameworks, conocimiento de BD, por ejemplo, y algunas otras habilidades técnicas propias del campo, en otras palabras (y por muy obvio que suene), la construcción de pruebas automatizadas requiere conocimientos de programación. Esto tiene consecuencias en la forma en que se busca a los candidatos para los puestos de automatizadores de pruebas, dando especial énfasis a estas habilidades fundamentales para el ejercicio de la profesión. A su vez, desempeñarse como QA Automation en un equipo de desarrollo no se limita solamente a los conocimientos técnicos que podamos tener sobre una herramienta en particular o un Frameworks para pruebas, se requiere una perspectiva diferente que permita planificar pruebas que realmente pongan a prueba el producto testeado. Si bien, tenemos técnicas como la buena escritura de historias de usuario que incluyen casos y/o criterios de aceptación que ofrecen un piso mínimo para lo que se debe testear existe en “las sombras” un amplio espectro de lo que no se explicita y que tiene relación directamente con las posibilidades de acción humana dentro de un aplicativo cualquiera. Veámoslo con un ejemplo (simplificado):

Como: Alumno

Quiero: Contar con un formulario que me permita ingresar mi nombre, mi mail y enviar una foto de mi pase escolar.

Para: Poder inscribirme en la actividad de fin de semestre

Criterios de Aceptación:

           - Se puede ingresar el nombre completo

           - El mail debe ser el de la universidad

           - La imagen debe ser JPG

           - Se deben completar todos los datos antes de enviar el formulario.

La construcción de casos de prueba, como es evidente, debiese iniciar por la validación de estos criterios de aceptación para profundizar en aspectos no implícitos del caso, como: ¿Cuántos caracteres soportará el nombre completo? ¿ese límite es aceptado en la BD donde persiste la información? ¿existe una validación nombre/mail? ¿Qué ocurre si me registro por segunda vez? ¿la imagen tendrá un máximo de tamaño y peso? ¿si habilito por código el botón para enviar el form que ocurre?, podríamos seguir, pero creo que la idea es clara.

Un QA automation, debiese ser capaz de identificar casuísticas de este tipo que no son implícitas y en muchos casos se dan por obvias para la construcción de casos de negocio pero que no lo son cuando el producto llega a los clientes. Como aclaración, estas interrogantes en un equipo de desarrollo maduro se pueden presentar en instancias como el refinamiento y ser añadidas a los criterios de aceptación, aun así, lo importante de señalar es que sigue siendo algo completamente humano, e inclusive en historias de usuario o casos de negocio muy refinados suelen aparecer interrogantes cuando el producto ya es utilizable o se encuentra en etapas de pruebas.

La perspectiva del cliente es uno de los desafíos a alcanzar, literalmente pueden darse tantas casuísticas de uso de una aplicación X como componentes tengas en ella elevados a N. Inclusive en una aplicación muy cuidada dentro de lo que se puede y no se puede hacer en ella tienes el factor del navegador web, como un agente “externo” que puede ser relevante para el funcionamiento de la aplicación y cuyas acciones pueden ser débilmente controladas desde la propia aplicación.

Según mi experiencia, el factor humano y la capacidad del QA automation de abstraerse de las propias pruebas preconcebidas y generar casos que busquen conocer los límites de funcionalidad de una aplicación es una de las cosas más difíciles de hacer en el día a día.

En este sentido, las herramientas de automatización de pruebas son solo eso, herramientas que permiten al ingeniero crear los casos de pruebas con todos los beneficios que mencioné anteriormente, sin embargo, creo están lejos de ser el factor crítico a la hora de asegurar la calidad de un producto utilizado por humanos.

Un proyecto o arquetipo robusto de automatización es una navaja suiza con la que podríamos construir pruebas a Apis, BD, aplicaciones web y mobiles, etc, con facilidad, pero representan solo el medio para llegar a ellas y no debería volverse el fin absoluto de ningún proceso de calidad. El factor Humano es tanto más importante en este caso y es allí adonde deberíamos apuntar a fortalecer los perfiles de ingenieros de calidad, al menos hasta que una inteligencia artificial como skynet sea capaz de imitar por completo el comportamiento humano, incluso el más absurdo (esperemos que no).

La Navaja Rota

Darle mayor énfasis al proyecto o arquetipo de automatización como el medio para alcanzar pruebas efectivas pareciera tener otra consecuencia que ya ha sido enormemente discutida en equipos de desarrollo large-solutions; la dañina dependencia de terceros.

Al utilizar lenguajes como Python, Java o JavaScript (como ejemplo) para la construcción de las pruebas automatizadas se suele tener la tendencia - ¿natural? - a añadir librerías para solucionar cualquier tipo de inconvenientes o requerimientos en nuestro código, incluso he visto como se integran librerías para solucionar problemas lógicos que podrían resolverse generando código personalizado a mano. Si bien en apariencia, integrar rápidamente una librería externa puede parecer la mejor solución por su facilidad y rapidez, el exceso de ellas trae consigo el aumento drástico (en muchos casos) de las dependencias externas lo que en muchos casos se traduce en lo que es conocido como el “Dependecy Hell”.

Se ha demoniado Dependency Hell al conjunto de problemas que ocurren producto de las dependencias desactualizadas, que dejan de estar disponibles o que -chocan- en sus subdependencias con otras librerías. Este último caso es el mas preocupante pues encontrar el problema real suele ser costoso en horas hombre por la propia dificultad de encontrar un error poco evidente relacionado a una librería sub-requerida por alguna dependencia instalada.

Este posible problema se puede tornar grave si consideramos que en gran medida el beneficio de la automatización de pruebas es poder realizar regresiones de las mismas en el tiempo; supón el caso donde por una actualización de la versión de Python soportada en el servidor (ejemplo una versión legada que deba ser parcheada por seguridad) hace imposible ejecutar un conjunto grande de pruebas, al realizar un análisis exhaustivo te percatas que el problema es que ciertas sub-librerias (aquellas dependencias dentro de otras dependencias) requerían a su vez una versión especifica de otra librería que ya no está disponible. Esto arruinaría el conjunto de pruebas y obligaría a invertir tiempo externos en corregir el problema, que probablemente se solucioné instalando otra librería.

Pero esto nos e trata de satanizar las dependencias (¡¡Que haríamos sin selenium, behave o los clientes de BD!!!) porque es claro que dentro de los principios del desarrollo de software está el no inventar la rueda dos veces, sin embargo, también resulta dañino el exceso de dependencias, sobre todo en aquellos casos donde es probable que crear una solución a la medida sea el camino más sensato a largo plazo.