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.
|