Anda di halaman 1dari 43

Ao del buen Servicio al Ciudadano

UNIVERSIDAD NACIONAL SAN LUIS GONZAGA

FACULTAD DE INGENIERA DE SISTEMAS

PRUEBAS DE SISTEMAS Y
PRUEBAS DE ACEPTACIN

CURSO:
Pruebas de Software
DOCENTE:
Mag. Morales Loaiza Alonso
INTEGRANTES:
Castaeda Gutierrez Jesus
De la Cruz Apari Joan Kimbely
Ramos Gutierrez Juan Angel
Salcedo Vilchez Almamia

ICA PERU
2017
PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

DEDICATORIA
Este presente trabajo est dedicado a
Dios, por brindarnos la dicha de la salud
y bienestar fsico y espiritual. A
nuestros padres, por los innumerables
motivos hayan logrado encaminarnos
por el buen camino y as lograr nuestros
objetivos.

A nuestros ingenieros por su tiempo,


por su apoyo as como por la sabidura
que nos transmiten en el desarrollo de
nuestra formacin profesional.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 1


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

INDICE
INTRODUCCION Pgina 6
PRUEBAS DE SISTEMAS....... Pgina 7
1. CONCEPTO............. Pgina 7
1.1. TIPOS DE PRUEBAS DE SISTEMAS... Pgina 8
1.1.1. PRUEBA DE RECUPERACION. Pgina 8
1.1.2. PRUEBA DE SEGURIDAD.. Pgina 9
1.1.3. PRUEBA DE RESISTENCIA... Pgina 10
1.1.4. PRUEBA DE DESEMPEO Pgina 10
1.1.5. PRUEBA DE COMUNICACIN.. Pgina 11
1.1.6. PRUEBA DE VOLUMEN.. Pgina 11
1.1.7. PRUEBA DE TENSION Pgina 11
1.1.8. PRUEBA DE DISPONIBILIDAD DE DATOS. Pgina 11
1.1.9. PRUEBA DE FACILIDAD DE USO. Pgina 11
1.1.10. PRUEBA DE OPERACIN..... Pgina 12
1.1.11. PRUEBA DE ENTORNO.. Pgina 12
1.1.12. PRUEBA DE ALMACENAMIENTO.... Pgina 12
1.1.13. PRUEBA DE CONFIGURACION Pgina 12
1.1.14. PRUEBA DE INSTALACION... Pgina 12
1.1.15. PRUEBA DE DOCUMENTACION.. Pgina 13
1.2. VISION SISTEMATICA DE LA PRUEBA.. Pgina 13
1.3. VISTA GENARAL DE LA PRUEBA DE SISTEMAS Pgina 13
1.4. PLAN DE PRUEBAS.... Pgina 14

PRUEBAS DE ACEPTACION...... Pgina 15


2. CONCEPTO0 Pgina 15
2.1. ESTUDIO DE LA SITUACION ACTUAL EN PRUEBAS DE ACEPTACION Pgina 16
2.2. OBJETIVOS DE LA PRUEBAS DE ACEPTACION. Pgina 16
2.3. GENERACION DE LAS PRUEBAS DE ACEPTACION.. Pgina 17
2.4. ESTRATEGIAS DE PRUEBAS DE ACEPTACION. Pgina 17
2.4.1. PRUEBAS ALFA Y BETA. Pgina 17
2.5. ENTRADAS, SALIDAS, TAREAS Y ROLES DE PRUEBAS DE
ACEPTACION... Pgina 18
2.6. CRITERIOS DE PRUEBAS DE ACEPTACION... Pgina 19
2.7. HERRAMIENTAS PARA PRUEBAS DE ACEPTACION Pgina 19
2.8. GARANTIA DE CALIDAD O CONTROL DE CALIDAD CON RESPECTO
A PRUEBAS DE ACEPTACION Pgina 20

3. IMPLEMENTACION DE PRUEBAS DE SISTEMAS Y PRUEBAS DE


ACEPTACION...... Pgina 21
3.1. IMPLEMENTACION DE PRUEBAS DE SISTEMAS. Pgina 21
3.1.1. GENERACION DE OBJETIVOS DE PRUEBA A PARTIR DE
CASOS DE USO.. Pgina 21
3.1.2. IMPLEMENTACION DE PRUEBAS DE SISTEMA.. Pgina 22
3.1.3. UN CASO PRACTICO.. Pgina 25

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 2


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

3.2. IMPLEMENTACION DE PRUEBAS DE ACEPTACION. Pgina 30


3.2.1. PRUEBAS DE ACEPTACION AUTOMATICA..... Pgina 31
3.2.2. IMPLEMENTACION DE PRUEBAS DE ACEPTACION.. Pgina 40

4. CONCLUSIONES Y RECOMENDACIONES... Pgina 41


5. BIBLIOGRAFIA. Pgina 42

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 3


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

INDICE DE FIGURAS
FIGURA 1: PRUEBAS DE SISTEMA.. Pgina 7
FIGURA 2: PRUEBA DE RECUPERACION.. Pgina 8
FIGURA 3: PRUEBA DE SEGURIDAD... Pgina 9
FIGURA 4: PRUEBA DE RESISTENCIA Pgina 10
FIGURA 5: FLUJO DE CONTROL DE PRUEBA DE ACEPTACION. Pgina 16
FIGURA 6: ARQUITECTURA DE PRUEBA DE SISTEMA.. Pgina 22
FIGURA 7: EJECUCION DEL CASO DE PRUEBA DEL ESCENARIO PRINCIPAL
CON LA HERRAMIENTA SELENIUN. Pgina 28
FIGURA 8: IMPLEMENTACION DEL CASO DE PRUEBA.. Pgina 29
FIGURA 9: ALTERNATIVAS DE ESPECIFICACION... Pgina 33
FIGURA 10: DESCRIPCION NARRATIVA...................... Pgina 34

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 4


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

INDICE DE TABLAS
TABLA 1: ENTRADAS, SALIDAS, TAREAS Y ROLES DE PRUEBAS DE
ACEPTACION................................................ Pgina 19
TABLA 2: HERRAMIENTAS PARA PRUEBAS DE ACEPTACION. Pgina 20
TABLA 3: COMPORTAMIENTO GENERICO DE UN CASO DE PRUEBA Pgina 23
TABLA 4: CASO DE USO BAJO PRUEBA.. Pgina 25
TABLA 5: REQUISITO DE INFORMACION DE LOS ENLACES.. Pgina 26
TABLA 6: ESCENARIOS DEL CASO DE USO... Pgina 26
TABLA 7: ESCENARIO PRINCIPAL. Pgina 27
TABLA 8: VARIABLES IDENTIFICADAS PARA EL CASO DE USO... Pgina 27
TABLA 9: CATEGORIAS PARA LAS VARIABLES IDENTIFACADAS Pgina 27
TABLA 10: TRADUCCION A CPDIGO EJECUTABLE DE LOS PASOS
REALIZADOS POR EL USUARIO EN EL ESCENARIO PRINCIPAL.. Pgina 29
TABLA 11: TRADUCCION A CODIGO EJECUTABLE DEL TEST ORACLE
PARA EL ESCENARIO PRINCIPAL. Pgina 30

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 5


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

INTRODUCCION
La aplicacin de pruebas de software es actualmente una herramienta importante para
llevar el control de la realizacin de un proyecto de software de calidad y cada vez es
ms rigurosa estas pruebas por el hecho de la gran competitividad creciente existente
en el mercado.

Las pruebas de sistemas conforman uno de los niveles de pruebas de software


conjuntamente con diversas pruebas como pruebas recuperacin, seguridad,
resistencia, desempeo, comunicacin, volumen, tensin, disponibilidad de datos,
facilidad de uso, operacin, entorno, almacenamiento, configuracin, instalacin y
documentacin. Cada cual tiene diversa finalidad y con un objetivo en comn que
demuestre una visin sistemtica para proyecto.

Las pruebas de aceptacin es otro tipo de nivel que se complementa en los niveles de
pruebas de software, estas pruebas son muy fundamentales ya que son las que nos van
a permitir que el producto cumpla con los estndares necesarios y que a la vez satisfaga
a los usuarios de acuerdo a los requerimientos que plantearon desde un inicio.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 6


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

