Si bien la agilidad no es sinónimo de hacer un producto con la menor cantidad de tiempo posible como algunos equipos puedan tratarla de definir, la agilidad se refiere a esa capacidad de adaptarte a los cambios y entregar en cada iteración del producto valor al usuario y al cliente final. Es por ello que tú mentalidad como ingeniero de pruebas debe estar enfocada en siempre crear algo que pueda dar valor al usuario.
Desde que recién empiezas con un nuevo equipo de desarrollo, puedes enseguida denotar la manera en que el equipo trabaja en conjunto como fluye la comunicación, y entonces también debes verificar la forma en que el equipo enfrenta la solución de defectos dentro de la aplicación.
Como uno de los pasos importantes que debes cumplir es hacer que el equipo sienta la responsabilidad de la calidad del producto al que todos están imprimiendo esfuerzo y tiempo.
A continuación voy a compartir tres consejos que te ayudaran a involucrar y a hacer a tu equipo apropiarse de la calidad de su trabajo.
Adoptar una vision de prevenir errores:
Existen equipos que prestan poca atención a los posibles errores en su código y dependen exclusivamente del equipo de pruebas para encontrarlos, este tipo de visión somete al equipo a un bucle interminable de volver las tareas atrás para continuas correcciones, esto resulta en una inversión importante de tiempo y muchas frustraciones, es por ello que la decision de trabajar para prevenir los errores es una visión más productiva dentro del equipo.
Probar el código a través de pruebas unitarias o desarrollo orientado a pruebas:
Cuando el equipo completo se concentra en construir la calidad dentro del producto, a través de las diferentes practicas que permiten la creación de código con la menor cantidad de errores, como es el caso del desarrollo basado en pruebas o la adopción de pruebas unitarias en cada funcionalidad creada, permite un proceso más limpio a la hora de prevenir errores. Aunque, igual puede que haya un camino muy largo para llegar a un código con menor presencia de errores, este ligero cambio en la perspectiva ayudara al equipo a crear un producto más estable.
Algunos equipos ponen en practica la tolerancia cero a los errores. Esto quiere decir que ningún error conocido o reportado debería colarse en una iteración o el cierre de una historia.
También con la adopción de pruebas unitarias y la tolerancia cero, el equipo de desarrollo debe recibir con mayor rapidez la retroalimentación que el equipo de calidad pueda aportar, de esta forma cualquier error que se encuentre a través de las pruebas se puede reparar inmediatamente.
Una vez se encuentra el error, los programadores deben escribir una o más pruebas unitarias que puedan ejecutarse y una vez se corrija el código, la prueba debe pasar, y entonces se pueden correr algunas pruebas exploratorias si es necesario.Una vez cubierto este procedimiento el equipo se puede pasar a otras funcionalidades.
Las multiples perspectivas ayudan con la elaboración de un producto de mayor calidad:
Por otro lado las multiples perspectivas enriquecen enormemente el trabajo de calidad, porque todos los miembros del equipo tienen puntos de vista, habilidades y visiones. Por experiencia te puedo decir que escuchando todas las perspectivas, podemos llegar a entender mucho mejor los riesgos asociados a la entrega de una funcionalidad.
Como siempre he dicho, el desarrollo de software es un trabajo de equipo y tus habilidades van mejorando conforme trabajes en un equipo que se tome muy en serio su producto y este muy comprometido.
Por ejemplo, cundo estes diseñando tus pruebas, puedes empezar a pensar en los comportamientos deseados y los que no que espera de tu producto de software.
Si comienzas a consultar con el equipo te darás cuenta que todos en el equipo se vuelven expertos especialistas en las funcionalidades, y en efecto algunos de ellos pueden ser expertos en una o dos areas, lo cual puede ser de mucha ayuda y de seguro todos van a querer contribuir en la meta común del equipo.
Por ello cada rol es importante, porque como te he dicho en otras oportunidades la visión del ingeniero de pruebas debe ser muy diferente a la visión del desarrollador.
Entonces para ir entrando en ejemplos, el ingeniero de pruebas, es el experto de la calidad y quien conoce sobre los posibles escenarios que pudieran contemplarse con el producto y la funcionalidad, pero pueden contribuir al equipo con el entendimiento de los características y las historias a través de las preguntas para descubrir los posibles supuestos sobre una funcionalidad.
Los programadores por su parte pueden correr algunas pruebas exploratorias antes de entregar su código al equipo de pruebas, y de esta forma cerciorarse lo que están entregando.
Finalmente los dueños del producto pueden correr algunas pruebas de aceptación una vez se ha terminado una historia.
De esta manera cada uno podrá aportar en la revisión del producto con su propia perspectiva.
Uno de los fundamentos de las metodologías ágiles es la confianza de los miembros del equipo y esta solo puede construirse en base al compromiso y la seriedad de cada uno de los integrantes del equipo.
