Mozilla QA: Bug Days

Revisando el blog de Mozilla encontré una muy interesante invitación al Thunderbird Bug Day. Me pareció cómico el nombre y comencé a buscar más información al respecto, en pocos clicks descubrí que es un concepto originalmente desarrollado por el grupo de QA de Mozilla en 1999 y que, a pesar de ciertos obstáculos en los años que le siguieron, actualmente se lleva a cabo todos los martes. Se puede encontrar mucha información sobre el Thunderbird Bug Day en su wiki, incluyendo la planificación de las próximas jornadas.

Por un momento me sumergí en la lectura y llegué a un corto párrafo, muy sencillo, pero cargado con una verdad inevitable para toda empresa, gerencia o grupo que se dedica al desarrollo de software. No traduciré el texto pero si listaré las frases contenidas en él que reflejan el karma de todo desarrollador.

• Muchos (MUCHOS!) errores [reportados].
• Algunos [errores] se encuentran en un estado que los hace difíciles de solucionar.
• Podrían no ser verdaderos errores y necesitamos su confirmación.
• Algunos [reportes de errores] están mal redactados.

Estas frases karmáticas son muy familiares para todos aquellos que han trabajado en el desarrollo de software. Sin embargo el concepto del Bug Day va más allá de la simple lista de errores, el Bug Day es una forma de acercar la comunidad de usuarios y el equipo de desarrollo. A mi parecer, esta frase extraída del wiki del grupo de QA de Mozilla revela el verdadero sentido del Bug Day:

"No importa si usted ha estado involucrado con Mozilla durante años o si este es su primer paso en nuestra increíble comunidad de código abierto. Cualquiera puede participar y ser un valioso contribuyente"

Una asombrosa jugada del equipo de QA de Mozilla, probablemente sean muchos los beneficios de aplicar este concepto, sin embargo se pueden identificar claramente dos beneficios muy atractivos para cualquier empresa que desarrolla software, bien sea para consumo interno o para la venta. Estos beneficios son: Incrementar la cantidad de testers y aumentar la identidad del usuario con la aplicación.

Cada usuario es un tester en potencia, al fin de cuentas son ellos los que diariamente usan la aplicación y son ellos quienes sufren las consecuencias de los errores. ¿quién mejor que ellos para reportar los errores de la aplicación? Además el hecho de estar involucrados en el proceso de depuración de los errores de la aplicación, hará que los usuarios se sientan más identificados con la misma ya que finalmente sentirán la aplicación con suya y posiblemente aumenten su compromiso y colaboración para lograr la aplicación perfecta para sus necesidades. Y ni hablar de la reducción del fenómeno de "resistencia al cambio" para aquellos casos en los que sustituye completamente una aplicación por otra.

Una vez más solo consigo ventajas y beneficios imaginando cómo sería aplicar este concepto en esas empresas de servicio que necesitan incorporar la tecnología a sus procesos de negocios para hacerlos más eficientes buscando siempre la ventaja en el mercado.

Una gran lección de un gran maestro!