PRUEBAS DE SISTEMAS
1. CONCEPTO
El software se incorpora a otros elementos del sistema (como hardware, personas,
informacin), y se realiza una serie de pruebas de integracin de sistemas y de validacin.
Estas pruebas estn ms all del alcance del proceso de software y no las realizan
nicamente los ingenieros del software. Sin embargo, los pasos durante el diseo y las
pruebas del software mejoran en gran medida la probabilidad de tener xito en la integracin
del software en el sistema mayor. Cualquier pieza de software completo, desarrollado o
adquirido, puede verse como un sistema que debe de probarse, ya sea decidir acerca de su
aceptacin, para analizar defectos globales o para estudiar aspectos especficos de su
comportamiento, tales como seguridad, rendimiento. A este tipo de pruebas donde se
estudia el producto completo se les llama pruebas de sistemas.

Un problema clsico de la prueba de sistema es sealar con el dedo. Esto ocurre cuando
se descubre un error y el desarrollador de cada elemento del sistema culpa a los dems. En
lugar de caer en este absurdo, el ingeniero del software debe de anticiparse a posibles
problemas de la interfaz:

Disear ruta de manejo de errores que prueben toda la informacin proveniente de otros
elementos del sistema.
Aplicar una serie de pruebas que simulen datos incorrectos u otros posibles errores en la
interfaz de software.
Registrar los resultados de la prueba como evidencia en el caso de que se culpe.
Participar en la planeacin y el diseo de las pruebas del sistemas para asegurar que le
software se ha probado adecuadamente.

En realidad, la prueba de sistema abarca una serie de


pruebas diferentes cuyo propsito principal es ejecutar
profundamente el sistema en cmputo. Aunque cada
prueba tiene un propsito diferente, todas trabajan para
verificar que se hayan integrado adecuadamente todos
los elementos del sistema y que realicen las funciones
apropiadas.

FIGURA 1: PRUEBAS DE SISTEMAS

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 7


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

1.1. TIPOS DE PRUEBAS DE SISTEMAS


Prueba de recuperacin.
Prueba de seguridad.
Prueba de resistencia.
Prueba de desempeo.
Pruebas de comunicaciones.
Pruebas de volumen.
Pruebas de tensin.
Pruebas de disponibilidad de datos.
Pruebas de facilidad de uso.
Pruebas de operacin.
Pruebas de entorno.
Pruebas de almacenamiento.
Pruebas de configuracin.
Pruebas de instalacin.
Pruebas de la documentacin.

1.1.1. PRUEBA DE RECUPERACIN


Muchos sistemas de cmputo 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 cada
del sistema, en general. En otros casos una falta del sistema debe de corregir dentro de
un periodo especfico o se sufrir un fuerte dao econmico.

La prueba de recuperacin es una prueba de sistema que obliga al software a fallar de


varias maneras y a verificar que la recuperacin se realice apropiadamente. Si la
recuperacin es automtica (la realiza el propio sistema) debe de evaluarse que sean
correctos la re-inicializacin, los mecanismos
de respaldo del sistema, la recuperacin de
datos y el nuevo arranque. Si la recuperacin
requiere de intervencin humana, se debe
evaluar el tiempo medio de recuperacin
(TMR) para determinar si se encuentra dentro
de los lmites aceptables.

FIGURA 2: PRUEBA DE RECUPERACION

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 8


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

1.1.2. PRUEBA DE SEGURIDAD


Cualquier sistema de cmputo que maneje informacin confidencial o que
desencadenen acciones que daen o beneficien inapropiadamente a los individuos es
un blanco para irrupciones impropias o ilegales. La irrupcin abarca un amplio rango de
actividades:

Hacker que tratan de entrar en los sistemas por juego.


Empleados disgustados que tratan de irrumpir como forma de venganza.
Individuos deshonestos que buscan ganancias personales ilcitas.

La prueba de seguridad comprueba que los mecanismos de proteccin integrados en el


sistema realmente lo protejan de irrupciones inapropiadas.
los sistemas se deben de probarse para la seguridad del sistema para asegurar que es
invulnerable a los ataques frontales, pero tambin a los perpetrados por los flancos o
las retaguardia. Durante la prueba de seguridad, quien la aplica desempea el papel
del individuo que desea entrar en el sistema. Todo vale! Debe de tratar de obtener
contraseas por cualquier medio externo; podra atacar el sistema con software
personalizados, diseados para burlar cualquier defensa que se haya construido; podra
saturar el sistema, negando as el servicio a otros; podra producir errores intencionales
en el sistema para tratar de tener acceso durante la recuperacin: podra revisar datos
sin proteccin, con la idea de encontrar la clave de acceso al sistema.

Si se dan el tiempo y los recursos suficientes, una buena prueba de seguridad terminara
por irrumpir en el sistema. El papel del diseador del sistema es que el costo de la
irrupcin sea mayor que el valor de la informacin que habr de obtenerse.

FIGURA 3: PRUEBA DE SEGURIDAD

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 9


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

1.1.3. PRUEBA DE RESISTENCIA


Los pasos de prueba analizados antes en este trabajo, llevan a una evaluacin completa
de las funciones y el desempeo normalmente del programa. Las pruebas de resistencia
estn diseadas para confrontar los programas en situaciones anormales. En esencia,
la persona que realiza la prueba de resistencia se preguntara.

Hasta dnde 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. Por ejemplo:
Se disea pruebas especiales que generen 10 interrupciones por segundo cuando la
taza de promedio es de una o dos.
Se aumenta la frecuencia de entrada de datos una magnitud que permita como
responder las funciones de entrada.
Se ejecutan casos de pruebas que requieran el mximo de memoria u otros recursos.
Se disea casos de pruebas que causen problemas de administracin de memoria.

Se crean casos de pruebas que produzcan bsquedas excesivas de datos en el disco.

FIGURA 4: PRUEBA DE RESISTENCIA

1.1.4. PRUEBA DE DESEMPEO


La prueba de desempeo est diseada para probar el desempeo del software en
tiempos de ejecucin dentro del contexto de un sistema integrado. La prueba de
desempeo se aplica en todos los pasos del proceso de la prueba. Incluso al nivel de la
unidad. El desempeo de un mdulo individual debe de evaluarse mientras se realizan

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 10


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

las pruebas. Sin embargo, no es sino hasta que se encuentre totalmente integrado todos
los elementos del sistema que es posible asegurar el verdadero desempeo del sistema.

Con frecuencia las pruebas de desempeo se vinculan con pruebas de resistencia y


suelen requerir instruccin de software y hardware. Es decir, a menudo resulta necesario
medir con exactitud la utilizacin de recursos (por ejemplo: los ciclos de procesador).
Mediante instrumentacin externa pueden vigilarse de manera regular los intervalos de
ejecucin, 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 degradacin y posibles fallas del sistema.

1.1.5. PRUEBA DE COMUNICACIN


Determinan que las interfaces entre los componentes del sistema funcionan
adecuadamente, tanto a travs de dispositivos remotos, como locales. Asimismo, se
han de probar las interfaces hombre/mquina.

1.1.6. PRUEBA DE VOLUMEN


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

1.1.7. PRUEBA DE TENSIN


La prueba de tensin es poner al programa a grandes cargas o tensiones. Esto no se
debe confundir con la prueba de volumen; una gran tensin es volumen mximo de
datos, o de actividad, en un tiempo corto. Una analoga sera evaluar a un mecangrafo.
Una prueba de volumen se determinara si el mecangrafo hiciera frente a un bosquejo
de un informe grande; una prueba de tensin se determinara si el mecangrafo puede
mecanografiar a un ndice de 50 palabras por minuto.

1.1.8. PRUEBA DE DISPONIBILIDAD DE DATOS


Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo
fsico como lgico, sin comprometer la integridad de los datos.

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

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 11


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

1.1.10. PRUEBA DE OPERACIN


Consisten en comprobar la correcta implementacin de los procedimientos de
operacin, incluyendo la planificacin y control de trabajos, arranque y Re-arranque del
sistema.

1.1.11. PRUEBA DE ENTORNO


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

1.1.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 tamao
de los archivos temporales. Se disean casos de prueba para demostrar que estos
objetivos de almacenaje no han sido encontrados.

1.1.13. PRUEBA DE CONFIGURACIN


Programas tales como sistemas operativos, sistemas de gerencia de base de datos, y
programas de conmutacin de mensajes soportan una variedad de configuraciones de
hardware, incluyendo varios tipos y nmeros de dispositivos de entrada-salida y lneas
de comunicaciones, o diversos tamaos de memoria. A menudo el nmero 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
configuracin mnima y mxima. Si el programa por s mismo se puede configurar para
omitir componentes, o si puede funcionar en diversas computadoras, cada configuracin
posible de este debe ser probada.

