Planificar la

prueba

Análisis de
Sistemas

1
Planificar la prueba
La planificación de la prueba consta de:

 Una descripción de la estrategia de prueba: Qué pruebas ejecutar,

cómo, cuándo y cómo determinar el éxito.
 Estimación de los recursos para la prueba (recursos humanos, equipos,
sistemas necesarios).
 Planificación del esfuerzo de la prueba.

Una vez planificada la prueba se procederá al diseño de la prueba.

Planeación de las pruebas de unidad

Se resumen a continuación los pasos para confeccionar un plan de pruebas
de unidades, tal como lo sugiere Eric Fraude (Braude Eric , 2003, pág. 405 –
407)

1) Decida la filosofía de las pruebas de unidades: El primer paso es

identificar qué “unidades” deben probarse y quién lo hará. Para
proyectos de desarrollo orientados a objetos, una organización
común para las pruebas de unidades es probar los métodos de cada
clase, después las clases de cada paquete y luego el paquete como
un todo.
2) Decida cómo se documentarán las pruebas de unidades: La
documentación de las pruebas de unidades consiste en los
procedimientos de prueba, los datos de entrada, el código que
ejecuta las pruebas y los datos de salida. Las pruebas de unidades
pueden estar en el paquete del código o en documentos separados.
3) Determine el alcance de las pruebas unitarias: Dado que es imposible
probar “todo”, debe definirse el alcance de las pruebas con cuidado.
Por ejemplo, si tenemos una clase CajaDeAhorro con sus métodos:
depositar(), extraer(), consultarSaldo(), las pruebas de unidad
podrían especificar que cada método se debe probarse con una
cantidad igual de datos ilegales, legales y de frontera; o tal vez los
métodos depositar() y extraer() se prueben tres veces más que los de
consulta.
En general, los métodos que cambian el estado (valores de las
variables, llamados métodos modificadores) suelen probarse en
forma más extensa que los otros (métodos selectores, que acceden
a los atributos pero sin modificar sus valores).
4) Decida cómo y dónde obtener datos para las pruebas: Se han
mencionado entradas legales, de frontera e ilegales para estos datos.

2
 También se requiere cierta generación aleatoria. Puede disponerse
de una buena cantidad de versiones anteriores de la aplicación,
fuentes estándar, entre otros. Todo eso se documenta para
referencia futura y reuso.
5) Estime los recursos requeridos: Igual que con toda la planeación, se
identifican las personas-mes y la duración requeridas para realizar las
pruebas de unidades. La fuente más importante de esta estimación
consiste en los datos históricos. Aunque las pruebas de unidades
pueden unirse al código fuente, la ejecución por separado da datos
invaluables.
6) Registre tiempo, cuenta de defectos, tipo y fuente: Los ingenieros
que participan determinan la forma exacta en la que registrarán el
tiempo dedicado a pruebas de unidades, estado de la aplicación y
pronosticar la calidad que tendrá el producto y su fecha de
terminación. Además, los datos se convierten en parte del registro
histórico de la organización.

Listas de verificación para las pruebas de métodos

Las pruebas de unidades incluyen pruebas independientes, cuando es
posible, de cada método que corresponde directamente a un requerimiento
establecido en la ERS (Especificación de Requisitos del Software), es decir,
se verifica que el método satisfaga sus requerimientos.

Dentro de su alcance limitado, ésta es una prueba de caja negra. También se

aplican pruebas de caja blanca para cada método.

Se brinda a continuación una lista de verificación para realizar pruebas de

métodos, que conviene tener a mano y consultar a la hora de diseñar los
casos de prueba de unidad:

1) Verificar la operación con valores normales de los parámetros (caja

negra)
2) Verificar la operación en los valores límite de los parámetros (caja negra)
3) Verificar la operación para en los valores de los parámetros fuera de los
límites (caja negra)
4) Asegurar que ejecuta todas las instrucciones (caja blanca – cubrimiento
de sentencias)
5) Verificar todas las trayectorias, incluidos ambos lados de todas las ramas
6) (caja blanca – cubrimiento de decisiones)
7) Verificar el uso de todos los objetos llamados
8) Verificar el manejo de todas las estructuras de datos
9) Verificar el manejo de todos los archivos
10) Verificar la terminación normal de todos los ciclos
11) Verificar la terminación anormal de todos los ciclos

