Muchas veces en este mundillo, nos pasamos el día debatiendo y debatiendo sobre términos, conceptos, métodos, funcionalidades, …. Pero a veces perdemos el punto de nuestra labor: ¿Cuál es el objetivo final de nuestro trabajo? Es más… ¿De qué va nuestro trabajo?

Al principio de trabajar en este maravilloso y loco mundo del QA, recuerdo que cuando intentaba decirle a mi madre (o a casi cualquier persona del mundo), en qué consistía mi trabajo, intentaba hacerlo de una forma más o menos técnica, pero al final me rendía y acababa resumiéndolo en: “hago que los programadores me odien para que el consumidor no nos odie a todos“. En el fondo, y aunque hoy el conocimiento del QA ha aumentado mucho en el mundo laboral, esta simplicidad de explicación sigue valiendo y validando el punto.

Pensar que un QA no es más que un mero tester, es un error. No sólo validamos pruebas o vemos si algo que alguien ha desarrollado va o no, sino que nosotros como QA debemos de adelantarnos a los futuros riesgos y problemas que pueda tener el usuario con la aplicación, da igual en el ámbito que sea. Debemos de asumir el rol del usuario tan bien como podamos, y no seguir siempre las normas o “lo lógico” porque un usuario no tiene por qué hacerlo ni por qué querer hacerlo. Debemos ir mas allá, intentar explorar cualquier camino. Preguntar. Indagar y ser tan exploratorios como podamos. Conocer “las tripas” del producto. Ver lo que otros no pueden ver, bien por falta de tiempo o por falta de hacerse preguntas que nosotros, como miembros de QA debemos hacernos.

Ir siempre un paso más allá de lo establecido o lo requerido, debería de ser una parte fundamental de nuestro trabajo. Pensar en cómo va a interactuar un usuario promedio, asegurarnos que todo va bien, y si hay tiempo (el enemigo mortal del desarrollo de software), preguntarnos continuamente: “pero y si…”

Sí es cierto que, en los últimos tiempos, el hecho de que haya aparecido con tanta fuerza la automatización de pruebas puede parecer habernos dejado un poco a un lado como miembros activos del proceso de desarrollo, pero no debemos equivocarnos. Confiar sólo en el resultado que una prueba automatizada nos dé en según qué casos, sería asumir que el usuario va a hacernos caso. Y ya sabemos todos que, por regla general no es así. En mi humilde opinión, los tests automatizados nos liberan a todos los miembros de un equipo de muchas tareas repetitivas, pero no sustituyen el proceso exploratorio y funcional que un miembro de QA puede realizar. Por ese conocimiento que tenemos del producto que a lo mejor desde otros ámbitos no se tiene.

Así que, hoy, tras un tiempo en esto del QA, los cambios, los nuevos frameworks, nuevas metodologías, sistemas de desarrollo…Al final, siempre que veo a mi madre, cuando sale el tema del trabajo siempre sigue haciéndome la misma pregunta: Pero, ¿eso del QA en el fondo, qué es?

Jesús Manuel Martín

Senior QA Engineer| Digital Assurance & Testing | SOGETI Spain