1.1.14. PRUEBA DE INSTALACIN


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

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 12


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

1.1.15. PRUEBA DE DOCUMENTACIN


Las pruebas de sistema tambin se refieren a la exactitud de la documentacin del
usuario. Una manera de lograr esto es utilizar la documentacin para determinar la
representacin de los casos anteriores de prueba del sistema. Esto es, una vez se desea
idear el caso de sobrecarga, se utilizara la documentacin como gua para escribir el
caso de prueba real. Tambin, la documentacin del usuario debe ser el tema de una
inspeccin, comprobndola para saber si hay exactitud y claridad. Cualquiera de los
ejemplos ilustrados en la documentacin se debe probar y hacer parte de los casos y
alimentarlos al programa. Determinan que las interfaces entre los componentes del
sistema funcionan adecuadamente, tanto a travs de dispositivos remotos, como
locales. Asimismo, se han de probar las interfaces hombre/mquina.

1.2. VISIN SISTMICA DE LA PRUEBA


Cuando se deben realizar pruebas, debe mantenerse un enfoque sistmico, es decir
integral, que est detrs de todo desarrollo de software. Al hablar de enfoque sistmico
se indica que:
Todo sistema tiene una serie de objetivos que le dan sentido. Esos objetivos estn
asociados con indicadores de xito que permiten determinar si los objetivos se
cumplen y en qu medida.
Todo sistema tiene una serie de elementos que lo forman y la interaccin 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 proporcionndoles una serie de
entradas y obteniendo del mismo un conjunto de salidas.
Ningn sistema existe en aislamiento; siempre interaccionan con otros sistemas
constituyendo un sistema mayor.

1.3. VISTA GENERAL DE LA PRUEBAS DE SISTEMAS


El proceso de prueba de sistemas tiene dos etapas que pueden estar muy separadas en
el tiempo:
La preparacin de la prueba.-muy ligada a la obtencin de requerimientos, por lo que
ocurre en la primeras etapas del proyecto.
La aplicacin de la prueba.- requiere del sistema completo al menos una integracin,
como se denomina a un producto parcial, aun no liberado, para poder aplicar las
pruebas por lo que ocurre en etapas avanzadas del proyecto.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 13


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

La situacin exacta de estas partes depende del modelo de ciclo de vida que haya
elegido. La etapa de preparacin de la prueba incluye al menos tres actividades:
Preparacin un plan de pruebas
Preparar una lista de verificaciones de los requerimientos
Preparar casos de prueba.

La prueba de sistema tiene varias suposiciones importantes:


Cada unidad que forma el sistema ha sido probado por separado y se han eliminado
sus defectos.
Las interfaces humano-computador (de texto o grfico) han sido probados tambin
por separados.
Se han realizados pruebas de integracin para analizar la interaccin entre partes del
sistemas y se han eliminado los defectos identificados.

El segundo punto es importante, ya que algunas veces se confunden la prueba de


sistemas con la prueba de interfaz. La primera verifica la interaccin de todas las partes,
mientras que la segunda nicamente analiza los elementos de la interfaz y posiblemente
el manejo de eventos asociados. Sin embargo, las herramientas que ayudan a la prueba
de interfaz pueden utilizarse para iniciar las pruebas de sistemas.

1.4. PLAN DE PRUEBAS


El plan de pruebas es un documento muy importante dentro del proceso de prueba del
software. En l se explican los propsitos y enfoques de las pruebas, el plan de trabajo,
los procedimientos operacionales, las herramientas necesarias y las responsabilidades.
La extensin y detalle del plan debe adecuarse al proyecto y a las necesidades de la
empresa, pudiendo usarse como gua el estndar IEEE 829. A continuacin se muestra
una propuesta mnima de contenido, para proyectos pequeos y medianos.
1) Identificacin del plan de pruebas y el sistema al que se aplica.
2) Elementos a probar: qu mdulos, clases, casos de uso se van a probar; cuando se
emplea desarrollo iterativo, deben especificarse las prestaciones (funcionalidades)
aprobar y cules no se probaran.
3) enfoque: vista general de la estrategia de prueba.
4) criterio de aceptacin o rechazo de un caso de prueba: criterio para dar por bueno o
malo un caso de prueba al ser ejecutado.
5) criterio de suspensin: ya sea por tiempo o por cobertura.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 14


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

6) productos a entregar: desde el propio plan, los casos y procedimientos de prueba, los
resultados.
7) tareas a realizar para satisfacer el proceso.
8) necesidades ambientales: hardware, software y espacios de trabajo necesarios.
9) responsabilidades: quin es responsable de cada cosa.
10) personal necesario y si requieren entrenamiento.
11) calendario: tiempo e hitos en el proceso.
12) riesgos y contingencias que pueden ocurrir en el proceso de prueba.

PRUEBAS DE ACEPTACION
2. CONCEPTO
Estas pruebas se realizan para que el cliente certifique que el sistema es vlido para l. La
planificacin 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 satisfaccin del cliente, el producto se considera
correcto y, por tanto, adecuado para su puesta en produccin.

Las pruebas de aceptacin, son bsicamente pruebas funcionales sobre el sistema completo,
y buscan comprobar que se satisfacen los requisitos establecidos. Su ejecucin es facultativa
del cliente, y en el caso de que no se realicen explcitamente, se dan por incluidas dentro de
las pruebas de sistema. Es decir, las pruebas de aceptacin son, a menudo, responsabilidad
del usuario o del cliente, aunque cualquier persona involucrada en el negocio puede
realizarlas. La ejecucin de las pruebas de aceptacin requiere un entorno de pruebas que
represente el entorno de produccin.

Esta fase o nivel toma como punto de partida la lnea base de aceptacin del producto ya
instalado en el entorno de certificacin. A partir de dicha lnea base se acepta el producto,
tomando como referencia la especificacin de requisitos y comprobando que el sistema cubre
satisfactoriamente los requisitos del cliente.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 15


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

FIGURA 5: FLUJO DE CONTROL DE PRUEBAS DE ACEPTACIN

2.1. ESTUDIO DE LA SITUACIN ACTUAL EN PRUEBAS DE


ACEPTACIN
Dentro del tipo de pruebas que tenemos para validar el software, una de las ms
importantes son las de aceptacin (users tests). Son aquellas pruebas que son
diseadas por el propio equipo de desarrollo en base a los requisitos funcionales
especificados en la fase de anlisis 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 mdulos,


etc. la realizacin de dichas pruebas se ejecuta de forma diferente. Si estuviera una
aplicacin dividida en mdulos, se trataran esto como subsistemas y estudiando si
tienen o no la suficiente complejidad como para tratarlos de forma diferente, habra que
realizar sesiones de prueba de aceptacin diferentes.

2.2. OBJETIVO DE LA PRUEBAS DE ACEPTACIN


Las pruebas de aceptacin tienen como objetivo obtener la aceptacin final del cliente
antes de la entrega del producto para su paso a produccin. Cuando la organizacin ha

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 16


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

realizado las pruebas de sistema y ha corregido la mayora de sus defectos, el sistema


ser entregado al usuario o al cliente para que d su aprobacin.

El objetivo de las pruebas de aceptacin es validar que un sistema cumple con el


funcionamiento esperado y permitir al usuario de dicho sistema que determine su
aceptacin, desde el punto de vista de su funcionalidad y rendimiento. Las pruebas de
aceptacin son definidas por el usuario del sistema y preparadas por el equipo de
desarrollo, aunque la ejecucin y aprobacin final corresponden al usuario. La validacin
del sistema se consigue mediante la realizacin de pruebas de caja negra que
demuestran la 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.

Dicho plan est diseado para asegurar que se satisfacen todos los requisitos
funcionales especificados por el usuario teniendo en cuenta tambin los requisitos no
funcionales relacionados con el rendimiento, seguridad de acceso al sistema, a los datos
y procesos, as como a los distintos recursos del sistema.

2.3. GENERACIN DE LAS PRUEBAS DE ACEPTACIN


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 aceptacin se
pueden desarrollar en paralelo con las actividades de diseo e implementacin, es
normal que esta actividad la inicie el analista nada ms finalizar la actividad de Anlisis
Estructurado.

2.4. ESTRATEGIAS DE PRUEBAS DE ACEPTACIN


Si el sistema ha sido desarrollado para el mercado masivo entonces no ser prctico
probarlo para usuarios o clientes individuales, en algunos casos sera imposible. En
estos casos, antes de que el producto se ponga a la venta, es necesaria una
retroalimentacin. A menudo este tipo de sistemas tiene 2 etapas de pruebas de
aceptacin.