3
12) Verificar la terminación normal de todas las recursiones
13) Verificar la terminación anormal de todas las recursiones
14) Verificar el manejo de todas las condiciones de error
15) Verificar el tiempo y la sincronización
16) Verificar todas las dependencias de hardware

Listas de verificación para las pruebas de clase

Una vez probados los métodos individuales, se puede pasar a la prueba de
la clase como un todo; esto significa ejecutar métodos en combinación. Una
vez más, es probable que un conjunta puramente aleatorio de
combinaciones de métodos desperdicie tiempo y de todos modos deje
huecos en la cobertura.

En la siguiente lista de verificación se encontrarán consejos para realizar

pruebas de la clase:

1) Use métodos en combinación:

1.1. Por lo común de 2 a 5 métodos.

1.2. Elija la mayoría de las secuencias primero.

1.3. Incluya las secuencias que son probables causas de defectos.

1.4. Requiere el cálculo a mano de valores de los atributos obtenidos.

2) Enfoque las pruebas de unidades a cada atributo: Inicie, después ejecute

las secuencias del método que lo afectan.

3) Verifique la transición de objetos entre los estados esperados:

3.1. Planee la secuencia de eventos de transición de estados

(basarse en el Diagrama de Estados).

3.2. Establezca el objeto en su estado inicial con los valores de las variables.

3.3. Proporcione el primer evento y verifique que ocurra la transición, y así

sucesivamente.

Planificar Pruebas de Integración

Una manera de planear y ejecutar las pruebas de integración sería la
siguiente:

4
1) Decidir cuándo y dónde almacenar, reusar y codificar las pruebas de
integración. Esto deber quedar claramente expresado en la
programación de tiempos del proyecto.
2) Asegurar que los requerimientos de las construcciones están bien
especificados.
3) Ejecutar los casos de uso que debe implementar la construcción: Realizar
la prueba contra lo documentado en la ERS (Documento de
Especificación de Requisitos del Software).
4) Realizar pruebas de regresión, para asegurar que las capacidades
existentes siguen funcionando.
5) Ejecutar las pruebas del sistema soportadas por esta construcción.

Actividades posteriores a la Planeación de la prueba

Luego de la actividad de planear la prueba deberá procederse al diseño de
la prueba, implementar componentes automatizados de prueba (de ser
posible) y luego realizar las pruebas (de integración y de sistema en el caso
del Flujo de Trabajo de Prueba del PUD ya que las pruebas de unidad se
ejecutan en el Flujo de Trabajo de Implementación).

Diseñar la prueba
En esta actividad se procederá a: identificar y describir los casos de prueba
para cada construcción, identificar y estructurar los procedimientos de
prueba especificando cómo realizar los casos de prueba.

Hay que considerar en esta actividad:

 Casos de prueba de integración, normalmente derivados de las

realizaciones de caso de uso-diseño.

 Casos de prueba de sistema, en los que se da prioridad a las

combinaciones de los casos de uso que se necesitan que funcionen en
paralelo, que se influencian entre sí si funcionan en paralelo, involucran
varios procesadores, usan recursos del sistema en quizás en forma
impredecible y compleja.

 Casos de prueba de regresión, que permiten asegurar, al finalizar una

iteración, que no se ha estropeado ninguna parte del sistema que antes
funcionaba bien y ya había sido probada. Son fundamentales en un
proceso iterativo e incremental.

5
Implementar pruebas
El propósito de esta actividad es automatizar los procedimientos de prueba
creando componentes de prueba, si es que es posible ya que no siempre es
posible o factible automatizar los procedimientos de prueba.

Realizar pruebas de integración

Durante esta actividad se procede a realizar las pruebas de integración
relevantes a la construcción realizando los procedimientos de prueba para
cada caso de prueba o ejecutando los componentes de prueba
desarrollados.

Luego se comparan los resultados de las pruebas con los resultados

esperados y se investigan los casos en que no coincidieron. Se procede
entonces a informar los defectos a los ingenieros de componentes
responsables de los componentes que se cree que tienen fallos.

También se informa de los defectos a los diseñadores de pruebas quienes

usarán los defectos para evaluar los resultados del esfuerzo de prueba.

Realizar prueba de sistema

