Pruebas de Aceptación del Cliente (página 2)

Partes: 1, 2

2. Fundamentos
teóricos.

Normalmente, un sistema es
sometido a pruebas de
unidad, pruebas de integración, pruebas de sistema, pruebas de
aceptación, etc. Las pruebas de unidad se realizan a
clases o interfases individuales o a un grupo de
estas, y son típicamente ejecutadas por el programador;
este tipo de prueba generalmente cuenta con herramientas
para automatizarlas.

Las pruebas de integración integran componentes y
clases según el orden especificado en el plan de
integración. Las pruebas de sistema ven al sistema como
una "caja negra" y validan que el sistema tenga la funcionalidad
que le usuario final espera. Las pruebas de
aceptación conducidas por el cliente verifican
que el sistema satisface los requerimientos y son similares a las
pruebas de sistema, pues se basan fundamentalmente en pruebas de
funcionalidad.

2.1. Pruebas de aceptación.

Estas pruebas las realiza el cliente. Son
básicamente pruebas funcionales, sobre el sistema
completo, y buscan una cobertura de la especificación de
requisitos y del manual del
usuario. Estas pruebas no se realizan durante el desarrollo,
pues sería impresentable al cliente; sino que se realizan
sobre el producto
terminado e integrado o pudiera ser una versión del
producto o una iteración funcionad pactada previamente con
el cliente.

La experiencia muestra que
aún después del más cuidadoso proceso de
pruebas por parte del desarrollador, quedan una serie de errores
que sólo aparecen cuando el cliente comienza a usarlo. Los
desarrolladores suelen llevar las manos a la cabeza y
expresan:

"Pero, ¿a quién se le
ocurre usar así mi programa?"

Sea como sea, el cliente siempre tiene razón.
Decir que los requisitos no estaban claros, o que el manual es
ambiguo puede salvar la cara; pero ciertamente no deja satisfecho
al cliente. Alegar que el cliente es un inútil es otra
tentación muy fuerte, que conviene reprimir.

Una prueba de aceptación puede ir desde un
informal caso de prueba hasta la ejecución
sistemática de una serie de pruebas bien planificadas. De
hecho, las pruebas de aceptación pueden tener lugar a lo
largo de semanas o meses, descubriendo así errores
latentes o escondidos que pueden ir degradando el funcionamiento
del sistema. Estas pruebas son muy importantes, ya que definen el
paso nuevas fases del proyecto como el
despliegue y mantenimiento.
[1]

Se emplean dos técnicas
para las pruebas de aceptación:

2.1.1. La prueba 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. Las pruebas
alfa se llevan a cabo en un entorno controlado. Para que tengan
validez, se debe primero crear un ambiente con
las mismas condiciones que se encontrarán en las
instalaciones del cliente. Una vez logrado esto, se procede a
realizar las pruebas y a documentar los resultados.
[1]

2.1.1. La prueba beta.

Se lleva a cabo por los usuarios finales del software en
1os lugares de trabajo de 1os
clientes. A
diferencia de la prueba alfa, el desarrollador no esta 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 1os problemas
(reales o imaginarios) que encuentra durante la prueba beta e
informa a intervalos regulares a1 desarrollador.

Como resultado de 1os problemas informados durante la
prueba beta, el desarrollador del software lleva a cabo
modificaciones y así prepara una versión del
producto de software para toda la clase de
clientes. [1]

3. Descripción del proceso de pruebas de
aceptación.

Un proceso no es más que la sucesión de
pasos y decisiones que se siguen para realizar una determinada
actividad o tarea.

El proceso de pruebas de aceptación esta basado
en nuestra universidad en la
presencia de un tercero confiable, en este caso el Laboratorio de
Pruebas y Certificación que esta integrado por el grupo de
calidad de la
universidad, el cual se encarga de diseñar, guiar y
dirigir las pruebas de aceptación. Las pruebas de
aceptación son un servicio que
brinda el laboratorio a los softwares que se
desarrollan.

