2 enfoques complementarios a la hora de estimar testing

Todavía recuerdo la primera vez que me encargaron hacer una estimación de esfuerzo. Se trataba de un testing funcional que debíamos hacer sobre un desarrollo de otro proveedor.

En retrospectiva fue divertido y desafiante pero en aquel entonces los primeros minutos de trabajo sobre la tarea fueron bastante tensos puesto que no tenía idea por donde empezar. Sin embargo, y luego de un rato de meditación sobre el asunto, la hoja en blanco se rompió y la cosa empezó a fluir [1].

La cantidad de métodos para estimar esfuerzo de testing funcional es inmensa. Particularmente a mi me gusta combinar siempre dos enfoques: top-down y bottom-up.

Llamo enfoque top-down a calcular el esfuerzo de testing a partir del esfuerzo total del proyecto o el esfuerzo estimado de desarrollo. La forma de implementarlo es hacer una cuenta del estilo "el testing debe ser el XX% del esfuerzo estimado para desarrollo". Dependiendo del contexto de proyecto y el software a testear, este XX puede ir desde el 20% hasta el 50%. Con este enfoque se tienen a minimizar los detalles de la prueba y a calcular esfuerzos que, en cierta forma, subestiman el trabajo.

En contraposición está el enfoque bottom-up, que consiste en estimar el esfuerzo sobre unidades funcionales del software más pequeñas. Para esto, es necesario hacer en forma combinada tres actividades: (1) Desgranar la funcionalidad en unidades mínimas (2) Estimar el esfuerzo individualmente para estas unidades (3) Calendarizar las pruebas individuales en el periodo de tiempo reservado para la prueba. Con este enfoque se tiende a exacerbar los detalles de la prueba produciéndose una sobreestimación del esfuerzo.

Estimar en base a ambos enfoques en simultáneo permite poner un poco de perspectiva sobre lo que uno realmente quiere invertir en la prueba. Así la tendencia natural a minimizar el problema del enfoque top-down se contrapone con la de maximizarlo del enfoque bottom-up.

Seguimos pensando..

[1] En aquella época no teníamos Google para tirar una consulta y ver cómo había resuelto el problema otra persona en este pequeño mundo que tenemos.

Comentarios

Entradas más populares de este blog

10 definiciones de calidad

¿Qué es time and material?

Teoría Económica y Outsourcing