2.4.1. PRUEBAS ALFA Y BETA


Cuando se construye software a medida para un cliente, se lleva a cabo una serie de
pruebas de aceptacin para permitir que el cliente valide todos los requisitos. La mayora
de los desarrolladores de productos de software llevan a cabo un proceso denominado
pruebas alfa y beta para descubrir errores que parezca que slo el usuario final puede
descubrir.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 17


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

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.

Pruebas beta ().


Las pruebas -beta se realizan con posterioridad a las prueba -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
aplicacin 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.

2.5. ENTRADAS, SALIDAS, TAREAS Y ROLES DE PRUEBAS DE


ACEPTACIN

Especificacin de Requisitos.
Manuales de Usuario.
Entradas Sistema probado.
Plan de Pruebas.

Preparacin del entorno de pruebas. Se recomienda la existencia de


un entorno de pruebas especfico para la realizacin de este tipo de
pruebas.
Instalacin en el entorno de pruebas.
Identificacin de las pruebas a realizar.
Planificacin de las pruebas. Se establecern las posibles
Tareas dependencias que hubiera entre pruebas y se establecer el orden
o secuencia de ejecucin de las pruebas en base a dichas
dependencias.
Ejecucin de las pruebas.
Obtencin y registro de resultados.
Correccin de fallos y errores detectados.
Reiteracin de la tarea hasta superar todas las pruebas.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 18


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

Elaboracin de un Informe de Pruebas de aceptacin.


Revisin de la correcta ejecucin y resultados de todas las pruebas
planteadas.
Creacin de la lnea base de produccin.
Cierre formal de la actividad.

Resultados de pruebas.
Salidas Producto aceptado
Informe de Pruebas de aceptacin.

Ingeniero de Pruebas.
Roles Jefe de Pruebas.
Jefe de Proyecto (Cierre formal de la actividad).

TABLA 1: ENTRADAS, SALIDAS, TAREAS Y ROLES DE PRUEBAS DE ACEPTACION

2.6. CRITERIOS DE PRUEBAS DE ACEPTACIN


La aceptacin del software se logra mediante una serie de pruebas que demuestren que
cumple con los requerimientos. Un plan de prueba delinea la clase de prueba que se
aplicara y un procedimiento de prueba define los casos de prueba especificas tanto el
plan como el procedimiento se disean para asegurar que satisfacen todos los
requerimientos funcionales, que se alcanzan todos las caractersticas de
comportamiento, que se cumplen con todos los requisitos de desempeo, que la
documentacin es correcta y se cumple tambin con todos los requisitos de facilidades
uso y otros requisitos especificados (portabilidad, compatibilidad, recuperacin de
errores, facilidad de mantenimiento).

2.7. HERRAMIENTAS PARA PRUEBAS DE ACEPTACIN

Herramienta Descripcin
Canoo es una herramienta de Software Libre para
automatizar las pruebas de aplicaciones web de una forma
CANOO muy efectiva.
http://webtest.canoo.com/webtest/manual/WebTestHome.htm
l
Concordion es un framework Java de Software Libre que
permite convertir especificaciones en texto comn sobre
CONCORDION
requerimientos en pruebas automatizadas
http://www.dosideas.com/wiki/Concordion

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 19


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

FitNesse es una herramienta colaborativa para el desarrollo


de software. Permite a los clientes, testers, y programadores
aprender lo que su software debera hacer, automticamente
FITNESSE
compara lo que realmente hace. Compara las expectativas de
los clientes a los resultados reales
http://www.dosideas.com/wiki/FitNesse
JBehave es un framework Java para mejorar la colaboracin
entre desarrolladores, QA, analistas de negocio, Dueo Del
JBEHAVE Producto y todos los miembros del equipo a travs de
escenarios automatizados y legibles.
http://www.dosideas.com/wiki/JBehave
JMeter es un proyecto de Apache Jakarta que puede ser
usado para realizar una Prueba De Carga, para as analizar y
mediar la Performance De Aplicaciones de distinto tipo,
JMETER
aunque con especial foco en Aplicaciones Web
http://jakarta.apache.org/jmeter/
http://www.dosideas.com/wiki/JMeter
Sahi es una herramienta de automatizacin de pruebas para
aplicaciones Web, con la facilidad de grabar y reproducir
scripts. Est desarrollada en Java y JavaScript, la herramienta
SAHI
usa simplemente JavaScript para ejecutar los eventos en el
browser.
http://www.dosideas.com/wiki/Sahi
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
SELENIUM
compatibilidad en navegadores, tambin como pruebas
funcionales de aceptacin de aplicaciones Web.
http://www.dosideas.com/wiki/Selenium
SoapUI es una herramienta de Software Libre grfica, est
basada en Java y sirve para el testeo de Web Service y
SOAPUI
generacin de Cliente De Web Service
http://www.dosideas.com/wiki/SoapUI
Watir es una librera simple de cdigo abierto para la
automatizacin web en los navegadores. Permite escribir
WATIR pruebas que sean fciles de leer y fciles de mantener. Se ha
optimizado para la simplicidad y flexibilidad.
http://watir.com/

TABLA 2: HERRAMIENTAS PARA PRUEBAS DE ACEPTACION

2.8. GARANTA DE CALIDAD O CONTROL DE CALIDAD CON


RESPECTO A PRUEBAS DE ACEPTACIN
Se conoce esta actividad como prueba final o prueba de aceptacin. Requiere como
entrada los datos de las pruebas de aceptacin y el sistema integrado producido en la
actividad. La prueba la realizara algn miembro o departamento del usuario, o incluso
un departamento independiente de control de calidad. Interesa sealar que es importante
realizar actividades de control de calidad en cada una de las actividades anteriores de

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 20


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

anlisis, diseo e implementacin 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 diseador est produciendo diseos 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.

Las pruebas de aceptacin 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 tpicas para comprobar que sus exigencias se
han cumplido o que la organizacin ha identificado estos para el mercado objetivo para
el software. Para esta actividad la prueba puede o no involucrar a los desarrolladores del
sistema.

3. IMPLEMENTACIN DE PRUEBAS DE SISTEMAS Y


PRUEBAS DE ACEPTACIN
3.1. IMPLEMENTACIN DE PRUEBAS SISTEMAS
Una implementacin o implantacin es la realizacin de una aplicacin, o la ejecucin
de un plan, idea, modelo cientfico, diseo, especificacin, estndar, algoritmo o poltica.
En ciencias de la computacin, una implementacin es la realizacin de una
especificacin tcnica o algoritmos como un programa, componente software, u otro
sistema de cmputo. Muchas implementaciones son dadas segn a una especificacin
o un estndar. Por ejemplo, un navegador web respeta (o debe respetar) en su
implementacin, las especificaciones recomendadas segn el World Wide Web
Consortium, y las herramientas de desarrollo del software contienen implementaciones
de lenguajes de programacin.

En este caso se presenta un ejemplo, basado en el perfil de pruebas de UML, para


la implementacin en cdigo ejecutable de objetivos de prueba definidos mediante
escenarios y variables operacionales.

3.1.1. Generacin de objetivos de prueba a partir de casos de uso.


Se resumen trabajos anteriores de los autores para obtener objetivos de prueba, los
cules son el punto de partida para desarrollar pruebas automticas. 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.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 21


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

Para la generacin de los escenarios de prueba, en primer lugar, se construye un


diagrama de actividades a partir de la secuencia principal y secuencias errneas 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. Despus, se realiza
un anlisis de caminos y, cada camino del diagrama de actividades, ser un escenario
del caso de uso y, por tanto, un potencial objetivo de prueba.

3.1.2. Implementacin de pruebas del sistema.


A.UNA ARQUITECTURA DE PRUEBA DEL SISTEMA.
La arquitectura para la ejecucin y comprobacin automtica de pruebas del sistema se
muestran en la figura 6. Esta arquitectura es similar a la arquitectura necesaria para la
automatizacin de otros tipos de pruebas, como las pruebas unitarias. La principal
diferencia estriba en que, en una prueba unitaria, la propia prueba invoca al cdigo en
ejecucin, mientras que una prueba funcional del sistema necesita un mediador (el
elemento UserEmulator) que sepa cmo manipular su interfaz externa.

UserInterface.- La clase UserInterface representa la interfaz externa del sistema bajo


prueba.

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 aplicacin web (como en el caso prctico) 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 interaccin de
dicha clase con el sistema, se obtendrn uno o varios resultados (clase TestResult), por
ejemplo, en el caso del sistema web, se obtendr cdigo HTML. El perfil de pruebas de
UML no define ningn elemento para representar los resultados obtenidos del sistema
a prueba, por lo que se ha modelado con una clase sin estereotipar.

FIGURA 6: ARQUITECTURA DE PRUEBA DE SISTEMA

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 22


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

AssertCatalog.- La clase AssertCatalog define la coleccin de asertos a disposicin 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 prueba de diversos sistemas y existe gran variedad de ofertas en el mercado
tanto de pago como libres y gratuitas.

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). En el perfil de pruebas, todo Test Context tiene un elemento Arbiter y un elemento
Scheduler, sin embargo, ambos elementos no se van a utilizar en esta propuesta, por lo
que han sido omitidos de la figura J1.

TestOracle.- Esta clase sirve de contenedor de todas las acciones de validacin


(expresadas mediante la ejecucin de asertos sobre el resultado obtenido) que
determinarn el veredicto de los casos de prueba del contexto de prueba.

TestDataPool.- La clase TestDataPool (estereotipada como Data Pool segn el perfil


de UML) contendr un conjunto de mtodos Data Selector para seleccionar los distintos
valores de prueba segn las distintas particiones identificadas en las variables de los
casos de uso.

B. IMPLEMENTACIN DE LOS CASOS DE PRUEBAS


Un caso de prueba es una implementacin de un objetivo de prueba. Segn el perfil de
pruebas de UML, un caso de prueba no es un elemento arquitectnico sino la definicin
de un comportamiento dentro de un elemento estereotipado como Test Context.

El comportamiento genrico para un caso de prueba se lista en la tabla 3.

TABLA 3: COMPORTAMIENTO GENRICO DE UN CASO DE PRUEBA

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 23


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

Cada caso de uso tendr asociado un test suite .Dicha suite contendr las pruebas de
todos los escenarios de dicho caso de uso. Como se ha visto en los objetivos de prueba,
en cada uno de los pasos del escenario debe indicarse si es realizado por un actor o por
el sistema a prueba. Esta informacin es muy relevante a la hora de la codificacin de
los mtodos de prueba de la suite.

Todos los pasos realizados por un actor se traducirn en el cdigo del caso de prueba
a una interaccin entre el caso de prueba y el sistema. El test oracle de un caso de
prueba ser el conjunto de ValidationActions, o acciones de validacin, obtenidas
principalmente, a partir de los pasos realizados por el sistema.Se va a aplicar la tcnica
de variables operacionales y de categora-particin para la definicin de los valores de
prueba necesarios. Se han identificado tres tipos distintos de variables operacionales.
Cada uno de los tipos se implementar de manera distinta en los casos de prueba.

El primer tipo lo componen aquellas variables operacionales que indican un suministro


de informacin al sistema por parte de un actor externo.Para cada variable de este tipo
se definir una nueva clase cuyos objetos contendrn los distintos valores de prueba
para dicha variable. Para cada particin del dominio identificada, el elemento
TestDataPool tendr, al menos, una operacin que devuelva un valor de prueba
perteneciente a dicha particin. Un ejemplo de una variable operacional de este tipo se
muestra en el caso prctico.

El segundo tipo lo componen aquellas variables operacionales que indican una


seleccin entre varias opciones que un actor externo tiene disponible. En este caso, no
tiene sentido implementar estas variables como mtodos del TestDataPool. En su lugar,
dicha seleccin se implementar directamente como parte del cdigo que implementa
la interaccin entre el actor y el sistema. Un ejemplo de una variable operacional de este
tipo se muestra en el caso prctico.

El tercer tipo lo componen aquellas variables operacionales que indican un estado del
sistema. Para implementar el mtodo de set up del caso de prueba, se debe escribir el
cdigo necesario para establecer adecuadamente el valor de las variables
operacionales que describen los estados del sistema, o bien comprobar que dichos
valores son los adecuados. De manera anloga, el mtodo tear up debe restaurar dichos
valores a sus estados originales. Adems, el mtodo tear down debe eliminar, si es
procedente, la informacin introducida por el caso de prueba en el sistema durante la

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 24


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

ejecucin del caso de prueba. Varios ejemplos de variables operacionales de este tipo
se muestran en el caso prctico.

3.1.3. UN CASO PRCTICO


En este caso prctico (Departamento de Lenguajes y Sistemas Informticos), en primer
lugar se aplicar lo visto, para obtener un conjunto de objetivos de prueba a partir de
un caso de uso. Despus, se definen las caractersticas del Test harness utilizado
(seccin B). Finalmente, se aplica lo visto en las secciones anteriores para implementar
un caso de prueba a partir de un objetivo de prueba (seccin C). Los artefactos del
sistema bajo prueba se han definido en ingls, ya que el espaol no est soportado por
las herramientas utilizadas.
A) OBJETIVOS DE PRUEBA.
El caso de uso de la tabla 4, describe la introduccin de un nuevo enlace en el sistema.
Como complemento, se muestra tambin el requisito de almacenamiento de informacin
que describe la informacin manejada por cada enlace (tabla 5). Los patrones usados
se describen en la metodologa de elicitacin NDT. A partir del caso de uso, y de manera
automtica, se han generado un conjunto de escenarios los cules sern los objetivos
de prueba de dicho caso de uso. Dado que el caso de uso presenta bucles no acotados,
con un nmero infinito de potenciales repeticiones, criterio de cobertura elegido para
obtener los caminos es el criterio 01, el cual consiste en obtener todos los caminos
posibles para una repeticin de ninguna o una vez de cada uno de los bucles.

Todos los escenarios obtenidos con este criterio y traducidos al espaol se listan en la
tabla 6. Para este caso prctico, seleccionamos el escenario 09, el cual se describe en
detalle en la tabla
7 (dado que el
caso de uso se ha
redactado en
ingls, su
escenario
principal tambin
se muestra en
ingls), para su
implementacin.

TABLA 4. CASO DE USO BAJO PRUEBA

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 25


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

TABLA 5: REQUISITO DE INFORMACIN DE LOS ENLACES

Tambin ha sido posible aplicar el mtodo de categora-particin. Todas las variables


operacionales encontradas automticamente por la herramienta ValueGen se enumeran
en la tabla 8. Las particiones para cada una de dichas variables (tambin encontradas
por la herramienta ValueGen) se enumeran en la tabla 9.

En este caso, no se ha continuado refinando el conjunto de particiones aunque para


algunas variables, como V04, s podran identificarse particiones adicionales. Para la
implementacin del escenario de xito, todas las variables operacionales deben tener
un valor perteneciente a las particiones C02.

TABLA 6: ESCENARIOS DEL CASO DE USO

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 26


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

TABLA 7: ESCENARIO PRINCIPAL

TABLA 8: VARIABLES IDENTIFICADAS PARA EL CASO DE USO

TABLA 9: CATEGORAS PARA LAS VARIABLES IDENTIFICADAS

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 27


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

B) TEST HARNESS.
Tal y cmo se describi en la figura 6, el test harness tiene la misin de simular el
comportamiento del usuario y ofrecer un conjunto de asertos para evaluar el resultado
obtenido.En este caso prctico, al ser el sistema bajo prueba una aplicacin web, es
necesario que el test harness sea capaz de comunicarse con el navegador web y sea
capaz tambin de realizar comprobaciones en el cdigo HTML recibido como respuesta.
Por ellos, hemos elegido la herramienta de cdigo abierto Selenium
(www.openqa.org/selenium) la cul cumple estas caractersticas.

Como se puede ver en la figura 7, Selenium ofrece un interfaz que permite abrir un
navegador web e interactuar con l de la misma manera que un actor humano. Respecto
al catlogo de asertos, al estar basado en la popular herramienta JUnit, Selenium
incorpora el mismo conjunto de asertos que JUnit y, adems, funciones para acceder a
los resultados visualizados en el navegador web.

FIGURA 7: EJECUCIN DEL CASO DE PRUEBA DEL ESCENARIO PRINCIPAL CON


LA HERRAMIENTA SELENIUM

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 28


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

C) IMPLEMENTACIN DE UN CASO DE PRUEBA.


En primer lugar se ha implementado el data pool y los valores de prueba tal y como se
muestra en la figura 8.

A continuacin, se toman todos los pasos ejecutados por el actor humano y se traducen
a cdigo Java para la herramienta Selenium. Dicha traduccin se realiza actualmente a
mano y se muestra en la tabla 10.

FIGURA 8: IMPLEMENTACIN DEL CASO DE PRUEBA

