archivo

Archivos diarios: agosto 24, 2011

Detectar errores al final puede ser demasiado tarde. Si las fallas son funcionales, la arquitectura no es buena, la codificación deja mucho que desear y la culpa es tuya (en muchos casos aunque no lo sea, si el cliente tiene fuerza y no te respeta) el esfuerzo de corregirlo será tan importante que los beneficios del proyectos, si los hay, se diluirán y si hay pérdidas se multiplicarán.

El testing debe acompañar al proyecto desde que se concibe. Los que nos dedicamos a esto tenemos el defecto de que damos demasiadas cosas por supuesto y nos pasan demasiadas cosas por eso. Desde el plan de proyecto, desde el primer acta de reunión, todo debe ser revisado, todo debe ser validado.

¿Es eso ágil? Habrá quien piense que no, pero desde mi punto de vista no hay nada más ágil que no tener que volver a hacer algo de nuevo sin que el usuario te haya dicho que lo cambies. ¿Qué hay que hacer quince veces una pantalla? Pues se hace, si con ello y en cada paso estamos más cerca de que el usuario vea satisfechas sus expectativas. Evidentemente eso cuesta dinero y si no hay presupuesto detrás, el usuario deberá intentar ser más preciso (o renunciar a funcionalidades menos prioritarias).

En el proceso de codificación las pruebas deben hacerse cuanto antes. Si consideras que TDD es demasiado, aplica pruebas unitarias una vez desarrollado el código, si también consideras que eso es demasiado aplica la técnica que prefieras, pero por favor, prueba lo que estés haciendo y no des por supuesto que determinadas partes del código funcionan salvo que estés muy seguro.