Disciplina: Prueba
Esta disciplina proporciona orientación sobre cómo evaluar y valorar la calidad del producto.
Relaciones
Descripción principal

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.

Relación con otras disciplinas

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.

Más información

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.

Más información