TABLA 10: TRADUCCIN A CDIGO EJECUTABLE DE LOS PASOS REALIZADOS


POR EL USUARIO EN EL ESCENARIO PRINCIPAL

A continuacin, en la tabla 11, se escribir los asertos a partir de los pasos que realiza el
sistema.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 29


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

TABLA 11: TRADUCCIN A CDIGO EJECUTABLE DEL TEST ORACLE PARA EL


ESCENARIO PRINCIPAL

La implementacin del mtodo de set-up consisti en comprobar que todas las variables
operacionales de la tabla 4 tuvieran un valor de la particin C02. Es decir, comprobar
que hay categoras y que no hay ninguna circunstancia que ocasione un error al
recuperar las categoras o insertar el nuevo enlace. La implementacin del mtodo de
tear down, consisti en la restauracin del conjunto original de enlaces almacenado en
el sistema.

3.2. Implementacin de pruebas de aceptacin


Las pruebas de aceptacin slo funcionan con el apoyo de los clientes, o por lo menos
un proxy para el cliente, para ayudar a definir los criterios. Sin el conductor de los criterios
de aceptacin, se hace difcil verificar si usted est construyendo el software correcto. El
cliente, junto con todos los miembros del equipo de desarrollo debe reunirse para definir
el sistema en trminos de una serie de "escenarios" que describen lo que el sistema
debe hacer y cmo debe hacerlo.

Mediante la creacin de pruebas con requisitos claros y criterios de aprobacin, el


software se encuentra una mejor oportunidad de cumplir con las expectativas del cliente.
Sin embargo, esto implica que alguien manualmente verifique que se cumplan los
requisitos y la aplicacin funcione como se esperaba. Aqu es donde las pruebas de
aceptacin automticas entran en lugar de los requisitos en un documento obsoleto, los

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 30


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

requisitos se definen como ejemplos y escenarios, se protegen en control de origen con


los artefactos de implementacin y se pueden ejecutar en cualquier momento para
comprobar si se implementa cualquier requisito y funciona correctamente. Puede tomar
el mismo enfoque para escribir las pruebas, pero en lugar de escribirlos en software de
administracin de casos de pruebas o en una hoja de clculo, escribirlos directamente
en el cdigo.

3.2.1. PRUEBAS DE ACEPTACIN AUTOMTICA


Una de las prcticas ms valiosas para salir del movimiento de Software gil es un
sistema automatizado, previamente probado estilo de desarrollo, a menudo denominado
Test-Driven Development, o TDD. Un principio fundamental de TDD es que la creacin
de pruebas se trata tanto de diseo y el desarrollo de la orientacin, ya que se trata de
la verificacin y la regresin. Es tambin acerca del uso de la prueba para especificar
una unidad de la funcionalidad requerida, y el uso de esa prueba a escribir a
continuacin, slo el cdigo necesario para ofrecer esta funcionalidad. Por lo tanto, el
primer paso en la implementacin de cualquier nueva funcionalidad es para describir
sus expectativas con una prueba.

Muchos desarrolladores y los equipos han tenido gran xito con TDD. Los dems no
tienen, y encontrar que luchan con la gestin del proceso a travs del tiempo, sobre todo
porque el volumen de pruebas empieza a crecer y la flexibilidad de las pruebas se
empieza a degradar. Algunos no son seguro de cmo empezar con TDD, mientras que
otros encuentran TDD fciles de iniciar, slo para ver lo abandonaron como los plazos
cercanos a los retrasos y el telar grande. Por ltimo, muchos desarrolladores
interesados cumplir con la resistencia a la prctica dentro de sus organizaciones, ya sea
porque la palabra "prueba" implica una funcin que pertenece a otro equipo o por la
falsa percepcin de que los resultados de TDD en cdigo extra demasiado y ralentiza
los proyectos.

ENFOQUE TEST-DRIVEN DEVELOPMENT (TDD).


El enfoque Test-Driven Development (TDD) se basa en que las pruebas deben dirigir el
desarrollo del producto software. El TDD se ha aplicado esencialmente en el mbito de
la implementacin, particularmente siguiendo e planteamiento no escribir cdigo hasta
disponer de las pruebas que debe satisfacer dicho cdigo. El TDD ha tenido un fuerte
impulso con las metodologas giles, las cuales lo incorporan entre sus prcticas
esenciales.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 31


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

En productos software industriales, cuando se utilizan prcticas de ingeniera de


requisitos, stas mayoritariamente estn soportadas por lenguaje natural, lo cual
conlleva los ya conocidos inconvenientes relativos a ambigedad. Sin embargo, la
necesidad de validacin puede ms que las ventajas que puede ofrecer una
especificacin ms formal y rigurosa de los requisitos.

El cliente debe poder leer y comprender los requisitos para as poder dar su conformidad
respecto de ellos. Las tcnicas ms populares para especificacin de requisitos se
resumen en Casos de Uso (utilizados en metodologas tradicionales, como RUP) e
Historias de Usuario (fichas de XP o representaciones similares en otras metodologas
giles como Scrum). Si bien los elementos Actor (o tipo de usuario) y Requisitos (Caso
de Uso o Historia de Usuario) pueden visualizarse y manipularse grficamente o en
fichas, la descripcin de cada requisito se elabora esencialmente de forma textual en
lenguaje natural. Para definir los requisitos es clave involucrar al cliente. El
acuerdo/contrato con el cliente y la planificacin del desarrollo del producto deberan
estar basados en los requisitos que se pretenden incorporar en el producto. Los
requisitos son el objetivo a conseguir, es decir, es lo que espera el cliente que el
producto software satisfaga.

Nuestra propuesta se denomina Test-Driven Requirements Engineering (TDRE) por


referirnos a TDD pero en el mbito de los requisitos y la planificacin. TDRE integra los
artefactos, actividades y roles, asociados a la especificacin y validacin de los
Requisitos y de las Pruebas de Aceptacin. El concepto de Requisitos se convierte en
un contenedor de Pruebas de Aceptacin, y son stas las que adquieren protagonismo
como especificacin de cada requisito. Una de las ocho buenas caractersticas que
recomienda la IEEE 830 para una especificacin de requisitos se refiere a que cada
requisito debe ser Verificable. En nuestra propuesta los requisitos son verificables pues
estn especificados como Pruebas de Aceptacin.

TDRE
Para comprender cmo los requisitos pueden ser especificados mediante Pruebas de
Aceptacin comenzaremos con un ejemplo. Consideremos el requisito Retirar dinero
en el contexto de un cajero automtico. Una tpica especificacin narrativa podra ser la
siguiente:
El cliente debe poder retirar dinero del cajero en cantidades seleccionables. Siempre
recibe un comprobante, a menos que el cajero se quede sin papel. Cuando se trata de

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 32


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

un cliente preferencial puede retirar ms dinero del que tiene en su cuenta, pero se le
debe advertir que se le cobrarn intereses. El cliente debera poder cancelar en
cualquier momento antes de confirmar el retiro de dinero. Las cantidades deberan poder
servirse con los billetes que en ese momento tenga el cajero y no se deberan aceptar
otros montos. Sera conveniente avisar cuando el cajero est realizando operaciones
internas mostrando un mensaje: El dinero retirado de la cuenta debe poder
comprobarse en los registros de movimientos de la cuenta.

FIGURA 9: ALTERNATIVAS DE ESPECIFICACIN

La Figura 9 ilustra algunas alternativas de especificacin para este requisito (incluyendo


la anterior descripcin narrativa como opcin por defecto). Los iconos reflejan la
conveniencia de cada alternativa de especificacin. Elaborar un Diagrama de
Secuencia para definir cada escenario de ejecucin del requisito puede parecer
interesante, sin embargo, en general no resulta apropiado por la gran cantidad de
diagramas generados. Resulta ms interesante la identificacin de los escenarios que
la ilustracin de cada uno de ellos en un diagrama.

La descripcin narrativa no es descartable, al menos para dar una breve definicin del
requisito centrndose en definir los conceptos involucrados (con la idea de un glosario
o de un sencillo Modelo de Dominio). Un Modelo de Casos de Uso no es mala idea,
especialmente para organizar y visualizar los requisitos de un sistema nuevo. Sin
embargo, un Modelo de Casos de Uso no es apropiado para ilustrar la estructura de
requisitos detallada de un producto software en situaciones de mantenimiento a ms
largo plazo, ya que un producto software de tamao medio puede tener miles de

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 33


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

requisitos. La visualizacin y gestin de gran cantidad de requisitos necesita de


