Gran cantidad de bugs son encontrados en los productos liberados; de hecho, los expertos estiman que el código fuente original contiene entre dos y cinco bugs por línea de código. Esto significa que el código requerirá dos o más cambios por línea para quitar todos los defectos. Sin duda, muchos productos son liberados mucho antes de que estén listos completamente. Un reconocido ingeniero de software sostiene que "No hay sistemas nuestros, ni siquiera los nuestros".
La ubicación y las consecuencias del software defectuoso no tiene relación con sus causas aparentes, incluso una cantidad mínima de bugs pueden resultar catastróficos. Por ejemplo, los sistema operativo (UNIX, Windows, etc.) contienen gran cantidad de defectos de seguridad conocidos y desconocidos que los vuelven vulnerables a ataques; además, Internet ha incrementado dramáticamente la probabilidad de ataques al sistema.
Los usuarios finales encuentran bugs frecuentemente. Por ejemplo, aproximadamente 1/7 números de teléfonos discados no son completados por el sistema telefónico. Y hay que notar que la tasa de quejas es baja en comparación con la frecuencia de las fallas del software.
El propósito de probar el software comercial es limitar el riesgo, en particular, para soportar los costos de productos empaquetados, cada que un usuario final contacta a un vendedor para solicitar soporte técnico, gran parte (o todo) el margen de ganancia es gastado en responder a esa llamada.
Solución
Se requiere una inversión apropiada en pruebas del software para hacer que el sistema se encuentre relativamente libre de bugs. En algunas compañías "avanzadas", el equipo de testing es mayor que el equipo de desarrollo. El cambio más importante para hacer las pruebas es el control de la configuración de los casos de prueba.
Un sistema típico puede requerir hasta cinco veces más software de prueba que software en producción. A menudo, el software de prueba es más complejo que el software de producción debido a que incluye la administración explícita de la sincronización de la ejecución para detectar muchos bugs.
Cuando una prueba detecta un bug, es más probable que sea el resultado de un bug en la prueba que en el código que está siendo probado. El control de la configuración posibilita la administración de los recursos del test, por ejemplo, soportar tests de regresión.
Otros enfoques efectivos para testing es la automatización de la ejecución de test y su diseño. La ejecución manual de las pruebas es un trabajo intensivo y no hay bases que prueben la efectividad de los test manuales.
En contraste, la ejecución automática de las prueba posibilita correrlos con el ciclo de build. Los tests de regresión pueden ser ejecutados sin intervención manual, asegurando que las modificaciones del software no causan defectos en los comportamientos previamente probados.El diseño automatizado de tests soporta la generación de rigurosas baterías de pruebas y existen docenas de herramientas que lo posibilitan.
0 comentarios:
Publicar un comentario
Muchas gracias por leer el post y comentarlo.