Llevo más de 14 años trabajando en el sector de IT y durante los últimos seis años he sido jefa de equipo de pruebas. Mis responsabilidades incluyen el desarrollo de estrategias de pruebas desde las fases iniciales del proyecto. Como todos, estamos intentando implementar autotests para acelerar el proceso, aumentar la cobertura de las pruebas y, básicamente, facilitar la vida y el trabajo para nosotros.
Creo que este artículo, que se basa en la experiencia de nuestro equipo, será útil para aquellos que están empezando a construir su propio proceso de automatización de pruebas y para quienes no están satisfechos con lo que están obteniendo de las pruebas hasta ahora.
Aclaro de entrada que no me meteré en detalles técnicos, ni enumeraré herramientas específicas: esto requiere un enfoque individual en función de la aplicación y del equipo específico. En su lugar, me centraré en cómo desarrollar un enfoque y una estrategia general.
Compartiré las ideas principales y los obstáculos que ya hemos encontrado en nuestro equipo, e intentaré ayudarte a evitar estos errores en el futuro. Si bien hay algunas cuestiones que pueden parecer obvias para quienes ya tienen experiencia en automatización, igualmente vale la pena volver a lo básico y recordar reglas sencillas que suelen olvidarse con el tiempo.
Entonces, empecemos.
Cómo arrancar a formar una estrategia
Creo que todo el mundo ha recibido mensajes de usuarios sobre errores que no fueron detectados por los autotests. Dicho esto, los usuarios también pueden ser poco atentos. No siempre entendemos perfectamente los matices del negocio para el que estamos desarrollando un producto o no podemos cubrir todos los escenarios posibles.
Por ejemplo, el siguiente caso es uno que tuvimos en un entorno de prueba. El probador siguió el enlace y comprobó que se abría una nueva página. Sin embargo, la apertura de una página que indicaba "No está autorizado a ver esta página" también pasó la prueba, aunque no fuera un escenario exitoso.
Por lo tanto, el problema sigue existiendo aunque la prueba haya tenido éxito. En cualquier caso, el proceso puede mejorarse y las pruebas automáticas son una herramienta poderosa para hacerlo.
Lo mejor es comenzar la automatización de las pruebas aplicando una pirámide estándar a todo el trabajo realizado. Esta pirámide se basa en las pruebas unitarias y de integración de los desarrolladores.
La automatización debe tener en cuenta la frecuencia de un determinado tipo de pruebas, así como también su necesidad y sus riesgos. Por lo tanto, las pruebas de humo son las siguientes en ser automatizadas. Luego, el equipo pasa a las pruebas funcionales o de regresión. Y después de eso, se pueden implementar las pruebas automatizadas en el nivel de entrega continua; todo a su debido tiempo.
Paso 1. Elegir la funcionalidad para la automatización
Si ya hay casos de prueba escritos de antemano, eso es bueno. Y construiremos un análisis basado en ellos. Si no hay casos de prueba, será momento de escribirlos.
Prestemos atención a los siguientes puntos.
¿Es posible, en principio, automatizar ciertos escenarios? ¿Y es aconsejable? Por ejemplo, una entrada en la base de datos aparecerá en media hora o en una hora después de ser añadida. ¿Tiene sentido que el autotest espere a esto? En principio podemos esperar, pero ¿aceleraremos el proceso de prueba en su conjunto en este caso?
Después de todo, acelerar el proceso es prácticamente el objetivo principal de la automatización. Resulta que es necesario reemplazar las pruebas manuales en un proceso de este tipo, sólo si queremos salvar por completo a nuestro Manual QA de tener que involucrarse.
Y si el escenario es sencillo y la comprobación es cosa de una sola vez, ¿es necesario dedicarle tiempo a la automatización? En teoría sí, sobre todo si el cliente exige automatizar "absolutamente todo". Pero hay que tener en cuenta que esto, inevitablemente, conlleva costos adicionales. ¿Estás preparado para estos costos adicionales en el proyecto actual? ¿Tal vez deberíamos echar un vistazo más de cerca a algo que tenga mayor importancia?
Por último, si los datos para la prueba necesitan ser cuidadosamente seleccionados cada vez de forma manual, ¿tiene algún sentido la automatización? No siempre es posible que los sistemas financieros complejos hagan una solicitud universal de información. ¿Es una buena idea en su caso generar manualmente los datos cada vez que se ejecuta un autotest?
También hay pruebas en las que una persona es más rápida y es más probable que note un error. ¿Yo debería crear comprobaciones para las expectativas necesarias utilizando scripts?
¿Resultarán rentables los recursos invertidos en la automatización? A primera vista, la automatización de una prueba específica parece simple. Sin embargo, una vez que nos ponemos a trabajar vemos que en la implementación actual -o bajo ciertas condiciones- requerirá recursos significativos. Pensemos si tenemos tiempo y si el cliente está dispuesto a pagar por ello.
¿Es necesario automatizar las pruebas sencillas? ¡Por qué no! Tal vez deba buscar las 500 líneas de datos en JSON. Una vez, yo mismo tuve que comparar JSON con datos dispersos en un archivo de Excel el día previo al lanzamiento. No diré que la prueba era demasiado difícil, pero con la máxima concentración me llevó siete horas. Por supuesto, luego de ese incidente automatizamos el proceso.
¿Y los complejos, con cálculos matemáticos? ¡Sin duda! Así se garantiza la precisión necesaria en los cálculos y se elimina el factor humano.
Paso 2. Asegurarse de que los casos de prueba existentes estén listos para la automatización
¿Qué significa "listos para la automatización"? Empecemos por el diseño.
En muchos sistemas de gestión de pruebas, se puede añadir un atributo que permite identificar si la prueba necesita ser automatizada (también se indica el motivo) o si ya está automatizada. En mi experiencia, esto es muy conveniente ya que resulta más fácil filtrar y determinar la cobertura.
Escribir casos de prueba claros y detallados en general, así como mantener una buena documentación, es un verdadero arte. Es una buena práctica recurrir a una revisión de los casos de prueba, la cual puede realizar uno de sus colegas que forme parte del equipo de pruebas como también un jefe o un analista de negocio.
Un punto de vista externo siempre es útil, ya que esta persona puede asegurarse de que no se haya pasado nada por alto y además puede ver el proyecto desde el punto de vista de un BA. Este enfoque confirmará que hemos cubierto todos los requisitos y escenarios del usuario.
Al seguir comprobando los casos de prueba, recomiendo prestar atención a los siguientes puntos:
1. ¿Los casos de prueba están escritos por probadores manuales? A menudo ellos escriben los casos de prueba. Es estupendo que los probadores manuales tengan una idea general sobre la automatización. Esto les permitirá analizar la posibilidad de la automatización y su conveniencia para un escenario específico, además de tomar una decisión significativa sobre la automatización.
De forma frecuente, me he encontrado con situaciones en las que los probadores manuales olvidaban por completo poner este atributo y los casos de prueba se perdían de los filtros. O, por costumbre, pusieron la automatización para todos los casos de prueba. Si es necesario, siempre se puede consultar con un experto en automatización.
2. ¿Los casos de prueba son escritos por los automatizadores? En este caso, los casos de prueba pueden estar escritos en un lenguaje puramente técnico y el script del usuario no será claro. Por ejemplo, me encontré con una prueba que consistía en varias consultas de peso: "ejecutar la consulta 1", "ejecutar la consulta 2".
De nuevo, si la solicitud devuelve datos, ¿es bueno o malo? ¿Cuándo se considera que la prueba ha sido superada? Tal vez lo hayan discutido una vez, pero luego de seis meses ya nadie lo recuerda. Esto es conveniente en general, pero puede ser difícil descubrir qué es lo que se comprueba exactamente sin profundizar en los detalles de la propia solicitud. Comprueba si entiendes los escenarios o si aún requieren una aclaración.
3. Escenarios detallados. Los escenarios deberían describirse con detalle a fin de que -con la automatización posterior- resulte obvio lo que hay que hacer, dónde hay que clickear y qué hay que comprobar.
Por ejemplo, al ejecutar un script para trabajar con un documento, el paso "guardar el documento" se queda al final. Este paso es ambiguo porque esta acción se realiza de varias maneras diferentes. La elección de una de ellas puede cambiar radicalmente el comportamiento del autotest que, como resultado, comprobará algo distinto a lo que pretendías. No queremos eso, ¿verdad? Entonces intenta no obligar a la otra persona a averiguar qué es lo que querías decir.
4. Importancia de la prueba. Las pruebas deben mantenerse actualizadas. Sí... es difícil, pero no se puede conseguir de otra manera. Es una buena práctica informar a los ingenieros de automatización sobre los cambios antes de que sus autotests fallen.
Por ejemplo, sabemos que la interfaz de usuario cambiará o que aparecerá una ventana adicional en algún lugar. Con las pruebas manuales, ni siquiera hay que prestar atención a esto: ya nos hemos enterado de los próximos cambios y sabemos que todo irá bien. Lo único que queda es hacer click en “Aceptar” y seguir adelante. El autotesting, por su parte, definitivamente no espera nada de esto y empezará a hacer sonar la alarma.
Paso 3. Decidir los datos que utilizarán los autotests
Habitualmente, los propios autotests generan datos para la verificación y los eliminan luego de la ejecución. Esto tiene sus pros y sus contras. Por un lado, intentamos no interferir con nadie: creamos lo que necesitamos nosotros, probamos la funcionalidad con los datos de los que estamos seguros y después limpiamos. Por otra parte, así garantizamos la cobertura necesaria.
Sin embargo, es importante realizar las pruebas también sobre los datos con los que el usuario trabaja (o lo más cerca posible). Si no podemos crear esos datos por alguna razón, utilizamos los que ya tenemos; pero no borramos los datos después de las pruebas.
¿Por qué? Los "datos reales" tienen ciertas características: por ejemplo, los datos pueden importarse a un sistema, formarse de manera diferente, tener una lógica más compleja (algo que será difícil de repetir por la pureza del escenario). Otro matiz es que los datos cambian con frecuencia. Si este es su caso, vamos a considerar un enfoque diferente.
En algún momento de los casos empezamos a añadir criterios para los datos que se van a utilizar. Pueden ser sencillos: por ejemplo, debes tomar un usuario que se registró en el sistema hace más de un año. Una de las soluciones es hacer una solicitud a la base de datos con los mismos criterios. Esto es todavía más conveniente para los autotests.
Este enfoque es adecuado si la prueba debe realizarse en diferentes entornos, donde los datos varían. Pero también hay un inconveniente: si los datos son bastante complejos, es decir, hay muchos criterios (un usuario registrado hace un año que no ha realizado compras de productos de una determinada categoría en los últimos tres meses), será difícil o incluso imposible obtener los datos de esta forma. Probablemente será más fácil seleccionar los datos manualmente y sustituirlos por un código duro.
Para no interferir entre sí durante las pruebas, utilice entornos diferentes o separe los datos para los autotests y las pruebas manuales. Así, al comprobar un determinado escenario no se encontrará con el problema de los cambios accidentales de datos.
Paso 4. Optimizar las comprobaciones
Al optimizar los autotests, no pierdas de vista un punto importante: la calidad de las comprobaciones. Nos esforzamos por hacer que las pruebas automáticas sean más rápidas y ésta es su ventaja evidente en comparación con las pruebas manuales. Sin embargo, hay que asegurarse de que al mismo tiempo se proporcione la cobertura necesaria.
He visto por experiencia propia que un intento de acelerar la comprobación puede tener un efecto desagradable en la calidad. Por ejemplo, puedes enviar solicitudes no a través de la interfaz de usuario, sino directamente mediante la API. Aquí tienes espacio para moverte. Y tu trabajo, por supuesto, irá más rápido. Pero con este enfoque, la interfaz de usuario no se comprueba y esto tiene muchas consecuencias.
Los usuarios no utilizarán la API y los problemas con la interfaz se notarán de inmediato: se convertirán en un bloqueo inequívoco para las tareas del usuario. Pero si se te ha ocurrido esa idea, puede ser el momento de separar y combinar las comprobaciones. A continuación, piensa con calma en la cobertura y optimiza el proceso para su propio placer.
Recomendaciones
En lugar de una conclusión, compartimos una breve lista de sugerencias. Resumamos y repitamos lo que hay que recordar al iniciar la automatización de las pruebas en el proyecto:
- asegúrate de haber identificado y designado todos los escenarios que conviene automatizar;
- combina las comprobaciones y trata de brindar una cobertura suficiente en términos de funcionalidad y datos;
- no pierdas de vista los casos de uso personalizados.
Y lo principal es recordar: el objetivo de cualquier prueba es encontrar problemas con el fin de lanzar un producto de calidad. Deja que las pruebas automáticas sean "verdes" y que los usuarios estén contentos.