mecanismos ms apropiados.
Los bocetos (visualizaciones muy preliminares) de la Interfaz de Usuario (IU) son
siempre bienvenidos pues son una herramienta efectiva de comunicacin y validacin
con el cliente, el cual puede hacerse una idea del producto. En este contexto de
requisitos no debe pretenderse realizar el diseo final de las IUs sino ms bien paneles
con cierto mbito de datos, sin profundizar en tipos de controles de interfaz o cuestiones
de esttica de formularios/pginas. Las plantillas son una de las alternativas de
especificacin ms usadas para Casos de Uso. Las plantillas son elegantes y
proporcionan una sensacin de orden en la especificacin. Sin embargo, en general
resultan contraproducentes ya que tienden a dar un tratamiento uniforme en cuanto al
nivel de detalle para todos los requisitos.

En aquellos muy simples se tiende a incluir cosas obvias o irrelevantes slo para poder
cubrir todos los apartados de la plantilla. Cuando un requisito incluye varios (o muchos)
escenarios, el intento por sintetizar todos los escenarios en una plantilla (que slo ofrece
pasos y excepciones) lleva normalmente a especificaciones enrevesadas.

FIGURA 10: DESCRIPCIN NARRATIVA

Nuestro enfoque TDRE apuesta por especificar los requisitos usando los elementos que
se muestran en la Figura 10: una breve descripcin narrativa que establece los
conceptos y motivacin del requisito, bocetos de la IU (si procede) y una lista de Pruebas
de Aceptacin (PAs). Estas PAs se refinarn desde simples frases que dan nombre a
los escenarios, hasta pruebas diseadas, listas para ser aplicadas o para automatizarse
y aplicarse en regresin. As, los requisitos actan como contenedores para la Pas.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 34


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

Dependiendo del requisito, podra ser til utilizar otras formas de especificacin con
carcter complementario. Por ejemplo un Diagrama de Actividad si el comportamiento
asociado al requisito es de carcter algortmico o un Diagrama de Estados si el
comportamiento incluye habilitacin o deshabilitacin de acciones de acuerdo con el
estado del sistema. La premisa esencial es pragmatismo respecto de la especificacin,
con lo cual no se descarta el uso combinado de alternativas de especificacin, pero el
criterio primordial debe ser el rentabilizar el esfuerzo en especificacin y facilitar el
mantenimiento de dicha especificacin. Por otra parte, desde el punto de vista de
esfuerzo de mantenimiento, especialmente en cuanto a consistencia, es importante no
abusar de solapes o duplicaciones de especificaciones en diferentes medios de
representacin.

Las miles de PAs que fcilmente puede llegar a tener un producto software deben
organizarse adecuadamente para poder ser gestionadas de forma eficiente. Un grafo
dirigido es una representacin adecuada para realizar un refinamiento por niveles. Dicho
grafo permite tanto la visualizacin de relaciones de descomposicin como de
dependencia entre requisitos. As, cada nodo es un requisito funcional o no funcional.
Los arcos entre nodos establecen relaciones padres-hijos (mediante las cuales se hace
una descomposicin de los requisitos) o relaciones de dependencia del tipo nodos que
afectan nodos (estas relaciones son clave para realizar anlisis de impacto).

Las PAs tendrn diferentes estados segn el refinamiento de su especificacin, de


menor a mayor detalle dichos estados son: identificacin (un nombre para la PA),
definicin (establecimiento de condiciones, pasos de ejecucin y resultado esperado),
diseo (instanciacin con datos especficos) y ejecucin en el producto (incluyendo el
caso de ejecucin en regresin, sea sta automatizada o manual). En el resto del
artculo nos centraremos en la identificacin y definicin de la PAs, lo cual est ms
asociado al marco de trabajo del analista. El diseo y ejecucin de la PAs es
responsabilidad del tester.

As, en el ejemplo anterior, el requisito Retirar dinero podra ser un nodo de la


estructura de requisitos. Los nombres que identifican sus PAs podran ser:
Reintegro usando cantidades predefinidas habilitadas.
Reintegro con cantidad introducida por cliente.
Reintegro saldo < cantidad.
Cancelacin de operacin.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 35


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

No disponibilidad de billetes.
No disponibilidad de papel para recibo.
Reintegro saldo < cantidad con cliente preferencial.
Excedido tiempo de comunicacin con sistema central.
Aviso de operaciones internas del cajero.
Excedido tiempo de espera para introduccin de accin.

Una PA tiene como propsito demostrar al cliente el cumplimiento parcial o total de un


requisito del software. Las caractersticas de una PA son:
Una PA describe un escenario (secuencia de pasos) de ejecucin o un uso del
sistema desde la perspectiva del cliente. Las PAs cubren desde escenarios
tpicos/frecuentes hasta los ms excepcionales.
Puede estar asociada a un requisito funcional o requisito no funcional. Un requisito
tiene una o ms PAs asociadas.
Una PA puede tener infinitas instanciaciones (ejecuciones con valores concretos).

La definicin de una PA se separa en cuatro apartados: Condicin, Pasos, Resultado


Esperado y Observaciones:
Condicin. Es opcional, y se utiliza para establecer condiciones previas antes de
aplicar los pasos de la prueba. Normalmente se refieren al estado de la BD antes de
ejecutar la prueba y/o la navegacin necesaria en la IU para localizarse en el punto
adecuado para realizar la prueba (cuando no sea obvio)
Pasos. Son las acciones de interaccin del actor con el sistema. Cuando son varias
acciones, stas pueden ponerse en una lista numerada. Deben ser simples, del estilo
seleccionar, introducir..., evitando hacer referencia explcita a controles de interfaz
o cualquier tecnicismo que dificulte su validacin con el usuario.
Resultado esperado. Es el efecto de las acciones de interaccin del actor. Cada
accin puede provocar uno o ms resultados. Es importante que cuando se trate de
mensajes al usuario se incluya el texto como parte del resultado esperado, as el
programador dispone de dicha informacin ya validada con el cliente.
Observaciones. Es un apartado opcional, son recomendaciones que el analista
estima conveniente hacerle al tester y/o programador.

Las condiciones y/o resultados esperados pueden establecerse en el mbito del


requisito contenedor de la PA o de otros requisitos. Esto, como indicaremos ms
adelante, permitir establecer relaciones de dependencia entre requisitos.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 36


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

A continuacin se presenta como ejemplo la definicin de la PA Reintegro saldo <


cantidad.
1. CONDICIN
Debe existir un cliente normal (esta caracterstica se establece en el apartado datos
bsicos del cliente).
2. PASOS
Intentar reintegro con cliente normal y con cantidad solicitada mayor al saldo.
Resultado esperado.
Se muestra el mensaje La cantidad solicitada supera su saldo actual, vuelva a
introducir la cantidad y se retorna a la ventana para introducir la cantidad.

Pruebas de aceptacin ayudar a validar que se est construyendo la aplicacin que


desea el cliente, mientras que la automatizacin de estos escenarios le permite verificar
constantemente la aplicacin en todo el proceso de desarrollo y los utilizan como parte
de su suite de pruebas de regresin para asegurar que los futuros cambios no violan los
requerimientos actuales.

Sin embargo, tener un cliente implicado con escritura de pruebas, especialmente


pruebas automticas, presenta un nmero de posibles problemas. Los clientes, en
general, no son tcnicos y tienden a alejarse del propio desarrollo de software. El cliente
puede proporcionar los datos y ejemplos, mientras que los probadores o los
desarrolladores rpidamente pueden codificar los escenarios y especificacin
ejecutable.

EJEMPLO:
LA HISTORIA
En el desarrollo de un sistema de clculo de precios con el objetivo de utilizar las
pruebas de aceptacin, la primera etapa es tener a todos en una sala para definir la
historia. Los clientes definen lo que quieren con el estmulo de los miembros tcnicos
del equipo. Con BDD, que desea utilizar un formato establecido para la definicin de las
historias con el fin de apoyar un lenguaje coherente entre los miembros del equipo, y en
concreto lo que se requiere por parte del cliente. Teniendo en cuenta el siguiente
formato, se rellena los datos con la ayuda del cliente:

Como [el rol] quiero [caracterstica] para que [el resultado]

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 37


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

Un error inmediato es a menudo empezar a incluir detalles de la implementacin de la


historia. Por ejemplo:
Como administrador, quiero que los precios que se muestran en una vista de cuadrcula
en default.aspx, para que yo pueda darles el costo.

La historia debe describir el problema slo en trminos de negocio especficas y