La prueba de sistema puede comenzar cuando las pruebas de integración
indican que el sistema satisface los objetivos de calidad de integración
fijados en el plan de prueba de la iteración actual.

Tipos de prueba
Niveles de prueba
Todo proceso de prueba de software consiste en tres niveles de prueba:
pruebas de unidad, de integración y de sistema. En el Proceso de Desarrollo
Unificado, las pruebas de unidad se realizan el Flujo de Trabajo de
Implementación y las pruebas de integración y de sistema en el Flujo de
Trabajo de Prueba, que tratamos en esta unidad.

Las pruebas de unidad son el primer tipo de pruebas que se realizan. Por
referirse principalmente a la prueba de métodos de las clases, se ubican
naturalmente en el Flujo de Trabajo de Implementación ya que es normal

6
que quien realiza la codificación de la clase vaya realizando la prueba de sus
métodos.

El siguiente nivel de pruebas consiste en las pruebas de integración. Esto

valida la funcionalidad global de cada etapa de la aplicación parcial.

Por último las pruebas de sistema y de aceptación validan el producto final.

La siguiente figura ilustra los niveles de prueba:

Fuente: Libro “Ingeniería de Software – Una perspectiva orientada a objetos” – Eric Braude, 2003,
Pág. 395.

Pruebas de Unidad
La meta de las pruebas de unidades es estructural mientras que el otro tipo
de pruebas es funcional típico. Como se muestra en el gráfico de la página
anterior, en general las funciones son las partes más pequeñas a las que se
aplican las pruebas de unidades. En el caso de la orientación a objetos se
refiere a los métodos de una clase. La siguiente unidad en tamaño es el
módulo, que en nuestro caso se refiere a una clase. Algunas veces, las
“combinaciones de módulos” se consideran unidades para los propósitos de
las pruebas (estos serían paquetes o subsistemas).

Las unidades a las que se aplican las “pruebas de unidad” son los bloques de
construcción de la aplicación, algo así como los ladrillos individuales sobre
los que se apoya una casa. Si algunos de estos “ladrillos” son defectuosos,
una vez integradas las partes defectuosas en una aplicación, puede tomar
mucho tiempo identificarlas y repararlas. Por ello, los bloques de
construcción de software deben ser completamente confiables y esta es la
meta de las pruebas de unidad.

7
En términos del PUD (Proceso de Desarrollo Unificado), las pruebas unitarias
se llevan a cabo durante las iteraciones de la fase de Elaboración y también
en las primeras iteraciones de la Construcción.

Pasos para realizar pruebas de unidad

La siguiente figura, basada en el estándar IEEE 1008-1987, muestra un mapa

conceptual típico para las pruebas de unidades:

Fuente: Libro “Ingeniería de Software. Una perspectiva orientada a objetos” Eric Braude, 2003, Pág.
397.

Los pasos que requiere el estándar IEEE (1008-1987) para las pruebas de
unidades, que amplían el mapa conceptual anterior, son:

1) Planear el enfoque general, recursos y programa de tiempos.

2) Determinar las características basadas en los requerimientos que deben
probarse.
3) Refinar el plan general.
4) Diseñar un conjunto de pruebas.
5) Implementar el plan y diseño refinados.
6) Ejecutar los procedimientos de pruebas.
7) Verificar que terminen.
8) Evaluar el esfuerzo y la unidad de las pruebas.

Tipos de pruebas de unidad

Generalmente una prueba de unidad consiste en una evaluación estructural
(o prueba de caja blanca), lo cual significa que se usan los conocimientos de
cómo la unidad es diseñada internamente, y una evaluación de
especificación (o prueba de caja negra), la cual usa lo opuesto: se aplican
los test solamente sobre la especificación de los comportamientos de la
unidad visibles externamente.

8
En el caso de sistemas orientados a objetos también se necesitan ejecutar
tests basados en estados encapsulados de objetos y la interacción de
operaciones, a las que se denomina evaluación basada en estado.

Pruebas de Caja Negra

Cuando el único interés de una prueba es si una aplicación o parte de ella
proporciona la salida adecuada, se prueba que cumpla cada requerimiento
al usar la entrada apropiada. Esto se llama prueba de caja negra porque no
se pone atención al interior de la “caja” (la aplicación).

