Las pruebas automatizadas han ganado cada vez más popularidad en las empresas de desarrollo de software, así como en los proyectos en los que son incluidas, sin importar la industria de la compañía que recibe el servicio o la naturaleza de este. Como explicamos en una entrada de blog anterior, el auge de la Automatización de Pruebas se basa la gran cantidad de recursos que se ahorran los departamentos de Testing & QA, ya sea en la reducción de mano de obra, así como en la liberación de tiempo y esfuerzo de los Testers , quienes pueden reducir la operatividad para dedicarse a tareas de mayor valor agregado , como el probar funcionalidades nuevas o no cubiertas en la automatización.
Sin embargo, como toda disciplina, la Automatización de Pruebas conlleva una serie de buenas prácticas que han de tomarse seguirse muy de cerca, logrando así que se cumpla la promesa de optimización de los recursos. Entre esas buenas prácticas encontramos:
Correcta asignación de los procesos de automatización por grados
La gran parte del proceso de testing en cualquier proyecto se basa en las pruebas unitarias, luego estaría la prueba de los componentes, posteriormente la integración y finalizando con API, asignando menos esfuerzo en la interfaz de los usuarios, que sería la parte más operativa de la gestión.
Automatizando las secciones más operativas del proyecto dejamos de pasar por alto las facetas más calificadas y funcionales del proyecto, brindando así el mayor valor al usuario final.
Explicación de la pirámide de Mike Cohn:
Pruebas Unitarias: Se utilizan para comprobar el correcto funcionamiento de una porción reducida de código, por ejemplo, un método. Son el punto de partida para detectar fallos, si una prueba falla en este punto, lo más probable es que también fallen las pruebas de los subsiguientes niveles (integración, API, funcional etc.)
Pruebas de API, integración de componentes, servicios: Estas pruebas verifican que la comunicación e intercambio de datos, entre los diferentes módulos de la aplicación o con otras aplicaciones. Sirven para detectar fallos en la forma en la que los diferentes módulos de la aplicación actúan y se integran los unos con los otros.
Pruebas de interfaz gráfica: Requieren elevado tiempo de desarrollo y son lentos en su ejecución y con muchas dependencias con otros componentes. La interfaz gráfica es donde los cambios se dan más frecuentemente, por eso también estas pruebas suelen ser las más inestables, requiriendo actualización periódicamente. Sí, hay que automatizar las pruebas de GUI de las funcionalidades críticas, pero es mejor hacerlo después de haber automatizado los niveles más bajos de la aplicación.
Determinar qué pruebas GUI son fundamentales para el proyecto
No todo se puede ni se debe automatizar, hay que definir los casos de prueba que son candidatos a teniendo en cuenta cosas como validaciones, usabilidad, accesibilidad, etc.
¿Qué automatizar? Pruebas críticas, que no requieran intervención humana, que dé resultados que se puedan comprobar inequívocamente, y cuya complejidad para automatizar no sobrepase el valor que puede aportar.
El tema de la selección de las pruebas de interfaz a automatizar es un tema amplio en sí mismo, por lo que debemos enfocarnos en aquellas áreas críticas para la aplicación, que ya están cerradas y que no van a cambiar constantemente.
Involucrar a todo el equipo en el proceso de testing, así como PM y ajenos al proceso
Se debe incorporar a todo el equipo en la estrategia de automatización de pruebas. Si testing y desarrollo no están en sintonía la automatización fallará. Testing necesita de la colaboración de desarrollo en cuando a seguir ciertas prácticas en el desarrollo de la aplicación para favorecer la automatización de las pruebas.
Adicionalmente, la inclusión de diversos profesionales con conocimiento en el core del negocio del cliente permitirá encontrar detalles y puntos de mejora en el desarrollo, teniendo en cuenta que este será usado por miles de usuarios finales, que demostrarán su descontento con un aplicativo ineficiente.
Asignar recursos con las habilidades necesarias para realizar la automatización
La automatización hecha correctamente requiere más que simplemente grabar y reproducir las pruebas de UI con una herramienta. La automatización debe poder integrarse a nivel proceso de desarrollo para que llegue dar verdaderos beneficios.
Una buena práctica es tener roles separados para el tester funcional y quien automatiza pruebas, combinar estas dos tareas para ahorra recursos es la opción más común, pero termina teniendo el efecto opuesto ya estos roles que requieren habilidades diferentes. Desde hace un par de años algunas compañías como Microsoft, empezaron incorporar el perfil de “Software Development Engineer in Test” o SDET cuyas tareas van desde desarrollar y mantener script de pruebas automatizados (no sólo de interfaz de usuario sino también de seguridad, carga, performance, etc.) hasta implementar y mantener la infraestructura necesaria para integrar y correr esos test como integral parte del proceso de desarrollo.
Este perfil no se encarga en ningún momento de las pruebas funcionales, test plans o test cases, esas tareas quedan en manos de los testers manuales.
Mantener un equipo de testing manual
El objetivo de la automatización de pruebas no es eliminar el testing manual, ni suplantar a los testers. Lo que se automatizan son validaciones que los testers manuales previamente han detectado durante pruebas de regresión o smoke testing.
Es incorrecto pensar que las pruebas automatizadas van a encontrar bugs que los testers manuales hayan omitido. Hay que recordar que se trata de scripts que simplemente corren pasos y verifican resultado, pero el script no verificará nada para lo que no se lo haya programado.
Pasos para elaborar una sólida estrategia de Testing
Determinar el alcance de la Automatización de Pruebas: Todos los aspectos deben considerarse al analizar la viabilidad. También es esencial realizar un análisis de factibilidad en el paquete de casos de prueba manual que permite a los ingenieros de automatización diseñar los scripts de prueba.
Seleccionar la prueba a automatizar correcta: Las pruebas de automatización dependen en gran medida de las herramientas. Es por eso que encontrar la herramienta de prueba de automatización adecuada es una fase crítica para un ciclo de vida de prueba de automatización. Cuando busque una herramienta de automatización, debe tener en cuenta el presupuesto, las tecnologías que se utilizan en el proyecto, la familiaridad de la herramienta de su equipo con los recursos a bordo, la intuición, la flexibilidad y más.
Plan + Diseño + Estrategia de Testing: La siguiente es la fase de la metodología del ciclo de vida de las pruebas de automatización que define cómo abordar y lograr el objetivo de la automatización de pruebas. La selección de un marco de automatización de prueba es lo primero y más importante en la fase de Estrategia de prueba del Ciclo de vida de pruebas de automatización.
Una buena documentación facilita la ejecución: Una vez que instale el entorno de prueba, es el momento de ejecutar el script de prueba. Entonces, esta fase del ciclo de vida de las pruebas de automatización está dedicada a la ejecución de todos los scripts de prueba.
Reporte y análisis de resultados de testing: Después de realizar todos los tipos de pruebas, el equipo de pruebas analizó para identificar qué funcionalidad o componente particular experimenta un número relativo de informes de problemas.
Conclusión
Son muchas las variables que determinan la calidad de la automatización, por los que los responsables de llevar a cabo el desarrollo y/o pruebas de calidad necesitan asignar más recursos para garantizar la calidad del desarrollo.
Te invitamos a que visites nuestra página de Testing & QA para que conozcas más sobre nuestra metodología y calidad de servicio.