En cada una de las facultades de nuestra universidad se
ha creado además un grupo de calidad, conformado por
estudiantes de diferentes años y guiados por los miembros
del grupo central de calidad el objetivo de
esto es que estos estudiantes lleven la calidad a cada uno de los
proyectos de
su facultad, de esta forma se realizaran pruebas a los productos
software de cada facultad antes de entregarlo al grupo de calidad
central, y el producto recibirá un mayor numero de
pruebas.

El proceso de pruebas de aceptación en nuestro
laboratorio comienza cuando las facultades le comunican al
Laboratorio de Pruebas y Certificación la propuesta para
realizar las pruebas de aceptación a un determinado
producto, luego el equipo de desarrollo y el equipo de calidad se
reúnen y planifican los cronogramas de entrega y
liberación de cada artefacto, esto será firmado por
ambas partes y se elabora el Plan de pruebas, el cual es el
encargado de guiar las pruebas, en el queda recogido todo lo
referente a las pruebas tanto por parte de los desarrolladores
como por parte de los ingenieros de pruebas, todo lo que se
menciona en el proceso que se comienza a describir aquí
esta incluido en la plan de pruebas. Pues este plan de pruebas es
el que recoge todo lo referente a estas pruebas.

Luego el equipo de desarrollo entrega al equipo de
calidad un expediente, este expediente se crea según la
norma cubana NC ISO/IEC 12119,
este contiene el producto software a probar, el documento de
especificación de casos de uso, el manual de usuario y de
instalación, un glosario de
términos, y en caso de no estar incluidos en la
especificación de casos de uso, un documento que contiene
los requerimientos y a que caso de uso corresponde cada uno de
ellos. También deberán entregar un documento con
los usuarios, permisos, nombres y demás detalles
necesarios que se deban conocer para la instalación del
software y no estén incluidos en los manuales.

El equipo de desarrollo debe garantizar además,
un producto estable en el laboratorio de prueba que el equipo de
calidad ha preparado para las mismas, durante los días que
se vayan a realizar las pruebas, para montar este laboratorio el
equipo de desarrollo deberá entregar al equipo de calidad
con antelación los requerimientos mínimos de
hardware y
software para que la aplicación funcione.

Según las necesidades y características
del software que se este probando se necesitara además un
documento con algunos juegos de
datos que
contiene la base de datos,
con el objetivo de que el ingeniero de pruebas cuente con todo lo
necesario y utilice datos específicos.

Antes de comenzar las pruebas se crea un expediente del
producto, el cual incluye todo lo entregado por los
desarrolladores y se le ira incluyendo todo lo que se genere
durante el proceso de pruebas.

Las primeras pruebas que se realizan serán las
pruebas al manual de instalación, los ingenieros de
pruebas (o los probadores) instalaran un producto que nunca han
visto guiándose solo por el manual de instalación,
si no pueden hacerlo dejara claro que el manual no cuenta con
todo lo necesario o hay algún problema, una vez
instalado el software, se comenzaran las pruebas al manual
de usuario, mediante este los ingenieros de pruebas deben ser
capaces de moverse por una aplicación que no conocen y
comprenderla así como saber hacia donde ir y que
hacer.

Pero esto no es lo único que los ingenieros de
pruebas revisan, además revisan otros detalles como
ortografía, redacción, e incluso a veces aunque algo
este bien redacto pueden sugerirlo de una mejor manera, pues
consideran que así el usuario final lo comprenderá
mejor.

Las próximas pruebas a aplicar son las pruebas
funcionales, las cuales mediante la técnica de caja negra
verifican si el software cumple con los requerimientos definidos
por el usuario. Para esto se diseñan los casos de pruebas,
los mismos se realizan a partir de los casos de uso, de forma tal
que al final del diseño
se tendrá un caso de prueba por cada caso de uso
existente. Para los casos de uso incluidos no se diseñaran
casos de pruebas sino que estos se agregaran en el caso de uso
que los contenga y se probaran cuantas veces aparezcan en el
software. A medida que se diseñan los casos de pruebas se
probara el documento de especificación de caso de uso, se
comprobara que lo que se encuentra en la aplicación
corresponde a lo descrito en el documento así como la
ortografía y la redacción.

Estas pruebas se pueden hacer de forma paralela, se
puede designar un grupo de ingenieros de pruebas para hacer las
pruebas a los manuales, mientras que otro grupo diseña los
casos de pruebas.

Si es un software complejo el cual esta compuesto por
varios módulos que se integraran al final para lograr el
producto completo, se probaran primero los módulos por
separados y luego se diseñara un caso de prueba de
integración para probar el software como un todo, para
esto el equipo de desarrollo deberá entregar con el
expediente del producto un documento donde exponga como los datos
manejados de un modulo afectan a otros. En caso de productos
menos complejos esto no es necesario.

Una vez diseñados los casos de pruebas el equipo
de calidad comienza a aplicar los mismos, en muchas ocasiones a
medida que se diseñan los casos de pruebas el software es
probado casi en su totalidad y se recogen las no conformidades
que aparecen, esto ahorra tiempo,
proporciona una mayor cantidad de pruebas y permite una mayor
detección de errores y defectos.

Además se diseña y aplica un caso de
prueba del sistema, que no es más que un caso de prueba
que sigue un flujo básico, ya que con las pruebas
modulares se puede perder la visión general del producto,
pues probara todos los flujos alternativos. Con el mismo se puede
simular el proceso en vivo como mismo debe ocurrir cuando el
usuario final lo utilice.

Luego de aplicadas las pruebas se obtiene como resultado
de las mismas el documento de no conformidades, en el mismo
están todos los defectos, errores y sugerencias realizadas
al equipo de desarrollo, así como también queda
documentado en el caso de prueba el resultado de todas las
pruebas aplicadas.

Otra técnica que se aplica es la
utilización de listas de chequeo para medir atributos de
las interfaces y de calidad con los que debe contar el software,
estas listas de chequeo se aplican para obtener un resultado
cuantitativo de estos atributos y características, el
contenido de la lista de chequeo puede variar según las
características del producto que se este
probando.

El equipo de calidad entrega estos resultados al equipo
de desarrollo, el cual trabajara en función de
estos para perfeccionar al máximo el software, este
proceso se repetirá cuantas veces sea necesario, y por
esto se establecerá una retroalimentación entre los dos equipos de
trabajo en cuanto a los defectos encontrados, cuando se
entreguen versiones nuevas que solucionen errores
señalados por el equipo de calidad el equipo de desarrollo
deberá entregar un documento adjunto a la nueva
versión, que especifique exactamente que parte se cambio en cada
artefacto, para evitar volver a indicar errores ya
señalados, y aun no corregidos, este documento puede ser
el mismo documento de no conformidades con modificaciones en sus
columnas según se plantea en las "Bases para la
comunicación con un equipo de desarrollo" De esta
forma el quipo de calidad se retroalimenta de las correcciones
realizadas y sirve de guía a los desarrolladoras para el
cumplimiento con los cambios necesario que implican las no
conformidades.

Por las características del proceso antes
descrito se puede decir que el objetivo de utilizar un tercero
confiable en este proceso de pruebas de aceptación es
lograr un producto con una alta calidad y con la menor cantidad
de errores posibles antes de presentarlo al usuario
final.

Una vez logrado esto, se crea el laboratorio de pruebas
donde el usuario final probara el software, ya que como se
había mencionado antes, hay cosas que solo el usuario
final puede detectar. Estas pruebas corresponden a pruebas de
tipo alfa, están guiadas por miembros del equipo de
calidad y contaran con la presencia de un miembro del equipo de
desarrollo, ya que pueden surgir dudas, o el usuario puede querer
saber algo especifico, que solo el desarrollador puede responder,
pues el ingeniero de prueba aunque ha llegado a conocer el
software, no sabe como se hizo el mismo, sino como funciona,
Además pueden estar presentes algunos especialistas
funcionales, estos son personas que pertenecen a la parte del
cliente pero no son el usuario final, conocen bien el negocio se
encargan de contactar a los usuarios finales para las pruebas y
participan también en las mismas, es con ellos que se
definen los días que se dedicaran a las pruebas, los
horarios y cualquier otra cosa que se necesite.