Las pruebas de caja negra pueden ser suficientes si se puede asegurar que
agotan todas las combinaciones de entrada. Esto probaría al cliente que
todos los requerimientos se satisfacen. Sin embargo, ninguna prueba cubre
todas las posibilidades.

Fuente: Libro “Ingeniería de Software. Una perspectiva orientada a objetos” Eric Braude, 2000, Pág.
398.

Como no se pueden probar todas las combinaciones, se buscan casos de

prueba representativos. El problema es representar de la mejor manera el
conjunto infinito de posibilidades con un conjunto finito tan representativo
como sea posible.

La partición de equivalencia es la división de los datos de entrada de las

pruebas en subconjuntos tales que si cualquier entrada única tiene éxito,
entonces es probable que todas las demás entradas tengan éxito.

Por ejemplo al probar el método tomarNombre(String), pasar la prueba para

tomarNombre (“Francisco”) significa que tal vez no se encuentren defectos
al probar tomarNombre() en cada cadena de nueve caracteres alfabéticos.
Sin duda, quizá ese conjunto de equivalencia se pueda extender a “todos los
nombres con un número de caracteres mayor que cero y menor que
maxNumCarEnNombre() (función que determina el máximo número de
caracteres aceptados para el nombre).”

En general, se llega a las particiones de equivalencia mediante la

investigación de los valores que limitan las variables dentro de la aplicación.

9
Por ejemplo, en un caso de un sistema académico de cursado de materias
en una facultad, los valores válidos para las notas de los parciales van entre
0 y 10 (0 se consideraría un Ausente), esto proporciona dos fronteras. Ahora
bien, que la nota sea mayor o igual a 4 tiene un significado especial (es la
nota inferior para aprobar), esto introduciría una frontera adicional. Al
diseñar las pruebas, también se usan los valores fuera de estas fronteras (es
decir, las entradas no válidas) como datos de prueba.

Ejemplo: Prueba de un método de la clase MateriaAlumno

Método: verificarRegularidad

Tablas de partición del intervalo para las pruebas de unidad

10
Pruebas de Caja Blanca
La idea de las pruebas de caja blanca es verificar los elementos de la
aplicación y la manera en que se ensamblaron. La meta de las pruebas de
caja blanca es probar las líneas de falla más probables de la aplicación.

Para realizar pruebas de caja blanca, primero se desglosa el diseño de la

aplicación en busca de trayectorias y otras particiones de control y datos.
Después se diseñan pruebas que recorran todas o algunas de estas
trayectorias y se ejecutan todas las partes o elementos. Un nombre que
describe mejor esta actividad es “pruebas de caja de vidrio”.

Fuente: Libro “Ingeniería de Software. Una perspectiva orientada a objetos” Eric Braude, 2000, Pág.
398.

Cada sentencia en un programa debe ejecutarse en al menos una prueba.

Esta cobertura es necesaria. Sin embargo, la cobertura de sentencias de
ninguna manera es suficiente para asegurar que un programa sea correcto.

La cobertura de decisiones asegura que el programa toma cada rama de

cada decisión. Por ejemplo, asegurar que cada “SI” y cada “NO” de cada
decisión se ha seguido por lo menos una vez en las pruebas del conjunto. La
cobertura de decisiones asegura también, que se ejecute cada iteración de
cada ciclo. Esto se puede hacer de manera que cada iteración de cada ciclo
se ejecute al menos una vez.

Este enfoque no es difícil para ciclos (sentencias FOR y equivalentes), pero

introduce complicaciones en los ciclos de while. En ocasiones se pueden
enumerar todas las posibilidades, otras se puede hacer una partición en
grupos. Sin embargo, algunas veces es casi imposible una cobertura
completa de las decisiones para los ciclos while.

11
Pruebas basadas en los estados
Como ya se ha visto, los objetos de las clases muchas veces se pueden
interpretar como transiciones entre estados en respuesta a los eventos. Por
lo tanto, deben probarse esas clases en términos de su estado. Las pruebas
basadas en estado prueban la interacción entre las operaciones de una clase
monitoreando los cambios que tienen lugar en los atributos de los objetos.
Probar sólo una operación aislada no es suficiente para probar una unidad,
se debe probar también los atributos del objeto.

