I.

PRUEBAS DE SISTEMA

1. CONCEPTO

Las pruebas del sistema es una forma de tratar de demostrar que el sistema no cumple sus
especificaciones de requisitos y no se puede utilizar. Se puede consumir tanto como la mitad
de los recursos de las pruebas.
Las pruebas de sistema buscan discrepancias entre el programa y sus objetivos o
requerimientos, enfocándose en los errores hechos durante la transición del proceso al
diseñar la especificación funcional. Esto hace a las pruebas de sistema un proceso vital de
pruebas, ya que, en términos del producto, número de errores hechos, y severidad de esos
errores, es un paso en el ciclo de desarrollo generalmente propenso a la mayoría de los
errores.

Cualquier pieza de software completo, desarrollado o adquirido, puede verse como un

sistema que debe de probarse, ya sea decidir acerca de su aceptación, para analizar defectos
globales o para estudiar aspectos específicos de su comportamiento, tales como seguridad,
rendimiento. A este tipo de pruebas donde se estudia el producto completo se les llama
pruebas de sistemas.

2. OBJETIVOS
Las pruebas de sistema tienen como objetivo ejercitar profundamente el sistema
comprobando la integración del sistema de información globalmente, verificando el
funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y
con el resto de sistemas de información con los que se comunica.

3. IMPORTANCIA DE LAS PRUEBAS DE SISTEMA

Las pruebas de sistemas son importantes por lo siguiente:

 Es donde se prueba el sistema como un todo dentro del ciclo de vida del desarrollo
del sistema.
 El sistema es probado para verificar si cumple con sus requisitos funcionales y
técnicos.
 El sistema es probado en un entorno lo más parecido al entorno de producción.
 Las pruebas de Sistema permiten probar, verificar y validar, tanto los requisitos de
negocios como la arquitectura de la aplicación.
 PRUEBAS DE SISTEMA Y ACEPTACION

4. TIPOS DE PRUEBAS DE SISTEMAS

 Prueba de recuperación.

 Prueba de seguridad.

 Prueba de resistencia.

 Prueba de desempeño.

 Pruebas de comunicaciones.

 Pruebas de volumen.

 Pruebas de tensión.

 Pruebas de disponibilidad de datos.

 Pruebas de facilidad de uso.

 Pruebas de operación.

 Pruebas de entorno.

 Pruebas de almacenamiento.

 Pruebas de configuración.

 Pruebas de instalación.

 Pruebas de la documentación.

4.1. Prueba de Recuperación

Muchos sistemas de cómputo deben de recuperarse de fallas y reanudar el

procesamiento en el tiempo determinado. En algunos casos, un sistema debe ser
tolerante con las fallas; es decir, las fallas de procesamiento no deben llevar a la caída del
sistema, en general. En otros casos una falta del sistema debe de corregir dentro de un
periodo específico o se sufrirá un fuerte daño económico.

La prueba de recuperación es una prueba de sistema que obliga al software a fallar de

varias maneras y a verificar que la recuperación se realice apropiadamente. Si la
recuperación es automática (la realiza el propio sistema) debe de evaluarse que sean
correctos la re-inicialización, los mecanismos de respaldo del sistema, la recuperación de
datos y el nuevo arranque. Si la recuperación requiere de intervención humana, se debe
evaluar el tiempo medio de recuperación (TMR) para determinar si se encuentra dentro
de los límites aceptables.

2
 PRUEBAS DE SISTEMA Y ACEPTACION

4.2. Prueba de Seguridad

Cualquier sistema de cómputo que maneje información confidencial o que

desencadenen acciones que dañen o beneficien inapropiadamente a los individuos es
un blanco para irrupciones impropias o ilegales.

La prueba de seguridad comprueba que los mecanismos de protección integrados en el

sistema realmente lo protejan de irrupciones inapropiadas.

Durante la prueba de seguridad, quien la aplica desempeña el papel del individuo que
desea entrar en el sistema. ¡Todo vale! Debe de tratar de obtener contraseñas por
cualquier medio externo; podría atacar el sistema con software personalizados, diseñados
para burlar cualquier defensa que se haya construido; podría saturar el sistema, negando
así el servicio a otros; podría producir errores intencionales en el sistema para tratar de
tener acceso durante la recuperación: podría revisar datos sin protección, con la idea de
encontrar la clave de acceso al sistema.

4.3. Prueba de Resistencia

Los pasos de prueba analizados antes en este trabajo, llevan a una evaluación completa
de las funciones y el desempeño normalmente del programa. Las pruebas de resistencia
están diseñadas para confrontar los programas en situaciones anormales. En esencia, la
persona que realiza la prueba de resistencia se preguntará: ¿Hasta dónde llevar esto
antes de que falle? La prueba de resistencia ejecuta un sistema de tal manera que
requiera una cantidad, una frecuencia o volumen anormal de recursos.

