Como pasar de ser un analista de pruebas a un automatizador de pruebas

Buenas lectores.

Si estas aquí es porque buscas como convertirte en un automatizador de puebas funcionales siendo actualmente un analista de pruebas / analista de pruebas funcionales / analista de pruebas manuales. Dejame darte la bienvenida y un caluroso abrazo para informarte que estás en el lugar adecuado. Si sigues todo el blog vas a poder convertirte en ese automatizador que deseas.

Introducción

Muchas veces nos encontramos en la dificil decisión de como aumentar nuestros ingresos y si eres como yo, siempre estarás pensando en como mejorar tu estado actual. Existen muchos métodos para aumentar nuestras ganancias, sin embargo todas conllevan riesgos. Estos riesgos se asumen de acuerdo al tipo de personalidad que tenga cada uno, sin embargo en mi caso personal soy reservado y prefiero no tomar riesgos, por ende,  escojí el camino mas torturio que es el aprendizaje.

Que eres actualmente?

Actualmente te dedicas a realizar pruebas funcionales, tus bases son:

• Historias de usuario -> Escenarios de pruebas 
• Precondiciones
• Datos de pruebas
• Resultados esperados.

Tu objetivo sin entrar en detalles es garantizar que el requerimiento cumpla con lo estipulado para su creación.

Que quieres ser?

Quieres poder automatizar ese requerimiento que probaste manualmente y agregar valor tanto para hacer regresiones como valor técnico para ti o tu equipo.

Que necesito adicional a mi rol actual de analista de pruebas funcionales?

Realmente no necesitas mucho conocimiento para comenzar, en este blog te daras cuenta que automatizar solo significa unos pasos adicionales o unos conceptos traducidos a nuestro lenguaje de analista de pruebas, te explico:

• Historias de usuario (cucumber)
• Precondiciones (cucumber)
• Datos de pruebas (cucumber)
• Resultados esperados (Resultados obtenidos con Selenium).

Como puedes observar en el anterior ejemplo, cuando se automatiza se hace exactamente lo mismo que hiciste cuando ejecutaste tus pruebas, sin embargo adicionalmente se deben tener unos conceptos adicionales y unos pasos extras. Entremos en detalles:

Historias de usuario (Cucumber): Las historias de usuario en automatización se crean usando cucumber que a su vez usa varios conceptos como gherkin y BDD. A continuación observarás como se ve una historia de usuario en automatización: 

Fuente: https://www.itdo.com/blog/ejemplos-bdd-behavior-driven-development-con-gherkin/

Como puedes observar la historia de usuario es exactamente igual a como la generamos en nuestras pruebas manuales. Adicional lo que son precondiciones y datos de pruebas también vienen dentro del mismo concepto. Esto lo entenderemos próximamente.

Resultados esperados vs Resultados obtenidos: Los resultados esperados son los datos que nos arroja un sistema bajo pruebas que nos indican si el funcionamiento es correcto, sin esto, no hay manera de saber si nuestro sistema bajo pruebas funciona como debe ser. Partiendo de esto en automatización también usamos los mismos datos, el paso adicional cuando automatizamos es simplemente que debemos capturarlos para poder compararlos. Normalmente como analistas de pruebas solo verificamos visualmente los valores, pero ahora como necesitamos automatizar, debemos capturar esos valores y compararlos contra los resultados esperados. Es decir, nuestro proceso siempre será comparar los resultados obtenidos versus los resultados esperados. Aquí salen los conceptos de Asserts e inclusive Selectores. También son temas que trataremos pronto.

En resumen puedes observar que para comenzar en la automatización de pruebas solo necesitas ser un analista de pruebas y que en el transcurso de tu crecimiento aprenderas algunos conceptos y herramientas adicionales.

Espero que con esta introducción te vieras reflejado y que te animes a seguir en tu camino del aprendizaje.

Saludos.