Desarrollo de software. La justificación presupuestaria del testing

Partiendo de la base de que en la mayoría de los casos, los responsables de autorizar el gasto en sistemas de información ya sea en desarrollo o en mantenimiento les va a parecer caro el presupuesto que le pongamos por delante, no va a ser sencillo conseguir una partida adicional para reforzar las tareas de testing por parte del proveedor.

Los motivos que pueden alegar podrían ser los siguientes:

- Si en la organización tenemos un equipo interno o externalizado responsable de verificar la calidad de los productos software entregados, ¿para qué invertir ese coste adicional?.

- Se supone que el proveedor independientemente de que la metodología de desarrollo que utilice esté condicionada por las directrices del cliente tiene unos mecanismos y buenas prácticas internas que garanticen que el producto que se entrega lo hace superando los umbrales mínimos de calidad exigidos en el proyecto. Si un proveedor no es capaz de garantizarlo, habrá otro que sí tenga un mayor nivel de madurez en sus procesos y que lo garantice y si así lo hace por escrito hay que exigirlo.

Lo peor de todo es que ambos argumentos tienen bastante peso y puede ser complicado de explicar la motivación de que sea necesario un mayor presupuesto para que el proveedor pueda realizar de manera adecuada las tareas de testing que requeriría un sistema de las características del que se va a desarrollar o mantener y que ya estaría integrada en sus procesos.

No obstante, lo que sí es cierto es que la calidad tiene un precio y que si una empresa de desarrollo de software tiene integrado controles de calidad en sus procesos que además son supervisados y verificados, el precio del desarrollo va a ser superior generalmente a quiénes no lo tengan. Ahora bien, lo que resulta interesante es encontrar la mejor opción en relación calidad/precio.

Por tanto, desde mi punto de vista la clave no está en entender el coste del testing como una partida adicional en el presupuesto del desarrollo de software sino como un elemento inherente al mismo. El objetivo no es ejecutar trabajo, sino que el trabajo que se ejecute esté bien hecho. Por ese motivo es importante conocer ante propuestas de colaboración u ofertas realizadas por proveedores qué servicios en cuanto a la verificación de la calidad del software tienen incluidos, así como conocer qué umbrales de calidad tienen como objetivo, qué técnicas van a utilizar, etc…. Y como es un elemento inherente al desarrollo de software también es necesario darle el valor económico que se merece y no pensar en que el proyecto va a ser utópico, que no pueden haber errores y que no van a existir ningún tipo de problemas.

About these ads

Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.215 seguidores

A %d blogueros les gusta esto: