En el blog de Elisabeth Hendrickson leí la frase del título de este artículo, la cual enuncia que el testing no es una actividad que brinde valor al negocio. La frase es un poco provocadora, pero si la analizamos correctamente es certera, ya que la actividad de hacer testing por sí misma no trae valor para el cliente.
El valor de negocio está relacionado con una mejora de las ganancias de la compañía del cliente o la reducción de los costos. Otra definición es lograr un resultado alineado con el objetivo estratégico de la empresa. Haciendo testing por si solo uno no logra nada. El testing es una de las tantas tareas que un equipo hace para llegar a
un fin, ya que ninguna actividad por si misma da valor al cliente.
Por ejemplo escribir solo código no tiene valor, ya que si uno no lo valida con el cliente se puede llegar a entregar cualquier cosa. El valor del desarrollo de software está en el resultado final, en el software entregado que es útil para uno o más propósitos, no en el proceso o en las actividades que se hicieron para llegar al resultado.
Uno puede pensar que el testing tiene valor, porque el cliente paga por la calidad. Pero en realidad el cliente no paga por la calidad en el sentido de tener testers cumpliendo con su actividad. Además, como vimos, mejor testing puede tener como consecuencia peor software. El testing solo trae valor en la manera que el equipo utiliza la información que el equipo de testing produce con el objetivo de mejorar el software.
El punto es que testing, diseño, desarrollo y todas las demás actividades son un medio para lograr un fin, que es software que satisface a los clientes. El resultado final es un logro de todo el equipo, de la suma de todas las actividades juntas.
2 comentarios:
Estoy de acuerdo en que el testing no aporta valor de negocio a la historia, pero creo que quizá la pregunta esté formulada de forma incorrecta y tendría que ser expresada en negativo.
¿Qué pasaría con el valor de la historia si NO se emplease testing?
Obviamente bajaría la calidad de la historia, existirian características (historias) presentes o pasadas que dejarían de funcionar, lo que restaría valor de negocio a la totalidad del proyecto y seguramente a la historia en cuestión.
El problema en sí no es lo que aporta, pero lo que se pierde al no existir.
Si empleásemos el modelo KANO, ello se situaría más como una necesidad básica, esto es, no produciría nivel de satisfacción si existe pero suma insatisfacción para el caso de no estar allí, en vez de estar situado en la línea de calidad atractiva (delighters).
Saludos,
Erich.
AgileIberoAmerica.wordpress.com
Hola Erich,
Primero y principal, muchas gracias por tu comentario.
Estoy de acuerdo, al no existir la actividad de testing sobre una historia de usuario o una tarea, el valor de la historia bajaría, ya que prácticamente sería inutil para el cliente, al menos que se haya extremado las tareas de aseguramiento de la calidad para lograr que el proceso de desarrollo salga sin errores, pero sabemos que eso es ciencia ficción.
Buenísimo lo del modelo KANO, lo desconocía.
Saludos,
Martin
Publicar un comentario