La prueba de disciplina actúa como proveedor de servicios de otras disciplinas en muchos aspectos. Las pruebas se
centran principalmente en la evaluación o la valoración de la Calidad del
producto, hecho que se lleva a cabo mediante las prácticas:
-
Buscar y documentar los defectos en la calidad del software.
-
Opinar sobre la calidad percibida del software.
-
Validar y demostrar las suposiciones efectuadas en las especificaciones de diseño y requisitos con una demostración
concreta.
-
Validar que el producto de software funciona según lo diseñado.
-
Validar que los requisitos se han implementado de forma adecuada.
Existe una interesante diferencia entre Probar y las otras disciplinas de RUP - básicamente, las tareas de Probar son
encontrar y exponer los puntos flacos del producto de software. Es interesante porque, para obtener mayores beneficios,
necesita una filosofía general diferente de la que se utiliza en las disciplinas de Requisitos, Análisis & diseño e
Implementación. Una sutil diferencia es que estas tres disciplinas se centran en la completitud, mientras que la Prueba
se centra en la falta de ésta.
Un buen esfuerzo de prueba se orienta con preguntas como las siguientes:
-
¿Cómo puede fallar este software?
-
¿En qué posibles situaciones podría fallar este software de forma previsible?
La prueba desafía las presuposiciones, los riesgos y las dudas inherentes al trabajo de otras disciplinas y dirige
estas preocupaciones hacia la utilización de una demostración concreta y una evaluación imparcial. Lo que desea es
evitar dos posible extremos:
-
un enfoque que no desafíe adecuada ni eficazmente el software, y que exponga sus problemas o debilidades inherentes
-
un enfoque que resulte inapropiadamente negativo o destructivo; adoptando tal enfoque negativo, puede resultar
imposible considerar el producto de software de calidad aceptable y se podría distanciar el esfuerzo de prueba de
otras disciplinas
La información presentada en varios informes y ensayos indica que las pruebas de software provocan entre un 30 y un 50
por ciento de los costes de desarrollo de software. Por lo tanto, resulta sorprendente que la mayoría de personas crean
que el software no se prueba bien antes de ponerse a la venta. Esta contradicción se basa en algunos aspectos clave:
-
Probar software es muy difícil. ¿Cómo se pueden cuantificar los diferentes modos en que puede funcionar un
programa?
-
Las pruebas se realizan habitualmente sin una metodología clara, creando resultados que varían de proyecto a
proyecto y de empresa en empresa. El éxito es principalmente un factor de la calidad y las habilidades de las
personas.
-
Las herramientas de productividad se utilizan de forma insuficiente, lo que dificulta la gestión de los aspectos
más laboriosos de las pruebas. Además de la falta de ejecución de prueba automatizada, muchos esfuerzos de prueba
se llevan a cabo sin herramientas que le permitan gestionar de forma efectiva los datos de prueba extensivos y los
resultados de la prueba. La flexibilidad de uso y la complejidad del software hacen que las pruebas completas sean
un objetivo imposible. Utilizando una metodología bien concebida y las mejores herramientas, se puede mejorar tanto
la productividad como la eficacia de las pruebas de software.
Un software de alta calidad es esencial para el éxito de los sistemas críticos para la seguridad (como el
control del tráfico aéreo, la orientación de misiles, o los sistemas médicos) donde una anomalía puede dañar a
personas. La criticidad de un sistema MIS típico no será evidente con tanta inmediatez, pero es posible que el impacto
de un defecto provoque unos gastos considerables en la empresa que utiliza el software, en beneficios perdidos y
posiblemente, costes legales. En la época de la información, con una creciente demanda de servicios electrónicos a
través de Internet, muchos sistemas MIS ahora se consideran críticos; es decir, las empresas no pueden
desempeñar sus funciones y sufren pérdidas masivas cuando se producen anomalías.
Un enfoque continuo sobre la calidad, iniciado en un estadio temprano del ciclo vital del software, puede reducir el
coste de completar y mantener el software significativamente. Esto reduce ampliamente el riesgo asociado con el
despliegue de un software de baja calidad.
La disciplina de prueba está relacionada con otras disciplinas, de la forma siguiente:
-
La disciplina Requisitos captura los requisitos del producto de software, que es una de
las principales entrada para identificar qué pruebas se deben efectuar.
-
La disciplina Análisis
& diseño determina el diseño apropiado para el producto de software, que es otra entrada importante
para identificar qué pruebas se deben efectuar.
-
La disciplina Implementación produce compilaciones del producto de software que se
validan con la disciplina Prueba. Dentro de una iteración, se probarán varias compilaciones; habitualmente una por
ciclo de prueba.
-
La disciplina
Despliegue proporciona el producto de software completo al usuario final.
Mientras que el software se valida con la disciplina Prueba, antes de que esto ocurra, las pruebas beta y las
pruebas de aceptación suelen llevarse a cabo como parte del despliegue.
-
La disciplina de entorno desarrolla y mantiene los artefactos de soporte que se utilizan
durante la prueba, como las directrices de prueba y el entorno de prueba.
-
La disciplina Gestión de proyecto planifica el proyecto y los trabajos necesarios en cada
iteración. Descrito en un plan de iteración, este artefacto es una entrada importante que se utiliza cuando se
define la misión de evaluación correcta para el esfuerzo de prueba.
-
La disciplina Gestión& control de cambios controla los cambios dentro del equipo de
proyecto. El esfuerzo de prueba verifica que cada cambio se ha completado de forma apropiada.
Recomendamos la lectura del libro de Kaner, Bach & Pettichord Lessons Learned in Software Testing [KAN01], que contiene una recopilación excelente de cuestiones importantes para los
equipos de prueba.
|