4.4. Prueba de Desempeño

La prueba de desempeño está diseñada para probar el desempeño del software en
tiempos de ejecución dentro del contexto de un sistema integrado. La prueba de
desempeño se aplica en todos los pasos del proceso de la prueba. Incluso al nivel de la
unidad. El desempeño de un módulo individual debe de evaluarse mientras se realizan
las pruebas. Sin embargo, no es sino hasta que se encuentre totalmente integrado todos
los elementos del sistema que es posible asegurar el verdadero desempeño del sistema.

Con frecuencia las pruebas de desempeño se vinculan con pruebas de resistencia y

suelen requerir instrucción de software y hardware. Es decir, a menudo resulta necesario
medir con exactitud la utilización de recursos (por ejemplo: los ciclos de procesador).
Mediante instrumentación externa pueden vigilarse de manera regular los intervalos de

3
 PRUEBAS DE SISTEMA Y ACEPTACION

ejecución, los eventos que se registran (como las interrupciones) y los estados de muestra
del equipo. Si se instrumenta un sistema, la persona que aplica la prueba descubrirá
situaciones que lleven a la degradación y posibles fallas del sistema.

4.5. Prueba de Comunicaciones

Determinan que las interfaces entre los componentes del sistema funcionan
adecuadamente, tanto a través de dispositivos remotos, como locales. Así mismo, se han
de probar las interfaces hombre/máquina.

4.6. Prueba de Volumen

Consisten en examinar el funcionamiento del sistema cuando está trabajando con
grandes volúmenes de datos, simulando las cargas de trabajo esperadas.

4.7. Prueba de Tensión

La prueba de tensión es poner al programa a grandes cargas o tensiones. Esto no se
debe confundir con la prueba de volumen; una gran tensión es volumen máximo de
datos, o de actividad, en un tiempo corto. Una analogía sería evaluar a un mecanógrafo.
Una prueba de volumen se determinaría si el mecanógrafo hiciera frente a un bosquejo
de un informe grande; una prueba de tensión se determinaría si el mecanógrafo puede
mecanografiar a un índice de 50 palabras por minuto.

4.8. Prueba de Disponibilidad de datos

Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo
físico como lógico, sin comprometer la integridad de los datos.

4.9. Prueba de Facilidad de uso

Consisten en comprobar la adaptabilidad del sistema a las necesidades de los usuarios,
tanto para asegurar que se acomoda a su modo habitual de trabajo, como para
determinar las facilidades que aporta al introducir datos en el sistema y obtener los
resultados.

4
 PRUEBAS DE SISTEMA Y ACEPTACION

4.10. Prueba de Operación

Consisten en comprobar la correcta implementación de los procedimientos de

operación, incluyendo la planificación y control de trabajos, arranque y re arranque del
sistema.

4.11. Prueba de Entorno

Consisten en verificar las interacciones del sistema con otros sistemas dentro del mismo
entorno.

4.12. Prueba de Almacenamiento

Los programas tienen de vez en cuando objetivos de almacenamiento que indiquen,

por ejemplo, la cantidad de memoria principal y secundaria que el programa usa y el
tamaño de los archivos temporales. Se diseñan casos de prueba para demostrar que
estos objetivos de almacenaje no han sido encontrados.

4.13. Prueba de Configuración

Programas tales como sistemas operativos, sistemas de gerencia de base de datos, y

programas de conmutación de mensajes soportan una variedad de configuraciones de
hardware, incluyendo varios tipos y números de dispositivos de entrada-salida y líneas
de comunicaciones, o diversos tamaños de memoria. A menudo el número de
configuraciones posibles es demasiado grande para probar cada uno, pero en lo posible,
se debe probar el programa con cada tipo de dispositivo de hardware y con la
configuración mínima y máxima. Si el programa por sí mismo se puede configurar para
omitir componentes, o si puede funcionar en diversas computadoras, cada configuración
posible de este debe ser probada.

4.14. Prueba de Instalación

Algunos tipos de sistemas de software tienen complicados procedimientos de instalación.
Las pruebas de los procedimientos de instalación es una parte importante del proceso
de prueba del sistema. Esto es particular de un sistema automatizado de instalación que
sea parte del paquete del programa. Al funcionar incorrectamente el programa de
instalación podría evitar que el usuario tenga una experiencia acertada con el sistema. La
primera experiencia de un usuario es cuando él o ella instalan la aplicación. Si esta fase
se realiza mal, entonces el usuario/el cliente puede buscar otro producto o tener poca
confianza en la validez de la aplicación.

