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’