Automation con Alma de Manual

Mi paso por manual testing a automation testing

Hace 10 años, que inicié mis pininos en el área de testing, por supuesto yo no tenía en mente ser programadora, sin embargo me gustaba picarle a las aplicaciones y me imaginaba que si le hacía algunos cambios se verían, o funcionarían mejor.

Mi primer trabajo fue en el área de soporte técnico, y a un lado de mi estaba el equipo de pruebas; ese fue mi primer encuentro con el mundo del testing y me gusto ver lo que hacían.

Cuándo por fin inicié como tester, me tocó con procesos rústicos, eran simples en cuanto a herramientas, un excel y tu imaginación para encontrar donde podría picarle el usuario y hacerlo fallar; inicie sin templates, sin estándares, y queriendo probar todo; sin tanto tiempo, creando mil defectos funcionales y de UI; vaya hasta sin herramientas para llevar un tracking, teníamos solo un correo con formato de tabla y en el me decían si el defecto era válido o no, y aunque si fueran válidos a veces ni siquiera le hacían caso hasta que fallaba después de liberarse la aplicación.

Con el tiempo empecé a crear límites de pruebas, ser más específica en mi scope y no crear toneladas de casos de usos o una matriz más extensa de lo que el cliente podía ver.

Hoy en día, después de muuucho tiempo, gracias a herramientas para hacer el track de los issues,  tenemos ya historias sin poder cerrarse a causa de los defectos no resueltos y con releases fallados que no fueron a producción, es ahí cuando te das cuenta lo importante que es arreglar un defecto en tiempo y no esperar a que siga tronando ya en la etapa final.

Conforme tenía más experiencia, me di cuenta que era más rápido para mi automatizar los casos de prueba críticos y los que tienen más impacto, que seguir haciendo todas las pruebas de regresión de forma manual.

Me di cuenta también que no es solo probar la funcionalidad, también es muy importante el backend, realizar pruebas a mi código y que los developers lo implementaran también. Así que también yo tenía que conocer el código del developer para encontrar las herramientas que más se adecuarán a su desarrollo. Saber que si está usando javascript, no sería muy óptimo automatizar con puro java, y en la actualidad ya no es solo correr los scripts de forma manual, es tener todo un proceso de continuous integration testing, donde implementas revisión de código estático, corres las pruebas de backend y frontend, por decir solo algunas y que el cliente vea el resultado final y en su máquina, sin necesidad de que se corra todo de forma local.

La magia del testing no se queda ahora en un excel, ¡ya no!, ahora es adentrarse al código, tener que conocer el scope del proyecto, hasta donde va, cómo funciona, lo que se espera, generar tu plan de pruebas, crear tu object page model y además generar tu código para que las cosas salgan y funcionen bien, y vaya, no solo una vez sino todas las necesarias (mientras se sigan haciendo más cambios).

Y esto me llevó como tester a salir de mi área de confort, no queda de otra que seguir aprendiendo.

Espero te guste un poco de mi experiencia, me gustaría tu también nos compartas como han sido los cambios que has enfrentado con el paso del tiempo de hacer pruebas manuales a automatizarlas, así como ha ido evolucionando tu forma de realizar las pruebas. Me puedes escribir al correo contacto@qaminds.com

¿Quien es Sandra Barba?

Habilidad: No dejo ir ningún software vivo
Debilidad: Los lonches bañados
Experiencia: +10 años
Apodo: Lady Bug
Universo Actual: Wizeline (Software Engineer in Test)