Concepto: Niveles de prueba
En esta directriz se categorizan las actividades de prueba en pruebas de desarrollador, independientes, de unidad, de integración, del sistema y de aceptación.
Relaciones
Elementos relacionados
Descripción principal

Las pruebas se aplican a diferentes tipos de destinos, en fases o niveles diferentes de esfuerzo de trabajo. Estos niveles suelen distinguirlos los roles que están más capacitados para diseñar y dirigir las pruebas, donde las técnicas son más adecuadas para realizar la prueba en cada nivel. Es importante asegurarse de hay un equilibrio entre los diferentes esfuerzos de trabajo.

Prueba de desarrollador

La prueba de desarrollador indica los aspectos de diseño e implementación de la prueba más adecuados que debe llevar a cabo el equipo de desarrolladores, a diferencia de la prueba independiente. En la mayoría de los casos, la ejecución de la prueba se produce inicialmente con el grupo de pruebas de desarrollador que la diseñó e implementó; aunque es recomendable que los desarrolladores creen las pruebas de forma que estén disponibles para que las ejecuten grupos de pruebas independientes.

Tradicionalmente, la prueba de desarrollador se consideraba, principalmente, con respecto a la prueba de unidad. Algunos desarrolladores también realizan pruebas de integración de diferentes niveles, aunque depende básicamente de la cultura y otros aspectos contextuales. Es recomendable que la prueba de desarrollador no cubra únicamente unidades independientes de prueba aisladas.

Prueba independiente

Las pruebas independientes indican el diseño y la implementación de la prueba realizados más adecuadamente por alguien ajeno al equipo de desarrolladores. Puede considerar esta distinción un superconjunto, que incluye validación y verificación independientes. En la mayoría de los casos, la ejecución de la prueba se produce inicialmente con el grupo de pruebas independientes que la diseñó e implementó; aunque los verificadores independientes deberían crear sus pruebas de forma que estén disponibles para que las ejecuten los grupos de pruebas de desarrollador. Boris Beizer ofrece la siguiente explicación del objetivo diferente que tiene la prueba independiente en comparación con la prueba de desarrollador.

"The purpose of independent testing is to provide a different perspective and, therefore, different tests; furthermore to conduct those tests in a richer [...] environment than is possible for the developer." (El objetivo de las pruebas independientes es proporcionar una perspectiva diferente y, por lo tanto, pruebas diferentes; además de dirigir estas pruebas a un entorno más rico [...] de lo que es posible para el desarrollador). [BEI95]

Prueba independiente de los interesados

Las pruebas independientes se pueden ver, de forma alternativa, como representaciones de pruebas basadas en las necesidades y las preocupaciones de varios interesados; por eso también se conocen como pruebas de los interesados. Esta distinción es importante, puesto que ayuda a incluir un conjunto más amplio de preocupaciones de los interesados de las que se pueden tener en cuenta normalmente, y amplía el "cliente" un tanto genérico con interesados, como pueden ser el personal de soporte técnico, los formadores técnicos y el personal de ventas, además de los clientes y los usuarios.

A modo de comentario final, la noción de XP de pruebas del cliente está relacionada con esta categorización de pruebas independientes en RUP.

Prueba de unidad

La prueba de unidad se centra en la verificación de los elementos más pequeños del software que se puedan probar. Normalmente, las pruebas de unidad se aplican a componentes representados en el modelo de implementación para verificar que se cubren los flujos de control y los flujos de datos y que funcionan como se esperaba. El implementador realiza la prueba de unidad mientras se desarrolla la unidad. Los detalles de la prueba de unidad se describen en la disciplina de implementación.

Prueba de integración

Las pruebas de integración se realizan para garantizar que los componentes del modelo de implementación funcionan correctamente cuando se combinan para ejecutar un guión de uso. El destino de la prueba es un paquete o un conjunto de paquetes del modelo de implementación. A menudo, los paquetes que se combinan proceden de diferentes empresas de desarrollo. Las pruebas de integración exponen el estado incompleto o los errores de las especificaciones de la interfaz del paquete.

En algunos casos, los desarrolladores presuponen que otros grupos, como los verificadores independientes, son los encargados de realizar las pruebas de integración. Esta situación supone un riesgo para el proyecto de software y, en última instancia, para la calidad del software, puesto que:

  • las áreas de integración son un punto común de fallo del software.
  • las pruebas de integración realizadas por verificadores independientes suelen utilizar técnicas de caja negra y tratar componentes de software más grandes.

Un enfoque mejor es considerar las pruebas de integración como responsabilidad tanto del desarrollador como de los verificadores independientes, e impedir que la estrategia de esfuerzo de prueba de los equipos no se superponga de forma significativa. La naturaleza exacta de esta superposición se basa en las necesidades del proyecto individual. Es recomendable que fomente un entorno donde los desarrolladores y los verificadores independientes del sistema compartan una visión única de la calidad. Consulte el apartado Concepto: Prueba de desarrollador para obtener información adicional.

Prueba del sistema

Normalmente, la prueba del sistema se realiza cuando el software funciona en su totalidad. Un ciclo vital repetitivo permite que las pruebas del sistema se realicen mucho antes, en cuanto se hayan implementado subconjuntos bien formados del comportamiento de guiones de uso. Normalmente, el destino son los elementos en funcionamiento de extremo a extremo del sistema.

Prueba de aceptación

La prueba de aceptación del usuario es la última acción de prueba antes de desplegar el software. El objetivo de la prueba de aceptación es comprobar si el software está preparado y lo pueden utilizar los usuarios para realizar las funciones y tareas para las que se diseñó. Consulte el apartado Concepto: Prueba de aceptación para obtener información adicional.

Hay otras nociones de prueba de aceptación, que generalmente se caracterizan por un rechazo de un grupo o un equipo a otro. Por ejemplo, una prueba de aceptación de compilaciones es la prueba que se realiza para aceptar la entrega de una compilación de software nueva del desarrollo en una prueba independiente.

Un comentario acerca de la secuencia y el tiempo de los niveles de prueba

Normalmente, se cree que las pruebas de unidad se implementan al principio de la iteración, como primera fase de pruebas: es necesario que se aprueben todas las unidades antes de que pasar a las fases posteriores. Sin embargo, en un proceso de desarrollo repetitivo, este enfoque es, por regla general, inadecuado. Es más apropiado identificar las pruebas de unidad, de integración y del sistema que ofrecen más potencial para detectar errores y, a continuación, implementarlas y ejecutarlas en función de una combinación de un entorno de mayor riesgo y soporte.