5
 PRUEBAS DE SISTEMA Y ACEPTACION

4.15. Prueba de Documentación

Las pruebas de sistema también se refieren a la exactitud de la documentación del

usuario. Una manera de lograr esto es utilizar la documentación para determinar la
representación de los casos anteriores de prueba del sistema. Esto es, una vez se desea
idear el caso de sobrecarga, se utilizaría la documentación como guía para escribir el
caso de prueba real. También, la documentación del usuario debe ser el tema de una
inspección, comprobándola para saber si hay exactitud y claridad. Cuales quiera de los
ejemplos ilustrados en la documentación se deben probar y hacer parte de los casos y
alimentarlos al programa.

5. PRINCIPIOS BASE PARA LA PRUEBA

Al aplicar esos conceptos a la prueba de software, se obtienen una serie de principios que
servirán de base para la prueba:

 Debe asegurarse de conocer con precisión los objetivos del software a probar. Esto
se localizan en los documentos obtenidos en la etapa de recolección de
requerimientos, así como en las especificaciones del software.

 Deben determinarse las entradas y salidas del sistema aprobar. Éste aspecto es
necesario en la preparación de los casos de prueba y también en el establecimiento
de procedimientos de prueba.

 Considerar el sistema mayor donde opera el software a probar. Generalmente es un

ambiente organizacional, formado por elementos de hardware, de software y
personas (usuarios).

6. VISIÓN SISTÉMICA DE LA PRUEBA

Cuando se deben realizar pruebas, debe mantenerse un enfoque sistémico, es decir

integral, que está detrás de todo desarrollo de software. Al hablar de enfoque sistémico se
indica que:

 Todo sistema tiene una serie de objetivos que le dan sentido. Esos objetivos están
asociados con indicadores de éxito que permiten determinar si los objetivos se
cumplen y en qué medida.

6
 PRUEBAS DE SISTEMA Y ACEPTACION

 Todo sistema tiene una serie de elementos que lo forman y la interacción de tales
elementos se orienta a satisfacer los objetivos.

 Todo sistema tiene una frontera que lo separa de un medio ambiente. Los
elementos de ese medio ambiente influyen sobre el sistema proporcionándoles
una serie de entradas y obteniendo del mismo un conjunto de salida.

 Ningún Sistema existe en aislamiento; siempre interaccionan con otros sistemas

constituyendo un sistema mayor.

7. VISIÓN GENERAL DE LA PRUEBA DE SISTEMA

El proceso de prueba de un sistema tiene dos etapas que pueden estar muy
separadas en el tiempo: la preparación de las pruebas y la aplicación de las mismas.
La primera está muy ligada a la obtención de requerimientos, por lo que ocurre en
las primeras etapas del proyecto, mientras que la segunda requiere del sistema
completo o al menos una integración, como se denomina a un producto parcial, aún
no liberado, para poder aplicar las pruebas, por lo que ocurre en etapas avanzadas
del proyecto. La situación exacta de estas partes depende del modelo de ciclo de
vida que se haya elegido.

8. PLAN DE PRUEBAS
El plan de pruebas es un documento muy importante dentro del proceso de prueba
del software. En él se explican los propósitos y enfoques de las pruebas, el plan de
trabajo, los procedimientos operacionales, las herramientas necesarias y las
responsabilidades. La extensión y detalle del plan debe adecuarse al proyecto y a las
necesidades de la empresa.

A continuación, se muestra una propuesta mínima de contenido, para proyectos

pequeños y medianos.

 Identificación del plan de pruebas y el sistema al que aplica.

 Elementos a probar: qué módulos, clases, casos de uso se van a probar; cuando
se emplea desarrollo iterativo, deben especificarse las prestaciones
(funcionales), a probar y cuales no se probarán (ya sea que se probaron antes
o que se implementarán después).
 Enfoque: vista general de la estrategia de prueba.
 Criterio de aceptación o rechazo de un caso de prueba: criterio para dar por
bueno o malo un caso de prueba al ser ejecutado.
 Criterio de suspensión: ya sea por tiempo o por cobertura.

7
 PRUEBAS DE SISTEMA Y ACEPTACION

 Productos a entregar: desde el propio plan, los casos y procedimientos de prueba,

los resultados.
 Tareas a realzar para satisfacer el proceso.
 Necesidades ambientales: hardware, software y espacio de trabajo necesarios.
 Responsabilidades: quien es responsable de cada cosa.
 Personal necesario y si requieren entrenamiento.
 Calendario: tiempos e hitos en el proceso.
 Riesgos y contingencias que pueden ocurrir en el proceso de prueba.

9. LISTA DE VERIFICACIONES
Para comenzar el proceso de pruebas del sistema se parte del documento de
requerimientos. En caso que no exista y se deba evaluar un sistema para aceptarlo o
seleccionarlo de entre un conjunto, habrá que preparar dicho documento, aun cuando
sea extemporáneo.

II. PRUEBAS DE ACEPTACIÓN

1. CONCEPTO
Estas pruebas se realizan para que el cliente certifique que el sistema es válido para él.
La planificación detallada de estas pruebas debe haberse realizado en etapas
tempranas del desarrollo, con el objetivo de utilizar los resultados como indicador de
su validez: si se ejecutan las pruebas documentadas a satisfacción del cliente, el
producto se considera correcto y, por tanto, adecuado para su puesta en producción.

Las pruebas de aceptación, son básicamente pruebas funcionales sobre el sistema

completo, y buscan comprobar que se satisfacen los requisitos establecidos. Su
ejecución es facultativa del cliente, y en el caso de que no se realicen explícitamente, se
dan por incluidas dentro de las pruebas de sistema. Es decir, las pruebas de aceptación
son, a menudo, responsabilidad del usuario o del cliente, aunque cualquier persona
involucrada en el negocio puede realizarlas. La ejecución de las pruebas de aceptación
requiere un entorno de pruebas que represente el entorno de producción.

Esta fase o nivel toma como punto de partida la línea base de aceptación del producto
ya instalado en el entorno de certificación. A partir de dicha línea base se acepta el
producto, tomando como referencia la especificación de requisitos y comprobando que
el sistema cubre satisfactoriamente los requisitos del cliente.

8
 PRUEBAS DE SISTEMA Y ACEPTACION

El sistema ha de ser aceptado por el usuario. Por tal motivo, a partir de las
especificaciones estructuradas del sistema, el analista produce un conjunto de casos
de prueba que tendrá que pasar satisfactoriamente. Como las pruebas de
aceptación se pueden desarrollar en paralelo con las actividades de diseño e
implementación, es normal que esta actividad la inicie el analista nada más finalizar
la actividad de “Análisis Estructurado”

2. ESTUDIO DE LA SITUACIÓN ACTUAL EN PRUEBAS DE ACEPTACIÓN

Dentro del tipo de pruebas que tenemos para validar el software, una de las más
importantes son las de aceptación (user’s tests). Son aquellas pruebas que son diseñadas
por el propio equipo de desarrollo en base a los requisitos funcionales especificados en la
fase de análisis para cubrir todo ese espectro, y ejecutadas por el propio usuario final, no
por todos evidentemente, pero sí por una cantidad de usuarios finales significativo que
den validez y conformidad al producto que se les está entregado en base a lo que se
acordó inicialmente.
Dependiendo de la complejidad del sistema a probar, si está o no dividido por módulos,
etc. la realización de dichas pruebas se ejecuta de forma diferente. Si estuviera una
aplicación dividida en módulos, se tratarían esto como subsistemas y estudiando si tienen
o no la suficiente complejidad como para tratarlos de forma diferente, habría que realizar
sesiones de prueba de aceptación diferentes.

3. OBJETIVO DE LA PRUEBAS DE ACEPTACIÓN

Las pruebas de aceptación tienen como objetivo obtener la aceptación final del cliente antes
de la entrega del producto para su paso a producción. Cuando la organización ha realizado
las pruebas de sistema y ha corregido la mayoría de sus defectos, el sistema será entregado
al usuario o al cliente para que dé su aprobación.

El objetivo de las pruebas de aceptación es validar que un sistema cumple con el

funcionamiento esperado y permitir al usuario de dicho sistema que determine su
aceptación, desde el punto de vista de su funcionalidad y rendimiento. Las pruebas de
aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo,
aunque la ejecución y aprobación final corresponden al usuario. La validación del sistema
se consigue mediante la realización de pruebas de caja negra que demuestran la

9
 PRUEBAS DE SISTEMA Y ACEPTACION

conformidad con los requisitos y que se recogen en el plan de pruebas, el cual define las
verificaciones a realizar y los casos de prueba asociados.

4. CICLO DE VIDA

El ciclo de la prueba de aceptación debe considerar al menos los siguientes puntos:

 Diseñar casos de prueba de aceptación basados en los requerimientos que

presenta el cliente.
 Preparar datos de las pruebas de aceptación.
 Validar datos de los casos de prueba de aceptación.
 Definir el procedimiento de la prueba.
 Ejecutar las pruebas de aceptación.
 Comparar los resultados de las pruebas con los casos de prueba iniciales.
 Documentar las pruebas de aceptación.

5. ESTRATEGIAS
En general, las pruebas de aceptación pueden adoptar, entre otras, las siguientes
formas:

5.1. Pruebas de aceptación del usuario

Hay casos en los que el cliente y el usuario final son diferentes y lo que le
parece válido a un usuario final, puede ocurrir que no le parezca válido a otro.
Por este motivo, es fundamental realizar pruebas con los usuarios finales.

5.2. Pruebas operativas

Estas pruebas son llevadas a cabo por los administradores del sistema que se
va a poner en producción. En estas pruebas se incluyen las tareas:

 Copia de seguridad/ restauración.

 Recuperación de desastres.
 Gestión de usuarios.
 Comprobaciones periódicas de vulnerabilidades de seguridad
 Carga de datos y tareas de migración.
 Tareas de mantenimiento.

5.3. Pruebas de aceptación contractual y normativa

Las pruebas de aceptación contractual Toman como base los criterios de

aceptación previstos en un contrato para fabricar un software desarrollado a

10
 PRUEBAS DE SISTEMA Y ACEPTACION

medida. Los criterios de aceptación deberán establecerse en el momento en

que las partes aceptan contraer dicho contrato.

Las pruebas de aceptación normativa toman como base cualquier normativa

de obligado cumplimiento, tales como normativas gubernamentales, legales
o de seguridad.

6.4. Pruebas alfa y beta (o de campo)

Cuando se construye software a medida para un cliente, se lleva a cabo una serie de
pruebas de aceptación para permitir que el cliente valide todos los requisitos. La
mayoría de los desarrolladores de productos de software llevan a cabo un proceso
denominado pruebas alfa y beta para descubrir errores que parezca que sólo el
usuario final puede descubrir.

6.4.1. Pruebas alfa (α).

Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de

forma natural con el desarrollador como observador del usuario y registrando los
errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno
controlado.
Las pruebas α-alfa consisten en invitar al cliente a que pruebe el sistema en el
entorno de desarrollo. Se trabaja en un entorno controlado y el cliente siempre
tiene un experto a mano para ayudarle a usar el sistema. El desarrollador va
registrando los errores detectados y los problemas de uso.

6.4.2. Pruebas beta (β)

Las pruebas β-beta se realizan con posterioridad a las pruebas α-alfa, y se

desarrollan en el entorno del cliente. En este caso, el cliente se queda a solas con
el producto y trata de encontrarle fallos de los que informa al desarrollador. Se
llevan a cabo por los usuarios finales del software en los lugares de trabajo de los
clientes. A diferencia de la prueba alfa, el desarrollador no está presente
normalmente. Así, la prueba beta es una aplicación en vivo del software en un
entorno que no puede ser controlado por el desarrollador. El cliente registra todos
los problemas que encuentra durante la prueba beta e informa a intervalos
regulares al desarrollador.

11
 PRUEBAS DE SISTEMA Y ACEPTACION

6. HERRAMIENTAS
Si bien este tipo de pruebas pueden realizarse con prototipos de la aplicación, diagramas
de secuencia o casos de uso que se muestran al usuario para que valide los requerimientos
definidos, existen algunas herramientas que pueden ser útiles:

6.1. CANOO
Es una herramienta de Software Libre para automatizar las pruebas de aplicaciones
web de una forma muy efectiva.

6.2. CONCORDION

Es un framework Java de Software Libre que permite convertir especificaciones en

texto común sobre requerimientos en pruebas automatizadas.

Las especificaciones (o pruebas de aceptación) se escriben normalmente en archivos

HTML, usando tablas y todos los elementos comunes para darle formato. De esta
manera se logran especificaciones muy fáciles de leer y que todos pueden
comprender (desde analistas de negocio hasta desarrolladores).

6.3. FITNESSE

Es una herramienta colaborativa para el desarrollo de software. Permite a los clientes,

testers, y programadores aprender lo que su software debería hacer, y
automáticamente compara lo que realmente hace. Compara las expectativas de los
clientes a los resultados reales.

6.4. JBEHAVE

Es un framework Java para mejorar la colaboración entre desarrolladores, QA,

analistas de negocio, Dueño del Producto y todos los miembros del equipo a través
de escenarios automatizados y legibles

6.5. SELENIUM

Es una herramienta de Software Libre para pruebas de aplicaciones Web. Las pruebas
de Selenium se ejecutan directamente en un navegador y facilitan las pruebas de
compatibilidad en navegadores, también como pruebas funcionales de aceptación de
aplicaciones Web.

12
 PRUEBAS DE SISTEMA Y ACEPTACION

7. GARANTÍA DE CALIDAD O CONTROL DE CALIDAD CON RESPECTO A

PRUEBAS DE ACEPTACIÓN

Se conoce esta actividad como prueba final o prueba de aceptación. Requiere

como entrada los datos de las pruebas de aceptación y el sistema integrado
producido en la actividad. La prueba la realizara algún miembro o
departamento del usuario, o incluso un departamento independiente de
control de calidad. Interesa señalar que es importante realizar actividades de
control de calidad en cada una de las actividades anteriores de análisis, diseño
e implementación para asegurar que se han realizado con un nivel apropiado
de calidad.

Así se asegura que el analista está desarrollando especificaciones de calidad,

que el diseñador está produciendo diseños de calidad y que el programador
está codificando programas de calidad. La actividad de control de calidad es
simplemente la prueba final de la calidad del sistema. (F. Alonso Amo, Loic
artínez Normand)

La prueba de aceptación comprueba el comportamiento del sistema frente a

las necesidades del cliente, sin embargo, estos pueden haber sido expresado,
los clientes se comprometen, o especificar, las tareas típicas para comprobar
que sus exigencias se han cumplido o que la organización ha identificado estos
para el mercado objetivo para el software..

13
 PRUEBAS DE SISTEMA Y ACEPTACION

III. IMPLEMENTACIÓN DE PRUEBAS DE SISTEMAS Y PRUEBAS

DE ACEPTACIÓN

1. CONCEPTO
Una implementación o implantación es la realización de una aplicación, o la ejecución
de un plan, idea, modelo científico, diseño, especificación, estándar, algoritmo o política.

En ciencias de la computación, una implementación es la realización de una

especificación técnica o algoritmos como un programa, componente software, u otro
sistema de cómputo. Muchas implementaciones son dadas según a una especificación
o un estándar. Por ejemplo, un navegador web respeta (o debe respetar) en su
implementación, las especificaciones recomendadas según el World Wide Web
Consortium, y las herramientas de desarrollo del software contienen implementaciones
de lenguajes de programación.

2. GENERACIÓN DE OBJETIVOS DE PRUEBA A PARTIR DE CASOS DE

USO
El perfil de pruebas de UML define un objetivo de pruebas como un elemento con un
nombre concreto que define qué debe ser probado.

En el contexto de pruebas del sistema a partir de los casos de uso, un objetivo de prueba
puede expresarse como un escenario del caso de uso. Dicho escenario estará
compuesto de una secuencia de pasos, sin alternativa posible, y de un conjunto de
valores de prueba, así como las pre-condiciones y post-condiciones relevantes para
dicho escenario.

Para la generación de los escenarios de prueba, en primer lugar, se construye un

diagrama de actividades a partir de la secuencia principal y secuencias erróneas y
alternativas del caso de uso. En el diagrama de actividades, se estereotipa las acciones
realizadas por el sistema y las acciones realizadas por los actores. Después, se realiza
un análisis de caminos y, cada camino del diagrama de actividades, será un escenario
del caso de uso y, por tanto, un potencial objetivo de pruebas

3. IMPLEMENTACIÓN DE PRUEBAS DE SISTEMA

Una vez obtenidos los objetivos de prueba es posible implementar casos de prueba que
cubran dichos objetivos. A continuación, se describe una arquitectura genérica para
pruebas del sistema a partir de los elementos definidos en el perfil de pruebas de UML.

3.1. Una Arquitectura de prueba de sistema

14
 PRUEBAS DE SISTEMA Y ACEPTACION

La arquitectura para la ejecución y comprobación automática de pruebas del

sistema se muestran en la figura 5. A continuación, se describen brevemente los
elementos de la arquitectura de prueba.

3.1.1. UserInterface:

La clase UserInterface representa la interfaz externa del sistema bajo prueba y

ha sido estereotipada de acuerdo con la definición del perfil de prueba de UML

3.1.2. UserEmulator:

La clase UserEmulator, define el elemento que podrá interactuar con el sistema

utilizando las mismas interfaces que una persona real. Si, por ejemplo, el sistema
a prueba es una aplicación web (como en el caso práctico) la clase UserEmulator
será capaz de interactuar con el navegador web para indicarle la URL qué tiene
que visitar, rellenar formularios, pulsar enlaces, etc. A partir de la interacción de
dicha clase con el sistema, se obtendrán uno o varios resultados (clase
TestResult), por ejemplo, en el caso del sistema web, se obtendrá código HTML

3.1.3. AssertCatalog:

La clase AssertCatalog define la colección de asertos a disposición de los casos

