|
La Importancia de la Prueba del Software Por John Viega y John McManus - Cutter Consortium - Research Briefs Traducción libre al español por J. F. Díaz Licenciado en Ciencias de la Computación del artículo original The Importance of Software Testing. La robustez del software es un problema que a todos importa pero pocas personas aplican en sus productos. El proyecto promedio tiene semanas destinadas a la prueba, principalmente en las semanas antes del despliegue. Por supuesto, la mayoría del software termina retrasado y por encima del presupuesto, y la prueba es la primer cosa que se reduce o se elimina. Así, mucho software comercial consigue solamente un par de días de prueba antes de enviarse a producción. En el mundo de alta presión de la Internet, este modelo parece razonable, puesto que todos se apresuran a sacar sus productos al mercado más rápido que sus competidores. Puesto que la próxima versión será liberada en sólo un par de meses, tiene sentido dejar los errores acumularse después de la liberación y corregirlos todos para la próxima versión, ¿correcto? Por supuesto, hay un montón de problemas con este modelo. Si dejas que tu software se embarque con errores significativos que afecten la experiencia de muchos usuarios, rápidamente despedazarás la calidad asociada con la marca de tu compañía. La gente siempre te recordará por la baja calidad de tu primera versión. Otra razón por la cual este modelo no tiene sentido es que a medida que avanza el ciclo de desarrollo del software, el costo de encontrar y corregir un simple error en el software crece enormemente. Si un problema es detectado en la fase de requerimientos, cuesta cerca de $139 corregirlo. Para cuando el tiempo de codificación empieza, el costo se eleva significativamente. Por ejemplo, muchas compañías tienen equipos de prueba cuyo trabajo es aporrear un producto extensivamente después de que la fase de codificación esté completa. Para esa gente encontrar errores, y para que esos errores sean entonces reparados, el costo se eleva sobre los $14,000 por error - más de 10 veces más dinero por error que si éste fuera detectado en la fase inicial de desarrollo. Claramente, el software no tiene que ser 100% libre de errores. De hecho, uno de los problemas más difíciles con la prueba es saber cuándo parar. Si tu compañía pone un equipo de probadores en un proyecto, y ellos invierten cuatro semanas en el producto terminado, ellos podrían encontrar un montón de errores la primer semana, algunos la segunda, pocos la tercera, y ninguno en la cuarta. Pero sólo porque ellos no encontraron ningún error en la cuarta semana no significa que no haya ninguno. No hay una forma práctica para probar que cualquier pieza de software del mundo real esté exenta de errores, incluso una bien probada pieza de software. Además, la funcionalidad para los usuarios expertos de software a menudo no llega a probarse tan bien como las funcionalidades básicas, debido a que los probadores son raramente usuarios expertos. Nadie quiere obtener una reputación por software que no es robusto a los ojos de los usuarios expertos, debido a que los usuarios expertos tienen un impacto en los hábitos de uso de los usuarios novatos. Si esos usuarios se enojan, tu base de usuarios completa podría lentamente migrar a otro producto, aún si lo probaste completa y honestamente a fondo. La prueba es generalmente considerada costosa y molesta. Pero como hemos acabamos de ver, es una molestia necesaria. La meta para la mayoría de las compañías debería ser hacer el mejor trabajo de prueba posible y minimizar los costos. La idea que parece funcionar mejor es "probar en etapas tempranas y probar a menudo." La robustez no es un módulo que puede ser incrustado a un lado de un sistema preexistente - es mucho más efectivo en costos desarrollar software robusto si te esfuerzas por esta calidad desde el día uno. Similarmente, entre más se pruebe el software, mayor cantidad de errores serán encontrados (aunque las malas estrategias de prueba son a menudo son las más usadas y las más inefectivas).- |
Lecturas Relacionadas Métodos de Prueba de Programas Las Fases de la Programación Cómo Ser un Buen Codificador de Software |
Ir al inicio de este artículo | Volver a Documentos Web
Ir a la Página Principal de NeoProgramadores