archivo

Archivos diarios: septiembre 21, 2013

Los defectos son una variable importante para medir la calidad del software, ¿puede ser la más significativa? Si respondemos que sí, podemos pensar que con la detección de defectos ya hemos solucionado cualquier problema pero más importante que dar esa respuesta es entender primero qué es un defecto y qué estrategias se adoptan generalmente para detectarlos.

El concepto de defecto tradicionalmente se asocia a la desviación respecto a especificaciones o requisitos funcionales y a bugs. Es muy frecuente encontrarnos con equipos de personas especialistas en testing que reciben un plan de pruebas y lo ejecutan junto a una serie de prueba que ya tienen catalogadas para realizar de forma genérica en las aplicaciones (a modo de un testing exploratorio un tanto dirigido).

En el momento que la detección de defectos se deja en manos de un plan de pruebas es donde este sistema empieza a hacer aguas. El problema no es el plan de pruebas en sí, sino la actitud que sobre el mismo tienen los desarrolladores (suele ser una molestia, un documento que tienen que hacer porque un tercero se los ha pedido) y también los testers (en una orientación del trabajo hacia el cumplimiento de un proceso, ellos reciben una entrada, la procesan y devuelven un resultado, cuanto más rígida sea su visión de ese trabajo menos práctico será el plan de pruebas).

Por tanto, y de entrada, tenemos un problema de actitud y de enfoque que requiere ser trabajado. Si los desarrolladores no entienden la importancia de colaborar con terceros para la detección de defectos (tal vez penséis que no es necesario que exista un equipo de testing independiente, y os puedo dar la razón en que a veces no haría falta, pero hay que entender que si desarrollamos para terceros, el cliente pueda querer que un equipo que dependa directamente de él le evalúe el trabajo que se entrega) o el equipo de testing no entiende que debe colaborar con los desarrolladores para entender el contexto del proyecto, las características del producto y consultar dudas, de poco vale seguir avanzando en otros aspectos.

Tener a tu equipo trabajando, recorriendo cientos de millas extras y pidiéndo esfuerzos cuando ya no quedan fuerzas, mientras no te involucras no es la mejor forma de que tu equipo crea en ti. Es más tu credibilidad se reducirá exponencialmente conforme tus actos se vayan alejando de tus palabras.

Que sí, que tu trabajo es uno y el de tu equipo puede ser otro. No se trata de roles, sino de implicación, de empatía y compromiso. Es cierto que esto requiere un esfuerzo extra para el gestor pero, ¿no es eso lo que pides en determinados momentos a tu equipo?.

Tu equipo no es una expendedora de servicios, son personas y tienen que sentirse arropadas. Si no lo están, solo quedará que entre ellos se autogestionen, algo que no es ni mucho menos malo, es más lo considero positivo, siempre y cuando tengan una visión que vaya más allá del día a día del proyecto, ya que pueden existir decisiones que requieran tener una visión de un mayor alcance y se les permita llevarlas a la práctica, algo que el gestor puede obstaculizar si lo interpreta como una intromisión en su trabajo en lugar de un apoyo.

Un equipo no se extralimita si existe un respeto entre los roles, existe un consenso entre los límites de cada parte y existe un diálogo fluido y confianza como para que todas las partes se escuchen entre sí.

La clave es que el gestor se sienta parte del equipo y el equipo lo sienta como parte integrante de él. Esto se gana, no se obtiene por tener unos simples galones.

Decía Lao-Tse que: “El sabio no enseña con palabras, sino con actos”.