¿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.
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.
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:
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.
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:
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/
COMPARTIR ESTE ARTÍCULO