En un curso al que asistí una vez me indicaron que se debía asignar un 50% del tiempo de programación a la etapa de pruebas, en su momento me pareció bastante razonable, incluso hasta llegué a pensar que ese estimado de tiempo era el resultado de la amplia experiencia que en el área tenía el instructor. Nada más lejos de la realidad.
Quiero aclarar que cuando menciono “50% del tiempo de programación” no me refiero a la mitad del tiempo, lo que quiero decir es que si a la etapa de programación se le asignan 100 horas, a pruebas se le asignan 50, y estas se ven recortadas, o eliminadas, en función a la proximidad de la fecha de liberación del producto.
Pero la mala información no quedó allí, también se nos dijo que si el tiempo asignado era excesivo, es decir, se terminaban las pruebas y aun teníamos tiempo disponible (cosa que no llegó a suceder) se deberían reproducir las pruebas desde el principio. Como si la repetición de las mismas pruebas, con los mismos datos, en el mismo ambiente y sobre el mismo producto pudiera hacer que aparecieran nuevas incidencias de la nada.
Toda esa operación estaba en función de darle una mayor importancia a la parte de desarrollo, considerando que los recursos asignados al área de pruebas eran un mal necesario y que las pruebas constituían una parte complementaria del desarrollo. Me gustaría decir que esa mentalidad ha cambiado; pero no es así.
En muchas empresas que se dedican al desarrollo de aplicaciones a la medida aun se sigue considerando lo referente a pruebas de software como algo que se debe hacer porque está de moda, no porque realmente vean un beneficio en ello; llegando incluso a hacer estimaciones de los recursos que se necesitarán para corregir las incidencias que el cliente reportará. Son incapaces de poder ver que independiente del tiempo que se puede ahorrar al detectar en etapas tempranas del desarrollo los problemas, la imagen de un producto sin defectos (o con pocos) es extremadamente beneficiosa para la empresa.
No hay comentarios:
Publicar un comentario