Para esta etapa del proceso de pruebas los ingenieros de
prueba refinan una vez más los casos de pruebas con la
última versión del software, que es el resultado de
todas las pruebas anteriores.

Para probar, el usuario final se guiara por los casos de
pruebas ya refinados, así como necesitara el documento
según las características del software con los
datos que contiene la Base de datos, aplicara el caso de prueba
del sistema y las listas de chequeo.

En un primer encuentro se explicara al usuario el
objetivo y proposito de las pruebas, así como la manera en
que serán realizadas, a medida que avancen las pruebas se
recogerán todos los señalamientos y problemas
detectados, que los miembros del equipo de calidad redactaran en
el "Sumario de Evaluación
de Pruebas", al final de cada día se realiza una
reunión de conclusión del día, donde se
expondrán los resultados del día, así como
cualquier dificultad o inconveniente que haya podido
surgir.

El "Sumario de Evaluación de Pruebas" puede
hacerse después del ultimo día de las pruebas
después de tener todos los señalamientos hechos por
el usuario, pero realmente esto no es recomendable, es mejor que
se vaya conformando según se termina cada día, pues
en ocasiones no se entienden bien los señalamientos
realizados por el usuario o no lo redactaron correctamente, y
así el ingeniero de pruebas puede aclarar cualquier duda
al respecto al siguiente día.

Luego de terminados todos los días previstos para
las pruebas los ingenieros de pruebas realizan las solicitudes de
cambio a partir del "Sumario de Evaluación de Pruebas",
estas solicitudes se entregan a los desarrolladores los cuales
redactaran un documento en que expondrán cuales proceden a
realizarse y cuales no así como la causa de estas
decisiones. También se realizara el sumario de las listas
de chequeo, donde se obtiene un resultado cuantitativo de las
mismas.

Luego se realiza una reunión con los
especialistas funcionales, los ingenieros de pruebas y el
representante del equipo de desarrollo para discutir este
documento, en esta reunión se firma el "Sumario de
Evaluación de Pruebas" como constancia de que todas las
partes están conformes con los señalamientos
realizados y con las solicitudes de cambio, así como
también se firmara el sumario de las listas
de chequeo.

Después de esto los desarrolladores trabajaran
sobre las solicitudes de cambio realizadas hasta una segunda
presentación del software al usuario final y así
este proceso se repetirá las veces que sea necesario con
la diferencia de que ya no se diseñaran nuevos casos de
pruebas sino el equipo de calidad refina los ya realizados y los
vuelve aplicar así como verificara si estas solicitudes
fueron llevadas a cabo y redacta un documento resumen de
estas.

En la próxima presentación al usuario
final el mismo aplicara nuevamente los casos de pruebas, revisara
las solicitudes de cambio para ver si fueron modificadas y
volverá aplicar las listas de chequeo, el resultado de
estas última será comparado con el de las aplicadas
anteriormente.

También para cada solicitud de cambio los
desarrolladores deben incluir que solución fue dada y que
partes de la aplicación fueron afectadas con los cambios
lo que incluye requerimientos y caso de uso, esto se hace en
busca de nuevos errores incluidos.

Si es un software complejo compuesto por diferentes
módulos se aplicara este proceso para cada uno de ellos,
para cuando termine el mismo el equipo de calidad ya habrá
elaborado un caso de prueba de integración y lo aplicara
para probar el software integrado, y se volverá a
presentar esto al usuario final para que aplique este caso de
prueba y haga los señalamientos que considere.

Al terminar el proceso se tendrá el expediente
actualizado con todo lo correspondiente al proceso de pruebas,
así quedara archivado un historial sobre las pruebas
realizadas, este incluirá un informe sobre las
pruebas realizadas, este informe recoge todo lo sucedido en las
diferentes etapas del proceso de pruebas.

Ver anexo # 1.

4. Un ejemplo
práctico.

Las pruebas de aceptación del software Identidad se
estan realizarando siguiendo el proceso antes descrito, aun no
han concluido; en estos momentos los desarrolladores trabajan
sobre los errores detectados, una vez entregado nuevamente el
software se volverá a realizar un ciclo de estas
pruebas.