Una prueba consistiría en la estimulación del sistema de manera que transite

por una secuencia de estados. Habría que probar todas las secuencias de
estados válidas y también introducir eventos que no se aplican a estados
particulares, para asegurar que no afectan a la aplicación. Es importante
basarse en los diagramas de transición de estados, así nos aseguramos que
cada estado es visitado al menos una vez y cada transición es atravesada al
menos una vez.

La matriz de estados es una buena herramienta para este tipo de pruebas.

La combinación de estados y estímulos puede probarse con esta matriz.

Una de las ventajas de este tipo de matrices es que focaliza la atención del
diseñador en la combinación estímulo (evento)/estado que puede ser

12
descuidada durante el diseño. Es posible incluir todas las combinaciones de
atributos del objeto (todos los posibles valores de las variables) y todas las
variantes de estímulo (distintos parámetros). En general algunas
combinaciones específicas de atributos pueden ser más interesantes que
otras. Algunas operaciones, como las de lectura, que no afectan el estado,
no necesitan ser consideradas.

Debe verificarse que todos los posibles estados pueden alcanzarse con
alguna combinación de operaciones, de otra manera puede haber una falla
en el diseño de la clase.

Pruebas de Integración
Concepto de Integración

Debido a que las aplicaciones son complejas, deben construirse con partes
que primero se desarrollan por separado. La “integración” se refiere a este
proceso de ensamble. Se realizan varios tipos de pruebas en los ensambles
parciales de la aplicación y en toda ella. La etapa de integración suele
producir sorpresas desagradables por incompatibilidad de las partes que se
integran. Por esto, el Proceso de Desarrollo Unificado, en particular, intenta
evitar la integración “explosiva” mediante la integración continua con
múltiples iteraciones.

Cuando se desarrolla la arquitectura, una consideración importante es la

facilidad con que se pueden integrar las partes. Sin embargo, rara vez es
factible completar los módulos individuales de software antes de la
integración. Aunque el proceso de construcción típico tiene la desventaja de
trabajar con unidades incompletas, posee la ventaja de ejercer la integración
antes en el proceso de desarrollo. Esto ayuda a eliminar los riesgos, al evitar
la integración “explosiva”.

Las dificultades de integrar las aplicaciones resaltan la importancia de

diseñar unidades (como clases y paquetes) que se centren en un propósito
lo más que sea posible, disminuyendo sus interfaces mutuas todo lo que se
pueda. Estas metas, “alta cohesión” y “bajo acoplamiento”,
respectivamente, se analizaron en la actividad de diseño.

Cuando se aplica a la integración, la verificación se reduce a confirmar que

se están uniendo justo los componentes que se planeó ensamblar, justo en
la forma que se planeó ensamblarlos. Esa verificación se puede realizar
mediante la inspección de los productos de la integración.

Realizar pruebas se simplifica con la incorporación de implementaciones de

casos de uso completos en cada construcción en lugar de sólo partes de un

13
caso de uso. Crear casos de uso relativamente pequeños desde el principio
facilita su ajuste en las construcciones.

Proceso de pruebas de Integración

Los casos de uso son una fuente ideal de casos de prueba para las pruebas
de integración. La idea es que los casos de uso se construyan sobre los que
ya están integrados para formar pruebas cada vez más representativas del
uso de la aplicación, como se muestra en la siguiente figura:

Fuente: Libro “Ingeniería de Software. Una perspectiva orientada a objetos” Eric Braude, 2000, Pág.
445.

Se requiere un número grande de pruebas para validar una aplicación de

manera adecuada, y necesitan una organización metódica. Un estilo de
organizar los casos de prueba es ponerlos en un paquete en clases
especialmente creadas para las pruebas. Una clase o quizá un paquete
entero, se puede dedicar a probar toda la aplicación.

Por lo general, las construcciones consisten en el código de varios

desarrolladores y es común encontrar muchos problemas cuando se integra
el código para crear la construcción. Por ello, se intenta comenzar la
integración y las pruebas de integración pronto en el proceso, para ejecutar
el código en su contexto final.

Pruebas de Interacción
Las interacciones entre casos de uso son las áreas más difíciles de probar,
debido a la gran cantidad de combinaciones posibles aún en un sistema de
tamaño moderado.

