Automatización de pruebas funcionales, cuando y cuando no
Creo que todos (o la mayoría) amamos las pruebas automatizadas, no solo porque aprendemos mucho sobre el código del proyecto en el que estamos trabajando, sino porque nos ayuda a aprender mas, ahorrar tiempo de ejecución de pruebas mientras nos enfocamos en otras áreas a probar y finalmente, se aprende mas de código y se hace mejor mientras avanza el proyecto.
He trabajado en muchos proyectos (E-commerce, buscadores, intranets, configuradores, canales de TV, etc) sin embargo, no todos los proyectos deben ser automatizados, por supuesto, se puede automatizar lo que se quiera, pero ¿tiene sentido ? para mi la respuesta es no, lo que tiene sentido es automatizar módulos, áreas o tareas que se hacen diariamente y que toman bastante tiempo en ser ejecutadas manualmente, si me lo preguntan a mi, la interfaz de usuario y el diseño del sistema (look and feel) no deberían ser automatizadas, se puede ver rapidamente y facilmente con los ojos que hacer un código que valide que se vea bien el sistema, como dije en mi anterior entrada, probar es prioridad y es mas importante que automatizar, hacer casos de prueba, feature files, etc, sin embargo, flujos como el registro de usuario, login, compras, agregar producto al carrito, buscar, editar la cuenta de usuario, configuraciones, entre otras transacciones y funcionalidad/flujos robustos en el sistema son los mejores candidatos para automatizar pruebas funcionales.
Cuando se automatizan pruebas se debe pensar en el impacto y el tiempo a invertir y pensar en el futuro, ¿si hago un script hoy, tendrá impacto en uno o tres meses ?, ¿ayudará a la salúd del proyecto ?, ¿ayudará a terminar más rápido las pruebas ?, ¿las pruebas que estoy haciendo están probando o solo chequeando ?, ¿cuánto dura el proyecto ? Hay muchas cosas a tener en cuenta cuando se hacen pruebas automatizadas y nos debemos hacer las anteriores preguntas, y por supuesto mas de ellas antes de decidir si se automatiza o no algún área o módulo, podemos acabar haciendo trabajo innecesario y perdiendo el tiempo en scripts que no tendrán impacto o serán obsoletos.
Sería genial crear una cultura de automatización en la cual cada persona en el proyecto puede y debe identificar áreas a ser automatizadas, sin importar que esa persona no sea el que haga el código. La automatización es genial, pero he visto que asignar a una persona para solo automatizar es realmente dificil, los clientes prefieren un QA que pueda hacer pruebas manuales y automatizacion, pero como ya lo mencioné arriba el objetivo siempre será probar, pensemos en esto, el tiempo gastado en automatización puede ser el tiempo que se deba invertir en probar y avanzar en pruebas en el proyecto, por eso es tan dificil asignar automatizadores de pruebas o ingenieros de QA para solo hacer pruebas de automatización, por supuesto, esto depende de como se vende el proyecto, que tan grande es y como lo quiere el cliente.
Esta es mi visión de cuando y cuando no hacer automatización de pruebas funcionales, obviamente la decisión está en cada uno. Se puede gastar tiempo haciendo pruebas automatizadas de UI, sin embargo, existe una gran herramienta llamada Ghost Inspector, es una herramienta que graba los movimientos que se hacen con clics y guarda una imagen para luego compararla con otra al momento de ejecutar otra prueba en el mismo sitio, los clicks son solo verificar que elementos existen y estan correctamente ordenados, la he usado y funciona genial, déjenme saber si les gusta, sin embargo en temas visuale, siempre preferiré las pruebas manuales.
Para terminar, alguna vez escuché una frase de alguien que decía: "El trabajo humano no puede ser remplazado por robots en QA" y creo que es verdad, necesitamos la automatización de pruebas, pero el QA manual y las habilidades humanas en QA son irremplazables.
Comentarios
Publicar un comentario