Comenzar en un equipo siempre trae consigo múltiples expectativas respecto al aporte que el resto del equipo espera de un Ingeniero de QA. Creo que muchos Ingenieros de Pruebas nos hemos encontrado con equipos que esperan solucionar los problemas de desarrollo, tan sólo agregando un nuevo compañero que se encargue de hacer una revisión que el camino que siguen los usuarios esté limpio de errores.
Pero ¿qué tan efectivo es esto? Para comprender todas las aristas de un buen proceso de calidad, tenemos que entender el proceso de desarrollo. Seguro, ya has escuchado esta explicación millones de veces, sobre los procesos predictivos y de la forma en que se desarrollaba el software hace algún tiempo atrás, donde estaban los equipos aislados y desarrollando para cumplir entregas, objetivos e hitos.
Las metodologías predictivas proponen una visión de desarrollo donde cada etapa se comienza al cerrar una etapa anterior. Esto por supuesto resultaba en un producto terminado y listo para probar luego de muchas horas, semanas, meses o incluso años de trabajo. Entonces, ¿dónde entra el proceso de calidad en una metodología de desarrollo predictivo? Una vez cerrada la etapa de integración es cuando comienza el despliegue de pruebas, siendo una de las últimas etapas del proyecto.
Pero claro, al momento de alcanzar esta etapa, pueden haberse colado muchos problemas en la ejecución de las etapas anteriores, y un Ingeniero de pruebas solo participa cuando ya se han cerrado todas las etapas anteriores. Si finalmente, se encontraba algún error en producción, era muy probable que los dedos apuntarán a culpar al departamento de calidad. Pero ¿es de alguna manera esto un proceso justo?
Aunque parezca algo exclusivo de un proceso predictivo, existen muchos equipos que trabajan bajo metodologías ágiles que siguen adoptando esa visión de relegar la calidad solo al departamento de pruebas, sin enfocarse en lo que realmente importa para trabajar desde el agilismo, un cambio de mentalidad, construir confianza entre los miembros del equipo y entregar valor desde etapas tempranas con altos estándares de calidad.
Recordemos que las metodologías ágiles nacen como una antítesis a las fórmulas de desarrollo del momento donde todos somos un equipo trabajando por un mismo objetivo, y por dar valor al usuario. Es por ello que la calidad se convierte en un trabajo colectivo y no una etapa del proyecto.
La pirámide de pruebas es una buena oportunidad en nuestro rol de ingenieros de QA, donde podemos participar del diseño de las pruebas unitarias, y no sólo esto, sino involucrar a todos los miembros del equipo en trabajar en un producto de calidad, con esto, poder dar pasos como en la definición de los criterios de aceptación en las sesiones de “Los Tres Amigos” o en la creación de las pruebas unitarias, para participar desde etapas más tempranas de la creación de una funcionalidad y poder abrir puentes de comunicación con roles de desarrollo.
Una de las características más importantes dentro del agilismo es esa visión de sombreros, donde entendemos el flujo de cada uno de los roles y las responsabilidades y de vez en cuando podemos intercambiarlas para apoyarnos. De esta manera fomentamos conversaciones entre todos los miembros que sin duda ayudarán a entender la función que cada uno juega para alcanzar el objetivo conjunto.
Tener sesiones para analizar los escenarios que pudieran presentarse para probar una funcionalidad, le permitirá al desarrollador, considerar más caminos y así desarrollarlos, siendo esto un desarrollo enfocado en las pruebas a las que su funcionalidad será sometida. Pero esto no tendría ningún sentido si sólo queda en palabras, pues recordemos que en agilismo sólo se crea documentación cuando se conoce que aporta algún valor.
Es por ello que a través de librerías como Junit en Java, podemos crear pruebas automatizadas sencillas que se encarguen de verificar en cada despliegue el correcto funcionamiento del sistema y que nada se haya roto con la incursión de modificaciones. Asimismo, que ofrezcan resultados rápidos sobre si la prueba fue aprobada o no, teniendo un reporte de lo que se aprueba o lo que falla en cada despliegue. Las pruebas unitarias deben ser contempladas por el desarrollador para considerar si una funcionalidad está completamente desarrollada, pero en tu rol como Ingeniero de Pruebas, debes ser un apoyo para el diseño de estas pruebas, con tu experiencia y la información que ya hayas recogido en sesiones anteriores sobre los criterios de aceptación.
Lo importante en este punto es que el trabajo de equipo con el desarrollador permitirá crear una mayor cantidad de pruebas automatizadas que provean al equipo de una retroalimentación inmediata con cada despliegue. Adicionalmente estas pruebas son más sencillas de crear que al subir en la pirámide y son más rápidas de ejecutar que las pruebas de API y las de UI.
Aunque el equipo no espera que conozcas sobre programación, es importante que te sientes a conocer cuales son las expectativas que tienen con respecto a tu trabajo.
Enfoca tus esfuerzos en fomentar una cultura de retroalimentación con el uso de buenas prácticas. Asegúrate de haber cubierto efectivamente los procesos con una buena cantidad de pruebas unitarias que puedan detectar cualquier fallo que pudiera colarse en este punto.
Que las pruebas automatizadas se conviertan en apoyo para prevenir errores en tu aplicación y no un factor de disminución de productividad. Recuerda que en el agilismo todos los miembros del equipo estamos remando hacia un mismo destino.
Aviso legal: Las declaraciones y opiniones expresadas en este artículo son las del autor/a o autores y no reflejan necesariamente las posiciones de Thoughtworks.