14
Una forma de buscar interacciones es buscar objetos compartidos entre
casos de uso. Para esto se pueden utilizar matrices CRUD
(Create/Read/Update/Delete - Crear/Leer/Actualizar/Borrar), buscando
principalmente las situaciones en las que los objetos son leídos, actualizados
o borrados en un caso de uso y creados en otro.

Veamos como ejemplo la matriz CRUD para el caso de un sistema académico

simplificado:

Del análisis de esta matriz vemos que en diversos casos de uso se “leen”
objetos “alumno, materia y profesor”, pero nunca son creados. En este caso
debe considerarse si:

 Se agregan casos de uso necesarios en nuestro sistema, o

 Si los datos serán proporcionados por otro sistema.

De cualquier manera, debemos asegurarnos que los objetos existan para

poder realizar las pruebas de nuestro sistema.

Pruebas de Sistema
La prueba del sistema es la culminación de las pruebas de integración.
Consiste en pruebas de caja negra que validan la aplicación completa contra
sus requerimientos (funcionales y no funcionales).

Siempre que sea posible, las pruebas del sistema se realizan mientras la
aplicación se ejecuta en su entorno requerido. Sin embargo, en ocasiones
habrá que conformarse con pruebas de ejecuciones del sistema en un
entorno o configuración que no es equivalente a la del cliente.

La confiabilidad/disponibilidad se determinan mediante medidas como el

tiempo medio entre fallas: MTBF (mean time between failures). Para
obtener el MTBF primero se establece una definición de “falla”, por ejemplo
la deshabilitación total de la aplicación (se pueden definir varios niveles de
falla). Para calcular el MTBF, un probador inicia la aplicación, registra la hora

15
y ejecuta la aplicación con un escenario aleatorio, hasta que el sistema falla.
Registra la hora y calcula el tiempo transcurrido. Este proceso se realiza
muchas veces. El MTBF es el promedio de los tiempos obtenidos.

A continuación se enumeran distintos tipos de pruebas de sistema:

 Volumen: Somete al producta a la entrada de grandes cantidades de

datos.

 Utilidad: Mide la reacción del usuario, por ejemplo con una calificación
del 0 a 10 (ver más detalles debajo).

 Desempeño: Mide la velocidad para varias circunstancias.

 Configurabilidad: Configura los distintos elementos de

hardware/software. Por ejemplo, mide el tiempo de preparación.

 Compatibilidad: Con otras aplicaciones designadas. Por ejemplo, mide

el tiempo de adaptación.

 Seguridad: Sujeta a intentos comprometedores. Por ejemplo, mide el

tiempo promedio para entrar (romper) al sistema.

 Uso de recursos: Mide el uso de RAM, espacio en disco, entre otros.

 Aptitud de instalación: Mide el tiempo de instalación.

 Recuperabilidad: Fuerza actividades que desactivan la aplicación y mide

el tiempo de recuperación.

 Funcionalidad: Da servicio a las aplicaciones en diferentes

circunstancias, mide el tiempo de servicio. El término funcionalidad se
refiere a la facilidad o dificultad con que la aplicación se mantiene
operativa. Por ejemplo, una aplicación de sistema experto se apoya en
su base de conocimientos, que debe ser capaz de modificarse con
facilidad.

Pruebas de Utilidad
Una buena interfaz puede mejorar mucho el valor de la aplicación. La prueba
de utilidad valida la aceptación de la aplicación por los usuarios. Una manera
de hacer esto es cuantificar el nivel de satisfacción que informan los usuarios
al usar la aplicación.

Algunos criterios esenciales para estas pruebas son los siguientes:

16
 Accesibilidad: Facilidad con la que entran, navegan y salen los usuarios.
Por ejemplo, medida por el tiempo promedio que toma.

 Rapidez de respuesta: Qué tan rápido permite la aplicación al usuario

lograr sus metas especificadas. Por ejemplo, medida del tiempo
promedio que toma.

 Eficiencia: Qué tan pequeños son los pasos requeridos para la

funcionalidad elegida. Por ejemplo, medida por el tiempo mínimo de
una muestra de usuarios.

 Comprensión: La facilidad con que se entiende y usa el producto

mediante la documentación y la ayuda en línea. Por ejemplo, medida
por el tiempo que toman las investigaciones estándar.