de prueba para determinar si el resultado obtenido del sistema a prueba (clase
TestResult) es correcto o no.

Tanto el UserEmulator como el AssertCatalog se han agrupado en un

clasificador que representa el test harness, dado que estos dos elementos,
suelen ser comunes para todas las pruebas de diversos sistemas y existe gran
variedad de ofertas en el mercado tanto de pago como libres y gratuitas.

3.1.4. TestSuite:

La clase TestSuite, estereotipada como un Test Context del perfil de pruebas

de UML, representa un conjunto de casos de prueba (Test Case en el perfil de
UML).

3.1.5. TestOracle:

Esta clase sirve de contenedor de todas las acciones de validación (expresadas

mediante la ejecución de asertos sobre el resultado obtenido) que
determinarán el veredicto de los casos de prueba del contexto de prueba.

3.1.6. TestDataPool

La clase TestDataPool (estereotipada como Data Pool según el perfil de UML)

contendrá un conjunto de métodos Data Selector para seleccionar los distintos
valores de prueba según las distintas particiones identificadas en las variables
de los casos de uso.

15
 PRUEBAS DE SISTEMA Y ACEPTACION

3.2. Implementación de casos de prueba

Para la implementación de los casos de prueba se van a aplicar los patrones

isolated test y test method. El primer patrón indica que cada caso de prueba debe
ser independiente de los demás. Por ello, como se ha visto anteriormente, cada
objetivo de prueba se codificará como un caso de prueba, ya que los objetivos
de prueba no tienen dependencias entre ellos y cualquier objetivo de prueba
puede verificarse independientemente de los demás. El segundo patrón indica
que cada caso de prueba debe ser implementado como un método.

4. IMPLEMENTACION DE PRUEBAS DE ACEPTACIÓN

4.1 DESCRIPCIÓN

Las pruebas de aceptación se ejecutan luego de culminar la fase de pruebas de sistema,

esta ejecución se realiza en la última etapa de pruebas, la cual evaluará el sistema final
con miras a su presentación frente al cliente. En este plan se especificarán las pruebas
que sean necesarias para verificar si el programa cumple con las especificaciones
formales establecidas por el cliente.

4.2 TÉCNICAS Y PRÁCTICAS

El tipo de prueba a ejecutar en esta etapa son las pruebas funcionales, más conocidas
como pruebas de caja negra. Las pruebas de caja negra permiten detectar
funcionamiento incorrecto o incompleto, errores de interfaz, errores accesos estructuras
de datos externas, problemas de rendimiento, errores de inicio y terminación. Su criterio
se basa en las interfaces y las especificaciones de los módulos.

4.3 ACTIVIDADES DEL PLAN

4.3.1 Diseño de casos de prueba de aceptación

Para las pruebas Alfa descritas se considera que los encargados de apoyar la labor del
usuario mantengan un registro de los eventos que realiza el usuario durante la ejecución
del sistema, mediante la siguiente tabla que detalla la información necesaria para la
realización de la prueba.

16
 PRUEBAS DE SISTEMA Y ACEPTACION

Como la prueba se realiza primordialmente basándose en la interfaz del sistema, se pide

que la captura de los datos se realice considerando el nombre de la funcionalidad que
se está manipulando, en cuanto a los entornos de prueba, se sugiere dar a conocer con
más detalle que elementos se están manipulando. El resultado indicará el estado en que
se encuentra el módulo con defectos, siendo del tipo Urgente, Controlada, Puede
esperar, Vital. Finalmente, las observaciones especifican de mejor forma cómo se
produjo el defecto o falla.

PRUEBAS ALFA
Encargado: Fecha:
Funcionabilidad Entorno de prueba Resultado Prueba Observaciones

FIGURA 7: Prueba Alfa

Además, se solicitará al usuario que finalizado el testeo de prueba complete un

formulario o cuestionario con preguntas relacionadas con su desempeño.

Para las pruebas Beta descritas en el punto 4.2.2 se considera la participación del usuario
frente al sistema, en este caso, el ambiente de prueba no contará con una persona
encargada de guiar al usuario, sino que su entorno de prueba será privado y la ejecución
la estimará el usuario en un ambiente propicio. Se podrá incluir además sugerencias en
cuanto a la interacción y manipulación del sistema.

PRUEBAS ALFA
Usuario:
Fecha:
Prueba Observaciones
realizada

FIGURA 8: Prueba Beta

4.3.2 Verificación de calidad del producto

Se realizará a través de una lista de Chequeo y donde se considerará un cuestionario

para las siguientes características: Corrección, Fiabilidad, Eficiencia, Integridad, Facilidad
de Uso y Facilidad de Mantenimiento.

