Estimada comunidad de Gente de Calidad, bienvenido a mi nuevo post, como siempre es un gusto saber que has dedicado unos minutos para leer sobre temas de calidad.
Si has llegado hasta aquí muy probablemente ya me sigues en mis otras redes y estarás enterado que estoy trabajando activamente en un nuevo curso con todo lo que he aprendido y avanzado en mi carrera.
Ya casi tengo medio año de trabajo con Thoughtworks y lo que he logrado avanzar me sorprende incluso a mi, pues lo interesante de cada proyecto que recibes en la compañía es que su grado de complejidad te invita a mejorar tus habilidades y a entender que incluso aquellas que creías haber dominado aún tienen espacios de mejora.
Es por ello que he empezado a explorar algunas formas de hacer un trabajo más especializado en materia de calidad y he estado probando cómo puede esto influir en la elaboración de un producto de alta gama.
Para mi sorpresa, e incluso creo que la sorpresa de muchos, la mejor manera de garantizar un producto mejor elaborado, no es corriendo más pruebas cuando se terminan una funcionalidad y pensando en más escenarios o contratando a un equipo más amplio de pruebas, sino al contrario, el secreto comienza con involucrar al equipo de pruebas en etapas más tempranas del desarrollo.
Puede que pertenezcas al grupo de escépticos que no ve beneficio alguno en que una persona que no tiene idea de como programar se involucre en otras etapas diferentes a las pruebas, pero luego de todo este artículo te invito a dejarme tu opinion y a que debatamos como gente civilizada los múltiples beneficios de trabajar de forma mancomunada entre el negocio, el producto y los usuarios.
Cuando podemos contar con la perspectiva de un ingeniero de calidad desde el comienzo de una funcionalidad nos aseguramos de comenzar a trabajar en pruebas incluso antes de comenzar a tirar líneas de código en el producto y la introducción de posibles errores a través de ellos.
Recientemente he recibido muchas preguntas al respecto, y he notado que hay equipos que conocen los beneficios de las pruebas en etapas tempranas y quieren comenzar a incluir al equipo de pruebas, pero no saben cómo empezar u otros equipos que tienen un equipo de pruebas que trabaja comúnmente de manera reactiva corriendo pruebas en cada sprint y aun no hayas tenido la oportunidad de participar en otras etapas, porque las prioridades de cada sprint lo impiden.
Sea cual sea el equipo al que pertenezcas, quiero comentarte hoy que existen tres pasos que debes abrazar para empezar a hacer shift left testing en tu equipo y que gracias a Andrea Puertas, una excelente analista de negocios logré determinar en mi última experiencia de trabajo. Te los voy a enumerar a continuación:
1.- Establezcan los estándares de código:
Puede que pienses que este es un trabajo exclusivo de los desarrolladores, pero te hablo desde la experiencia, muchos equipos no se toman el tiempo para sentarse a debatir sobre ello, lo que provoca que en la hora de la revisión de los códigos, el equipo de desarrolladores no esté en la misma página.
Este tipo de escenarios genera retrasos y no ayuda al equipo a construir confianza entre los miembros.
Establecer un modelo aceptado por todos, agiliza las revisiones y se entregará un código más seguro que se apega a los principios de todo el equipo.
Asegurate tambien que todos los miembros del equipo tengan clara la arquitectura de diseño y patrón de desarrollo y en caso de cualquier duda dirigirse al líder técnico para resolverlas, si bien no eres quien tiene la responsabilidad de definir estos aspectos, debes velar por que se lleven a cabo estas conversaciones y se logren estos acuerdos.
2.- Comienza a probar desde etapas tempranas:
En lo posible, visualiza cómo se irán integrando las pruebas en cada etapa del proyecto, recomienda al equipo utilizar herramientas que revisen el código y pueden generar un reporte de las mejoras que se pueden hacer. Existen múltiples herramientas como SonarQube que te permiten conocer la cobertura de código y el cuidado de los estándares de desarrollo.
También analiza cómo se incrementará la aplicación de pruebas a través de cada sprint o cada entrega de una nueva funcionalidad.
Aunque actualmente muchas empresas batallan con la inclusión de metodologías ágiles en sus proyectos, es importante que como analista de calidad puedas brindar un camino a todo el equipo sobre cómo el producto será probado en las diferentes etapas.
3.- Abraza la automatización
Con esto no me refiero a automatizar las pruebas, la automatización de pruebas requiere esfuerzo y no va a solucionar problemas de fondo, sino me refiero a que el equipo de desarrollo automatice lo más que pueda de sus procesos.
Ya sea las pruebas unitarias, el despliegue, la entrega. Cada uno de estos pasos genera presión y ansiedad en el equipo, y mientras se lleven de manera manual resultan en posibles errores. Así que trabaja con tu equipo en visualizar las ventajas de automatizar los procesos, y en caso de los reportes de calidad, busca herramientas que se integren al equipo y les puedan proveer de una retroalimentación rápida y segura sobre las fallas que eventualmente puede presentar el sistema.
Recuerda dar valor a tu equipo y ser un medio para la entrega de un producto del que todo el equipo se sienta satisfecho. La calidad es mucho más que aplicar pruebas y recuerda todos los días que la calidad es trabajo de todos.
Cuéntame que te han parecido estos aspectos y dentro de tu perspectiva del equipo, ¿crees que puedan ayudar en el desarrollo de un producto de calidad?
Quedo a la espera de tus comentarios.