Pruebas de Regresión
Cuando una aplicación crece, las pruebas del sistema adquieren un
significado especial. Esto es en especial notorio cuando se hace un cambio
en una aplicación grande y los desarrolladores necesitan validad el hecho de
que el cambio no haya afectado la funcionalidad existente.

La primera pregunta después de integrar el cambio casi siempre es la

siguiente: “¿es este producto el mismo que el anterior, con la funcionalidad
agregada?”. En general, la reinspección no es práctica, por lo que una
manera práctica importante de ayudar a contestar esta pregunta es verificar
que el sistema continúe pasando el mismo conjunto de pruebas diseñado
antes de hacer los cambios. Este proceso de verificación se llama pruebas de
regresión. Si el tiempo no permite realizar las pruebas completas, se
seleccionan aquellas con mayor probabilidad de fallar debido a los cambios.

Pruebas de Aceptación
La organización desarrolladora y la del cliente son las partes de un contrato.
Cuando termina un trabajo, un desarrollador inteligente obtiene una
declaración definitiva del cliente que establece que de hecho la aplicación
está entregada.

Las pruebas de aceptación están diseñadas para asegurar al cliente que se

construyó la aplicación estipulada. Las pruebas de aceptación tal vez no sean
muy diferentes de las pruebas del sistema que diseña el desarrollador, pero

17
la organización del cliente es el testigo y se ejecutan en la plataforma que
van a operar.

Evaluación de la prueba
En esta actividad, los diseñadores de pruebas evalúan los resultados del
esfuerzo de la prueba comparando los resultados obtenidos con los
objetivos establecidos en el plan de prueba.

Como resultado de esta actividad se preparan métricas que les permiten

determinar el nivel de calidad del software y qué cantidad de pruebas son
necesarias.

Fundamentalmente se observan dos métricas:

 Compleción de la prueba: Indica el porcentaje de casos de prueba que

han sido ejecutados y el porcentaje de código que ha sido probado.

 Fiabilidad: Se basa en el análisis de las tendencias en los defectos

detectados y en las tendencias en las pruebas que se ejecutan con el
resultado esperado.

Para determinar la fiabilidad del sistema, los diseñadores de pruebas crean

diagramas de las tendencias de los defectos, donde representan la
distribución de tipos específicos de defectos a lo largo del tiempo. La prueba
puede crear también diagramas de tendencias que representan el
porcentaje de pruebas ejecutas con éxito (es decir con los resultados
esperados) a lo largo del tiempo.

Basándose en el análisis de la tendencia de los defectos, los diseñadores de

pruebas pueden sugerir otras acciones, como por ejemplo:

 Realizar pruebas adicionales para localizar más defectos, si la fiabilidad

medida sugiere que el sistema no en un nivel de madurez apropiado.
 Relajar el criterio para las pruebas, si los objetivos de calidad para la
iteración actual se pusieron demasiado altos.
 Aislar las partes del sistema que parecen tener una calidad aceptable y
entregarlas como resultado de la iteración actual. Las partes que no
cumplen los criterios de calidad deben ser revisados y probados
nuevamente.

18
Referencias
Booch Grady, Rumbaugh James, Jacobson Ivar (1999) “El lenguaje de
Modelado Unificado”, España, Addison Wesley Iberoamericana. Capítulos: 25,26,
29 y 30

Braude Eric (2003) “Ingeniería de Software, una perspectiva orientada a objetos”,

Alfaomega Grupo Editor SA. Capítulo: 8 y 9

Jacobson Ivar, Booch Grady, Rumbaugh James (2000) “El Proceso

Unificado de Desarrollo de Software”, España, Addison Wesley. Capítulos: 10 y 11
Larman Craig (2003) “UML y Patrones. Una introducción al análisis y diseño
orientado a objetos y al proceso unificado”, 2da. Edición, España, Prentice Hall.
Capítulo: 20

Pressman Roger (2006) “Ingeniería de Software. Un enfoque práctico”

6ta. edición, McGraw Hill. Capítulos 10

Rubble David (1998) "Análisis y Diseño práctico de Sistemas Cliente/Servidor con

GUI". Prentice Hall. Capítulo: 8

Sommerville Ian (2002) “Ingeniería de Sofware”, Ed. Pearson Educación, México.

Capítulo: 10

19