17
 PRUEBAS DE SISTEMA Y ACEPTACION

CUESTIONARIO
Característica Pregunta Evaluación
1= Inaceptable
2= Bajo el promedio
1. ¿La información que
Fiabilidad actualmente entrega el 3= Promedio
sistema le parece 4= Bueno
fidedigna? 5= Excelente
1= Inaceptable
2= Bajo el promedio
Corrección 3= Promedio
4= Bueno
1. ¿El sistema hace lo que uno
5= Excelente
le pide? Y ¿cómo lo
calificaría?
FIGURA 9: Cuestionario

A modo de resumen, en esta tabla 3 se presenta la Lista de chequeo para las

características de fiabilidad y corrección.

4.3.3 Procedimiento y evaluación de la prueba

4.3.3.1 Criterio de aceptación

El cliente elaborará un ranking para cada Caso de Uso (CU) con las siguientes
prioridades: ALTA, MEDIA o BAJA y en base a ellas se le asignará un mayor número
de pruebas para los CU con un mayor nivel de prioridad.

Las pruebas serán validadas por el usuario, y posteriormente los resultados

obtenidos serán entregados en una tabla de evaluación de las pruebas, la cual debe
poseer al menos un 85% de satisfacción para el Software sea aprobado.

4.3.3.2 Criterio de evaluación

Se realizará una asignación de pesos para cada una de las sub-características de
calidad.

EVALUACIÓN DE PRUEBAS
Participantes: Fecha:
Tipo prueba: Área /Equipo(a realizar la prueba):

Porcentaje de satisfacción obtenido:

Análisis de resultados:

18
 PRUEBAS DE SISTEMA Y ACEPTACION

FIGURA 10: Evaluación de pruebas

4.3.4 Análisis de resultados

Los resultados pueden obtenerse en base a dos criterios:

 Respuestas a las preguntas de las listas de chequeo y la ponderación.

 Dar respuesta a las distintas preguntas de las listas de chequeo.

Las respuestas a las preguntas de las listas de chequeo se pueden dar de forma
directa o mediante la realización de casos de prueba. De realizarse a través de
los casos de prueba, las respuestas dependerán de los resultados en los mismos.

Los casos de prueba serán evaluados por medio de la siguiente escala:

ESCALA DE EVALUACIÓN
Aprobado 5

No aprobado 3
Falla menor
1
Falla Grave
FIGURA 11: Escala de Evaluación

4.3.4.1 Ponderación de Resultados

A partir del procesamiento de las respuestas dadas en las listas de chequeo, se generan
tres tipos de resultados, no excluyentes:

 Resultados de la presencia de las sub-características en

cada etapa del proceso de prueba, según la característica
de calidad a la que corresponde.
Se calcula el promedio aritmético de las respuestas de cada pregunta de la sub-
característica que se está evaluando.

Sobre la base de los promedios anteriores, la presencia de las sub características

tendrán los siguientes valores:

1= La sub-característica no está presente en esta etapa.

2= La sub-característica se presenta de manera muy deficiente.
3= La sub-característica se presenta medianamente.
4= La sub-característica se encuentra presente.
5= La sub-característica se encuentra altamente presente.

19
 PRUEBAS DE SISTEMA Y ACEPTACION

IV. CONCLUSIONES Y RECOMENDACIONES

1. Conclusiones
 Las pruebas de sistema permiten probar, validar, verificar tantos los
requisitos del negocio como la arquitectura del sistema.
 Las pruebas de sistema deben ser realizadas por un equipo de técnicos
especializado en prueba y los requerimientos del sistema deben ser
completos y estar correctamente documentados.
 Las pruebas de sistema nos permiten obtener una visión muy similar a su
comportamiento en producción por ello estas pruebas se deben ejecutar
en un entorno muy similar al de producción para minimizar el riesgo de
encontrar fallos específicos en él.
 Las pruebas de aceptación nos permiten obligar a definir que los
requisitos sean verificables, además de valorar adecuadamente el
esfuerzo asociado a la incorporación de un requisito.
 Los requerimientos y las pruebas de aceptación conducen el proceso de
desarrollo, y sobretodo marcan el cierre de las pruebas, por ende, el
producto aceptado.
2. Recomendaciones
 Para las pruebas de aceptación es recomendable que se cuente con
criterios de aceptación previamente aprobados por el usuario.
 Estas pruebas se deben realizar en el entorno en que se pondrá en
producción el sistema, es decir en el ambiente en donde se incluye al
personal donde hará uso del producto.
 Es indispensable tener presente que se deben validar la documentación
y los procedimientos de uso, por ejemplo, mediante una auditoría.

20