Los resultados que se muestran en la tabla del anexo #2
son los obtenidos en Venezuela al
realizar las pruebas con el usuario final. Como se puede apreciar
en la segunda revisión del modulo pasaporte solo se
encontraron 19 señalamientos de 82 realizados en la
primera etapa de pruebas, lo que demuestra la utilidad de las
pruebas, el resultado satisfactorio de las mismas así como
la calidad lograda.

5. Propuesta
de automatización del proceso.

Como solución se propone una aplicación
WEB
cleinte-servidor, ya que
proporciona las siguientes ventajas:

Permitirá centralizar los resultados del
proceso de pruebas.
Permitirá a los desarrolladores estar
sincronizados con los resultados de las pruebas.
Agilizará el trabajo
de los ingenieros de pruebas.
Posibilitará llevar un historial por proyecto
de las pruebas realizadas, por el cual se podrá comparar
incluso el estado y
desempeño de las pruebas entre diferentes
proyectos.

La plataforma para desarrollo será WAMP5
(Windows,
Apache, MySQL y
PHP5).

En la versión inicial se realizara la
aplicación Web de forma tal que se recojan los resultados
y las no conformidades obtenidas luego de aplicar las pruebas, se
podrá saber que ingeniero de prueba aplico cada prueba;
los demás ingenieros de pruebas podrán ver los
señalamientos hechos por otros, y los miembros de equipo
de desarrollo también podrán hacerlo, esto no
sustituye los documentos que se
generan, independientemente de esto se realizaran los documentos
que corresponden al proceso, esto puede cambiar en versiones
posteriores, pues se quiere lograr que el sistema genere
automáticamente los documentos de no conformidades, el
sumario de evaluación de pruebas y de listas de chequeo,
así como las solicitudes de cambio.

6. Valor
Práctico

Con la automatización de este proceso se logra la
eficacia de
una forma más eficiente, es decir, se logran realizar las
pruebas, a los softwares producidos en nuestra universidad, con
la mayor calidad posible empleando menor esfuerzo y
tiempo.

7.
Conclusiones

Mediante las revisiones bibliográficas,
entrevistas
a especialistas y análisis de la información se logró:

Definir y describir el proceso a seguir para realizar
las pruebas de aceptación con el cliente en una
versión preliminar.
Definir el flujo de comunicación necesario entre el equipo de
desarrollo y el grupo de calidad para lograr terminar con
éxito
la etapa de pruebas.
Definir la documentación empleada y generada en el
proceso de pruebas de aceptación.

Llevar las pruebas de aceptación fue más
que un reto para el equipo de calidad de la universidad, pues era
la primera vez que se realizaban, el laboratorio de
certificación y pruebas estaba surgiendo y solo
había dado pequeños pasos, era un camino nuevo,
ahora se pueden transmitir experiencias y seguir perfeccionando
el proceso de pruebas con las nuevas experiencias de cada
día, nuestro mayor propósito es que esta investigación ayude a realizar software con
una alta calidad, llevando el proceso de calidad hasta las
facultades y hacia cada uno de los proyectos de la universidad.
Se espera que este trabajo sirva de guía para los
desarrolladores e ingenieros de pruebas en su trabajo.

Agradecimientos

A todas las personas que depositarón su confianza
y me dieron la oportunidad de pasar por la experiencia de aplicar
las primeras pruebas de aceptacion en un software desarrollado en
nuestra universisad.

Referencias

[1] Presman, Roger S. "Ingeniería de
software un enfoque practico" pp. 316 Quinta edición.

[2] Suárez, Pablo y Fontela, Carlos
"Documentación y pruebas", 2003.

[3] ¿Qué es UML?.

[4] Tipos de pruebas.
http://pcarrasco.blogspot.com/2005/06/tipos-de-pruebas.html

[5] Test de
aceptación.
http://www.fing.edu.uy/~dvallesp/Tesis/webActividades/todo/actividades/VyV/testing/tda.htm

[6] Prueba de programas.

http://www.lab.dit.upm.es/~lprg/material/apuntes/
pruebas/testing.htm

Anexo #1:

Proceso ‘Pruebas de
aceptación’