prescindir de los detalles tcnicos. Un ejemplo mejor podra ser esta:
Como administrador de ventas, quiero que los precios sean identificados por un cliente
para que pueda proporcionarles el costo.

Lamentablemente, mientras se sigue el formato, que ofrece una informacin muy floja,
y no un punto de partida para la puesta en prctica. Un ejemplo an mejor sera:
Como administrador de ventas, quiero ser capaz de ver los precios del producto X, para
que pueda ofrecer a los clientes con un costo exacto basado en sus necesidades.

Esta historia nos ofrece ms detalles y ms de contexto sobre lo que el cliente est
esperando a suceder y lo que quieren en realidad. Como resultado, es mucho ms til
para nosotros en la aplicacin del sistema. Un hecho importante a recordar cuando se
escriben las historias y caractersticas es de mantenerlos lo ms centrado posible. Que
har que sea mucho ms fcil crear los escenarios, escribir las pruebas, y aplicar el
cdigo final.

Escenarios
Incluso con una historia, usted todava necesita ms informacin sobre lo que estn
esperando a suceder. Los escenarios son muy tiles para esto. Un escenario se limita
a establecer que, dado un determinado contexto, si algo sucede, entonces la salida debe
ser esto. El objetivo es ofrecer un ejemplo ms concreto de cmo la implementacin de
la historia debe comportarse en diferentes situaciones. Este se comunica con las
expectativas del equipo y proporciona los pasos para su verificacin.

La sintaxis recomienda el uso que se conoce como dado, Cundo, entonces (GWT)
sintaxis, promovido por Dan North:
Dado/ Teniendo en cuenta [el contexto], cuando [algo que ocurre], entonces [el
resultado].

Un escenario de ejemplo podra ser algo como esto:

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 38


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

Escenario: Licencia de usuario nico para el producto X, sin apoyo

Teniendo en cuenta el producto X, cuando el usuario solicita licencia de usuario nico,


y esto no incluye el apoyo, entonces el precio debera ser de $ 250.El uso de la "Y" se
puede utilizar para conectar mltiples contextos o los resultados que le permite dar ms
sentido a la situacin y proporcionar ms informacin acerca de lo que est sucediendo.
Idealmente, debe haber tantos escenarios como sea posible para resolver cualquier
ambigedad, servir como especificacin ejecutable, y proporcionar informacin
suficiente para comenzar el trabajo inicial.

LAS PRUEBAS DE ACEPTACIN DE LA INTERFAZ DE USUARIO


En los ejemplos, las pruebas de aceptacin se centr en la lgica de negocio y los
objetos de dominio con el fin de comprobar si la lgica trabajado con xito. Pero, qu
acerca de cmo el usuario interacta con la aplicacin? Estas pruebas de aceptacin
deben estar all para verificar la lgica es correcta el punto de vista del usuario-y el punto
de vista del usuario es la interfaz de usuario. Personalmente, creo que las pruebas de
aceptacin deben centrarse en la lgica de la aplicacin y las secciones importantes del
cdigo que decidir qu hacer. Si la aplicacin tiene un buen desacoplamiento, y una
buena separacin de la lgica del cdigo de la interfaz de usuario, esto debera hacer
las pruebas ms fciles de implementar. Si est probando en este nivel, las pruebas no
sufrirn cambios en la interfaz de usuario.

Mientras que las pruebas deben centrarse exclusivamente en la lgica, esto no significa
que usted no debera tener ninguna prueba de aceptacin en todo el interfaz de usuario.
Me gusta tener un conjunto de pruebas de humo que se dirigen a la base "camino feliz"
de la interfaz de usuario. Se centran en las partes de la aplicacin que los usuarios son
ms propensos a utilizar con el fin de obtener el mximo valor de la menor cantidad de
pruebas. Si se intenta cubrir todos los posibles caminos y usos de la interfaz de usuario,
y si los cambios de interfaz de usuario (por ejemplo, como opciones de pasar a un
dilogo a otro), entonces usted tendra que cambiar todas las pruebas.

Por ejemplo, si se prueba la interfaz de usuario para un sitio de comercio electrnico,


el camino sera feliz para seleccionar un artculo, incorporarlo a su carrito de compras,
echa un vistazo, y ver la confirmacin de compra. Si este escenario falla, usted
realmente quieren saber lo ms pronto posible. Para ciertas aplicaciones, dependiendo
de la complejidad y el tiempo de vida, es posible que desee tener ms pruebas de

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 39


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

aceptacin que se ejecutan en la interfaz de usuario para asegurarse de que tienen ms


confianza en la capa de interfaz de usuario. Con xito pruebas de la interfaz de usuario
es un tema complejo, sin embargo, y no lo hago tiene el espacio para cubrirla aqu.

3.2.2. IMPLEMENTACIN DE PRUEBAS DE ACEPTACIN


Una vez que tenga la historia y los escenarios en un formato claro y comprensible, el
siguiente paso es automatizar la historia y los escenarios. Esto les permite ser ejecutado
durante el desarrollo para seguir los progresos y detectar los errores de regresin.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 40


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

4. CONCLUSIONES Y RECOMENDACIONES
Las pruebas de aceptacin son iterativas donde se pueden aplicar un conjunto de
metodologa como el programacin extrema (XP), el scrum y RUP (casos de usos)
estn definidas como pruebas de Caja negra por la que que el ms importante de los
actores que estas pruebas sean exitosas es el cliente es importante determinar las
historias y escenarios en donde se van a especificar determinar los requisitos para
que el cliente pueda validar si est conforme a lo especificado.

Por otra parte tenemos las pruebas de sistemas estas son las encargadas de evaluar
el funcionamiento a lo largo del proceso para detectar los errores que se puedan
producir para ello es necesario hacer una estrategia con los testing y separar el
desarrollo del cdigo con el desarrollo de la interfaz as se hace mejor una
implementacin de prueba de sistemas.

La implementacin de estas dos pruebas de software se debe hacer con exmenes


riguroso y que cumplan con determinados estndares y con la coordinacin de los
stakeholder que estn implicados en la elaboracin del sistema.

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 41


PRUEBAS DE SISTEMAS Y PRUEBAS DE ACEPTACIN

5. BIBLIOGRAFIA
1. Isabel Ramos Romn, Jos Javier Dolado Cosn. Tcnicas Cuantitativas para la
Gestin en la Ingeniera del Software. Primera Edicion ed. Tuya , Ramos Romn I,
Dolado Cosn JJ, editors. Espaa: Netbiblo, 2007; 2007.

2. INTECO. Instituto Nacional de Tecnologias de Comunicacion. [Online].; 2009 [cited


2012 [Plan Avanza 2 - Ministerio de Industria, Turismo y Comercio de Espaa].
Available from:
www.inteco.es/file/XaXZyrAaEYfaXKiMJlkT_g.

3. F. Alonso Amo, Loic Martnez Normand. Introduccin a la Ingeniera del software.


Primera edicion ed. Barbero Ruiz J, editor. Espaa: Delta Publicaciones, 2005.

4. IEEE Computer Society. Computer. [Online].; 2004 [cited 2012. Available from:
http://www.computer.org/portal/web/swebok/html/contentsch5#ch5.

5. Asociacion de tecnicos de informatica. Pruebas de Aceptacin en Sistemas


Navegables. REICIS Revista Espaola de Innovacin, Calidad. 2010 Noviembre; vol.
6(nm. 3): p. pp. 47-55.

6. ALEGSA. ALEGSA - DICCIONARIO DE INFORMTICA. [Online].; 2012. Available


from: http://www.alegsa.com.ar/Dic/implementacion.php.

7. ingsoft. ingsoft-ETAPA DE PRUEBAS. [Online].; 2007. Available


from:
http://ingpau.blogspot.com/2007/09/etapa-de-pruebas.html.

8. Departamento de Lenguajes y Sistemas Informticos. ITESCAM. [Online].


Available from:
http://www.itescam.edu.mx/principal/sylabus/fpdb/recursos/r43876.PDF.

9.Satrom B. MSDN Magazine. [Online].; 2010. Available from:


http://msdn.microsoft.com/es-es/magazine/gg490346.aspx.

10. Francisco Surez;Patricio Letelier. TUNE-UP. [Online]. Available from:


http://tuneup.dsic.upv.es/LinkClick.aspx?fileticket=Dshzxx-2qDY%3D&tabid=40

CASTAEDA, DE LA CRUZ, RAMOS Y SALCEDO 42

Anda mungkin juga menyukai