La automatización de pruebas al 100% puede ser deseable, pero ¿es práctica?

Por Jonny Steiner, Gerente de Marketing de Producto

 

Si tuviera acceso a una máquina del tiempo, o incluso a unos binoculares temporales (una forma mágica de ver a través del tiempo que acabo de inventar), haría muchísimas cosas con ellos. Sin embargo, para este artículo, me gustaría usar mis binoculares temporales para observar el futuro. Concretamente, me gustaría ver si algún día alcanzaremos el 100% de automatización en las pruebas continuas.

Las pruebas 100% automatizadas podrían ser imposibles.

Es algo que todos desean. Automatizar el 100% de las pruebas continuas es el sueño de todo miembro del equipo de control de calidad y pruebas. Sin embargo, en cierto modo, esto representa un verdadero desafío. Para empezar, algunos códigos son demasiado complejos para escribir pruebas automatizadas. Por otro lado, otros no son lo suficientemente importantes como para requerirlas. La idea es que utilizar un enfoque basado en riesgos para la automatización de pruebas garantiza que se prioricen las partes más importantes del software.

Algunos expertos aconsejan abandonar el objetivo de la automatización total. Argumentan que no hay tiempo para automatizar por completo en el proceso de desarrollo de software, que está en constante evolución. Según ellos, el enfoque debe estar en el retorno de la inversión y en aquello que satisfaga a los líderes empresariales y a las partes interesadas.

¿Y si?

Supongamos que automatizar el 100 % de las pruebas continuas fuera posible. Hay indicios de que algunas organizaciones ya lo están intentando. Con el auge del desarrollo sin código y las soluciones de pruebas automatizadas, se han sentado las bases para un futuro en el que una aplicación se desarrolla y luego se somete a un proceso de pruebas totalmente automatizado. La única interacción humana sería reiniciar cada ejecución de pruebas cuando una nueva versión esté lista o cuando se haya corregido un defecto.

La ventaja radicaría en la posibilidad de acelerar aún más el lanzamiento de productos y, al mismo tiempo, eliminar errores en las primeras etapas del proceso sin intervención humana. Sin embargo, como veremos, las pruebas automatizadas generan valor, pero no siempre de la forma esperada.

El “valor” de la automatización de pruebas

El proceso de pruebas automatizadas se desarrolla de la siguiente manera: se ejecutan pruebas utilizando un punto de partida, un cambio y un resultado esperado. Cuando una prueba finaliza, significa que la automatización se ha ejecutado, pero la funcionalidad bajo prueba aún no está terminada, hasta que se ejecuten las comprobaciones. El valor reside en el proceso de probar, corregir y volver a probar. Este proceso genera instrucciones claras sobre cómo corregir errores.

Es importante comprender que cuando se crean comprobaciones automatizadas, se completa la ejecución inicial de las pruebas, se implementan los cambios y se vuelven a ejecutar las pruebas; entonces, las pruebas detectan defectos cuando el resultado esperado es incorrecto.

En el mundo de las pruebas continuas existe un viejo dicho: “Un cambio de software convierte la automatización de pruebas en detección de cambios”.

La automatización como origen de todos tus problemas

En resumen, las pruebas continuas pueden acarrear más desafíos. En cuanto se modifica la aplicación en desarrollo, el conjunto de pruebas automatizadas queda obsoleto. El mantenimiento de las pruebas, a menudo olvidado, también es fundamental. Un problema que sufren algunas organizaciones es la falta de supervisión del mantenimiento de las pruebas existentes y la eliminación de las obsoletas, lo que genera deuda técnica.

La cobertura de pruebas también es importante en las pruebas automatizadas. Es necesario cubrir todos los escenarios, ya que una prueba que se considera superada podría no ser tan precisa como se piensa. Si bien es cierto que se pueden superar el 100 % de las pruebas, ¿qué sucede con los escenarios que no se incluyeron? Estos no se contemplaron.

Luego está el problema de los ensayos fallidos. Todos ellos deben investigarse. Lo que complica aún más las cosas es que, a veces, los ensayos fallan por causas ambientales y no técnicas. En un mundo donde cada minuto ahorrado es valioso, los resultados falsos negativos lo son aún más.

También hay que tener en cuenta los fallos en las pruebas, ya que cada uno requiere una investigación. Algunas pruebas dan falsos negativos; por ejemplo, una prueba que se agota por algún motivo debido a un problema ambiental. Esto supone una pérdida de tiempo en lugar de un ahorro.

El último desafío de la automatización de pruebas es que estas no piensan por sí mismas. Siguen el camino preestablecido y para el que fueron programadas. Esta no es la forma en que los humanos interactuamos con las aplicaciones. Nos distraemos, nos desviamos y, a veces, hacemos clic en elementos incorrectos. Una prueba automatizada solo cubre el comportamiento preseleccionado por el usuario.

¿Cuánta automatización es suficiente?

Desde líderes empresariales y ejecutivos hasta desarrolladores y personal de control de calidad, constantemente surgen ideas para probar y explorar al usar o navegar por las aplicaciones. Puede que solo lo pruebes una vez para ver si funciona. Lo que no harás, ni nadie debería hacer, es desarrollar una prueba para todos estos pequeños escenarios.

Todavía no hemos llegado al punto de simplemente introducir los requisitos en nuestras herramientas de prueba y esperar los resultados esperados. Sin embargo, ya estamos en un punto en el que los testers quieren poder ejecutar sus pruebas con un clic y obtener resultados. Si hablamos de automatizar nuestras pruebas al 100%, esto significaría que, si la ejecución es exitosa, el software podría pasar directamente a producción sin necesidad de análisis adicionales.

La buena noticia es que acabo de describir las pruebas de regresión automatizadas. Esto excluye las pruebas de rendimiento y seguridad, pero significa que una aplicación puede implementarse en producción una vez que la prueba se haya realizado de forma aislada y haya sido superada.

Vivir con la verdad

Por lo tanto, tal vez la automatización de pruebas al 100% no sea posible. Es una buena idea, pero no la más práctica. Siempre habrá código demasiado complejo para automatizar las pruebas, que además puede ser difícil de leer, pero a veces un fragmento de código no es lo suficientemente importante como para justificar la automatización. El enfoque basado en riesgos que propongo aquí se centra en las partes más importantes del software.

Quizás sea mejor pensar en términos de retorno de la inversión (ROI). Considere el nivel de cobertura que su empresa realmente necesita. Analice la opinión de sus ejecutivos y líderes para determinar su tolerancia al riesgo en relación con el software que se está desarrollando.

Recuerda que no todos los errores son iguales y, por lo tanto, no todas las pruebas deben automatizarse.