¿Por qué la cobertura automática completa es una mala idea?

¿No sería bueno tener el 100% de cobertura automática de un sistema? Imagínalo. Al no tener que realizar ninguna prueba manual y cada vez que se actualice algo, obtenga un informe completo de todo el sistema. Todo sería perfecto, ningún error se pasaría por alto ¿Cierto?

Tristemente no. Esto es imposible, eso es una completa utopía. No hay manera de explicar cada una de las acciones que un humano puede realizar en nuestras aplicaciones. ¿Por qué? Porque los seres humanos son impredecibles.

Esto es aún más notable cuando estamos probando la interfaz de usuario con marcos automatizados como Selenium, Appium y otras soluciones de front-end para pruebas automatizadas.

EVITAR LA COBERTURA POR EL BIEN DE ESTA

Incluso si la intención de intentar automatizar todo es noble y positivo, a veces eso nos puede llevar a escribir un código increíblemente complejo que será difícil de mantener por lo frágil y no rentable. Para probar escenarios impredecibles, debemos usar métodos impredecibles (humanos).

¿Dónde viene la automatización? Con cosas como pruebas de regresión, pruebas de humo y pruebas rendimiento. El tipo de prueba que siempre sigue el mismo camino y tiende a ser repetitiva. Tener ese esfuerzo de control de calidad automatizada permite a los evaluadores humanos concentrarse en las cosas divertidas, lo que también mantiene su concentración y los hace más productivos.

Un buen equilibrio entre pruebas manuales y automatizadas es clave en cada plan de control de calidad

Cuántas pruebas manuales comparadas con las pruebas automatizadas depende de usted. Eso depende mucho del tipo de sistema que se está probando. Hay sistemas que permiten una cobertura automatizada más grande que otros. A veces, si algo parece demasiado difícil de automatizar, es porque no debería automatizarse en absoluto.

Cuando nuestro objetivo es tener una cobertura del 100% de las pruebas automatizadas en nuestro sistema, es muy probable que nos encontremos con estos problemas:

• Código que es difícil de mantener
• Una solución que parece «no tener fin».
• Limitaciones de lo que pueden hacer nuestras herramientas.
• Progreso lento (si hay)

Entonces, ¿eso significa que deberíamos centrarnos solo en cubrir una pequeña parte de nuestro sistema? Absolutamente no. No centrarse en una cobertura del 100% no significa que debamos cubrir los aspectos básicos. Lo que significa es que debemos centrarnos en agregar pruebas que  agreguen valor a nuestra solución.

ENTONCES, ¿CÓMO PODEMOS DECIDIR QUÉ AUTOMATIZAR?

No hay una regla de oro para esto, la mayoría cae en el sentido común. Pero usualmente los mejores candidatos para la automatización son:

• Pruebas de humo : si tus pruebas de humo son automáticas, siempre tendrás una forma rápida de saber si tu aplicación es lo suficientemente estable como para continuar con el resto de las pruebas.
• Pruebas de regresión : un conjunto de pruebas de regresión puede ser enorme (y aburrido) realmente rápido. Automatizar esta parte de tus pruebas te permitirá concentrar tus recursos de control de calidad, en probar nuevas funciones con más concentración y menos fatiga.

¿QUÉ NO ESPERAR DE LAS PRUEBAS AUTOMATIZADAS?

Nunca debemos esperar probar nuevas características con nuestra automatización. La primera vez que se crea una nueva función es preferible que los ojos reales la vean y la prueben desde tantos lados como sea posible. Las pruebas automatizadas son buenas para validar si algo sigue funcionando como se espera a pesar de los cambios realizados en la aplicación. No de la otra manera.

Escribir una prueba automatizada para un sistema que es estable en este momento es mucho más fácil y más productivo. Una nueva característica no puede garantizar esto. En un mundo ideal, una nueva característica es probada y documentada por un ser humano y luego, cuando esta se prueba como parte de las pruebas de regresión, se automatiza según los resultados de las pruebas manuales.

En conclusión, manténlo simple, manténlo ordenado y manténlo significativo.

Este artículo fu Escrito por Mike Arias
Senior Software Testing Engineer of TechAID.
Twitter: @theqaboy
Blog: qaboy.com/