Revista Cubana de Ciencias Informáticas

ISSN: 1994-1536

rcci@uci.cu

Universidad de las Ciencias Informáticas

Cuba

Fernández Pérez, Yamilis; Cué Delgado, Rosalía Lucia; Cruz Aguila, Claribel Lucy;

Gonzalez Jorrín, Michael; Acosta Molina, Dialexis; Hernández Aguilar, Violena

Pruebas de aceptación para un software con la presencia de una entidad certificadora de

la calidad

Revista Cubana de Ciencias Informáticas, vol. 1, núm. 3, 2007, pp. 84-93

Universidad de las Ciencias Informáticas

Ciudad de la Habana, Cuba

Disponible en: http://www.redalyc.org/articulo.oa?id=378343633008

Cómo citar el artículo

Número completo

Más información del artículo

Página de la revista en redalyc.org

Sistema de Información Científica

Red de Revistas Científicas de América Latina, el Caribe, España y Portugal

Proyecto académico sin fines de lucro, desarrollado bajo la iniciativa de acceso abierto

Pruebas de aceptaci6n para un software con la presenciade una entidad certificadora de la calidadTesting of the client's acceptance with the participation of acompany guaranteeing the qualityYamilis Fernandez Prezl*, Rosalia Lucia Cue Delgado2, Claribel Lucy CruzAguila2, Michael Gonzlez Jorrfn3, Dialexis Acosta Molina3 yViolena Hernandez Aguilar3lDepartamento de Ingenieria y Gesti6n de Software, Universidad de las Ciencias Informtica (UCI),Carretera a San Antonio de los Baos, km 2 1/2, Boyeros, Ciudad de La Habana, Cuba.2, Softel Carretera a San Antonio de los Baos km 2 1/2, Boyeros, Ciudad de La Habana, Cuba.3 Direcci6n de Calidad, Universidad de las Ciencias Informaticas (UCI), Carretera a San Antonio delos Baos, km 2 1/2, Boyeros, Ciudad de La Habana, Cuba

*Autor para la correspondencia: yamilisf@uci.cu

REV\STA CUBANA DE CIENC\AS INFORMAT\CAS VOL.1 No.3 AGOSTO 2007 p. 84-95

_______________________________________________

En este articulo se define un flujo de trabajo de pruebas deaceptaci6n del cliente con la participaci6n de un terceroconfiable, una empresa certificadora de calidad. En el Sedetallan: quienes participan, qu hacen, cuando y c6modeben hacerlo; asi como, Que artefactos se generan. Esde destacar la participaci6n a este nivel de los clientes, losusuarios finales, los desarrolladores y la empresa terceragarantizando la calidad y el buen desarrollo del proceso.

Palabras clave: Calidad de software, Proceso de desarrollode software, Pruebas de Aceptaci6n de software, Pruebasde Software.

This paper defines a working flow of clients acceptance testswith the participation of a reliable third part: a company thatcertificates the quality of software. The people involved, theiractions and when and how those actions are performed aswell as the artefacts generated are detailed in this article. Itis necessary to highlight the clients involvement, the endusers, the developers and the company guaranteeing thequality and the right development of the process are veryimportant.

Key words: Acceptance Testing, Quality of Software, Testing,Software Development Process.

"No irnporta lo bueno que sea nuestro c6digo: siemprecometeremos errores . . . . " Es una frase muy conocida enel mundo del software. Tomar medidas, utilizar mtodos ytcnicas para prevenir esos errores es realmente necesariopero, aun asi, algunos persisten y de ahi la importancia derealizar un flujo de trabajo de prueba durante el ciclo de Vidadel software (Prado, 2006).

Las pruebas del software son el proceso de ejecuci6n deun programa bajo condiciones controladas, evaluando yregistrando los resultados con la intenci6n de descubrirun error, el objetivo fundamental es disehar pruebas quesistematicamente saquen a la luz diferentes clases de erroreshaciendolo con la menor cantidad de tiempo y esfuerzos(Pressman, 2002). Las tcnicas y herramientas para encontrarproblemas en un programa son extensamente variadas.

Los principales aspectos a ser evaluados en un producto software son la Fiabilidad(resistente a fallos) la Funcionalidad (hace lo que debe) y el Rendimiento (Ileva acabo su trabajo de manera efectiva). Las pruebas pueden hacerse a diferentes nivelesdependiendo del objetivo de los mismos: pruebas de unidad (se prueban las unidadesminimas por separado, y normalmente se hacen durante la implementaci6n misma), deintegraci6n (varias unidades juntas), de sistema (sobre la aplicaci6n o sistema completo) yde aceptaci6n (realizado sobre el sistema global por las usuarios o terceros) (RUP, 2003).Cada Una de ellas se reafizan en determinados momentos del ciclo de Vida def software,la Tabla 1 las resume.

Tabla 1 Niveles de pruebas.

Tipos de Pruebas Descripci6n_________________________________________________________

Unitarias

lntegraci6n

Sistemalmplantaci6n

Su objetivo es probar el comportamiento de cada uno de lascomponentes de forma independiente. Este tipo de prueba deberarealizarse Una vez sea implementado el componente. Se prueba lafuncionalidad de Una clase o conjunto de clases correlacionadasSu objetivo es probar la uni6n de las componentes del sistema, Unavez estos hayan rebasado las pruebas unitarias se deber verificarque estos interactuan correctamente a travs de las funcionalidadesexpuestas en Sus interfaces, se verifican las interfaces entre las partesde Una arquitectura. Este tipo de prueba debera realizarse durante lafase de construcci6n, Una vez sea implementado el componente.Su objetivo es comprobar la funcionalidad de todo el sistemaSu objetivo es la comprobaci6n de cualquier detalle de disehointerno hasta aspectos coma las comunicaciones. Se deben verificarfundamentalmente las requisitos no funcionales definidos parael producto coma par ejemplo, comprobar que el sistema puedegestionar los volumenes de informaci6n requeridos, se ajusta a lastiempos de respuesta deseados y que los procedimientos de respaldo,seguridad e interfaces con otros sistemas funcionan correctamente.Se debe verificar tambien el comportamiento def sistema bajo lascondiciones ms extremas.Su objetivo es el de verificar formalmente con el cliente que el sistemasatisface todas Sus necesidades.Es un conjunto de pruebas que se ejecutan nuevamente. Su objetivoes verificar que cambios ocurridos en un componente def sistema noprovocan errores adicionales en otros componentes def mismo queya han sido probados.

Aceptaci6n

Regresi6n

Es muy comun encontrarse en la literatura que aborda el proceso de pruebas una referenciaal "Modelo V" (Le6n Carrillo, 2005). Este modelo describe a un nivel alto de abstracci6nlas fases def ciclo de desarrollo en las que se involucran las pruebas y los niveles de lasmismas, la Figura 1 muestra este modelo.

La prueba comienza hacienda revisiones tecnicas a las requerimientos y hacienda unesfuerzo de los primeros casos de pruebas de aceptaci6n, se continua revisando que laarquitectura satisfaga los requerimientos y definiendo las primeros casos de pruebas desistemas. Despues se revisa la modular|dad def diseho y se esfuerzan las casos de pruebasde integraci6n, para luego pasar a revisar las algoritmos y a desarrollar los casos depruebas de unidad.

Las actividades de pruebas de la linea izquierda de la V se Ilevan a cabo en paralelo aldesarrollo de software y se produce de cierta forma la documentaci6n y la descripci6nde las pruebas. La linea de la derecha involucra la terminaci6n del diseho de los casos depruebas y la aplicaci6n de los mismos, en esta parte se producen los informes resultantesde las pruebas (Le6n Carrillo, 2005).

OQ

O.__QvQ~OJ

O

Q-

Ravi'stones e Inicto de D/sen-o Fin del Dise6o y su Aplicaci6n

Fig. 1 . Modelo V de pruebas (Le6n Carrillo 2005).

Cuando se construye un software a la medida para un cliente se Ilevan a cabo una seriede pruebas de aceptaci6n para permitir que el cliente valide todos los requisitos. Estaspruebas tienen como objetivo validar el producto y verificar si este atiende a los requisitosespecificados. Elias se realizan en un ambiente semejante al ambiente real de ejecuci6n.

Las pruebas de aceptaci6n involucran pruebas funcionales y de sistema. En el caso de laspruebas funcionales se realizan pruebas con el mtodo de caja negra, utilizando tecnicasde participaci6n equivalentes, aha|Isis del valor limite, de comparaci6n, etc. (Collado,2003).

Las pruebas de aceptaci6n tambin involucran pruebas de desempeo, de stress,de seguridad, pruebas para los datos persistentes, haciendo en este caso pruebas defrecuencia de uso, restricciones de acceso, restricciones de integridad, requisitos deguarda y retenci6n de datos, entre otras.A este nivel de pruebas se rectifican atributos de calidad como confiabilidad, usabilidad,portabilidad, etc.

A continuaci6n se describe un flujo de trabajo para la realizaci6n de pruebas de aceptaci6ndel cliente para un software de gesti6n dirigido y diseado por Una empresa certificadorade calidad.

Descripci6n del flujo de trabajo de pruebas de aceptaci6nEl flujo de trabajo que se propone para el proceso de pruebas de aceptaci6n seen la figura 2.

muestra

Superada |

Fig. 2. Flujo de trabajo de Pruebas de Aceptaci6n.

A continuaci6n se detallaran cada Una de las actividades con su descripci6n, Sus objetivos.En las diferentes tablas se especifican los artefactos que son entradas y salida de cadaactividad; y los pasos a ejecutar.

1.- Planificaci6n de las pruebas.En la primera actividad su prop6sito es definir y documentar los objetivos de las pruebas,el alcance de las mismas, los tipos de pruebas, los elementos a probar los recursosnecesarios el cronograma y los riesgos en un plan de pruebas (De Pdua-Paula, 2001).Involucra las tareas de Planificaci6n Inicial, ldentificaci6n de los elementos a probar yRefinamiento del plan (Ver Tablas 2, 3 y 4). Este plan de pruebas puede sufrir cambiosdurante todo el ciclo y es el encargado de guiar las pruebas.

Tabla 2. Planificaci6n de las pruebas.

Entrada Tareas Salida

1.Expedientes del software a probar,segun la NC, ISO/ IEC12119, este debecontener:.La versi6n del producto liberada.Especificaci6n de los CU. Documento de Especificaci6n de Requerimiento

. Glosario de terminos

. Manual de usuarios

. Manual de instalaci6n

. Documentos con los niveles de usuarios,permisos, hombres y los detalles necesarios

.Requerimiento minimo de hardware ysoftware para realizar las pruebas

.Algunos juegos de datos que contienenla BD

. Documento de la Arquitectura.2.Expediente de Pruebas anteriores~3.Casos de pruebas realizados en el ciclode desarrollo.4.Producto

Tabla 3 . Planificaci6n Inicial

Planificaci6n Inicialldentificaci6n de loselementos a probarRefinamiento delplan

Plan de prueba.

Objetivo: Definir los objetivos, alcance de las pruebas, tipos de pruebas, recursos, etc.

Entrada Pasos a seguir Salida__________________

.Expediente del software a probar

.Expediente de pruebas anteriores

1.Entrega de la documentaci6n necesariapor parte de los desarrolladores.2.Entrega de los objetivos de las prue-bas y tipos de prueba que desean losclientes.3.Seleccionar el ambiente de pruebas,identificar:.Objetivos. Alcance de las pruebas. Estrategia de evoluci6n del plan. Areas de riesgo. Tcnicas para registrar y validar lassalidas.

4.Especificar condiciones de completitud:.Tipos de pruebas a realizar.Grado de cobertura5.Especificar condiciones finales de laspruebas.. En caso de terminaci6n normal

. lnformaci6n generaldel Plan de pruebas

.En caso de terminaci6n anormal yprocedimiento a adoptar en estecaso

6.Determinaci6n de recursos. Persona. Hardware. Software. Herramientas de pruebas7.Especificar una pre - agenda.

Tab\a 4. Identificar los elementos a probar.

Objetivo: Especificar todos los elementos que sern probados para con ello solicitar toda la informaci6n necesaria para la elaboraci6n de las pruebas necesarias._________________________________________________

Entrada Pasos a seguir Salida

1,Expedientes del soft- 1.Identfficar requisitos funcio- Plan de pruebas en espe-war a probar hales y requisitos no funcfona- cffico con la definfci6n de.Especificaci6n de los CU les a probar las estrategias de pruebas,. Documento de especifi 2.Identfficar los tipos de prue- crfterfos de aceptaci6n defcaci6n de Requeri`mlento bas a realfzar producto y evaluaci6n de

. Documento de Arqui 3.Deterfninar la estrategia de las pruebas.tectura las pruebas

. Manual de Usuario 4.Determinar crfterfos de acep-' Manual de lnstalaci6n taci6n de productos2.Expedientes de Pruebas

Tabla 5. Refinamiento del plan.

Objetivo: Refinar el plan de pruebas, detallando el cronograma de trabajo.

Entrada Pasos a seguir Salida_____________

a\\v

>OJ

Q:

1 Revisar el plan de pruebas definido Plan de pruebas2 Determinar el cronograma detallado completo.3 Reuni6n de conciliaci6n y aprobaci6ndel plan de pruebas por los involucrados

Plan de pruebas

2.- Oiself:;iar pruebas:A partir de las especificaciones en el plan de pruebas y de las estrategias a seguir sedetermina:. Oisear los niveles de pruebas, tipo de prueba, procedimiento y caso de pruebas (Cortes2004). Seleccionar herramientas automaticas de pruebas (Rice, 2002). Ordenar la ejecuci6n de los casos de pruebas.En los casos de pruebas se documenta la secuencia de pasos para ejecutar el caso deprueba, los requisitos de datos para realizar las pruebas, los resultados esperados y losmetodos para registrar los resultados (Ver Tabla 6).

Tabla 6. Disear pruebas.

Entrada Pasos a seguir Salida___________________

1 Expediente del proyecto. Documento de Especificaci6n de Requerimientos

. Documento de Arquitectura

. Especificaci6n de las CU2 Expediente de prueba3 Plan de pruebas

1 Disehar las pruebas par niveles,determinando el objetivo de cadaprueba.2 Especificar las casos de pruebaa partir de las CU.3 Detallar las casos de pruebas, elprocedimiento a utilizar, deter-minando las Va|ores de entrada ysalida.4 Determinar el contenido de laslistas de chequeos para mediratributos de las interfaces y decalidad con las que debe contarel software.5 Seleccionar herramientas au-tomaticas de prueba.6 Ordenar las casos de pruebas aejecutar.7 Reuni6n de conciliaci6n de lascasos de pruebas a aplicar.

1 Expediente de laspruebas de acep-taci6n2 Especificaci6n de lascasos de prueba

3.- lmplementaci6n de las pruebas.En esta actividad se realiza la instalaci6n del hardware, software y herramientas necesariaspara realizar las pruebas. Ademas se selecciona el equipo de probadores y se capacita aIpersonal (Ver Tabla 7).

Tabla 7. Implementad6n de las pruebas.

Entrada Pasos a seguir Salida___________________

1 Plan de pruebas2 Especificaci6n decasos de pruebas

1 Configurar el ambiente depruebas~2 lnstalaci6n del software aprobar.3 lnstalaci6n de las herramientasautomaticas de pruebas.4 Selecci6n del equipo de proba-dares.5 Capacitaci6n del personalinvolucrado en las pruebas.

Ambiente de pruebalisto para comenzarlas pruebas.

las

4.- Ejecuci6n de las pruebas.Se realizan las pruebas planificadas, tal y coma se documenta en las casos de pruebas.Se registran las resultados y se comprueban. Se documenta cualquier desviaci6n de lasresultados esperados. Se realizan diariamente reuniones para revisar las no conformidades(NC) registradas y se determina las prioridades de las no conformidades. (Ver Tabla 8).

Es irnportante destacar en esta etapa, el proceso de registro y seguimiento de noconformidades. Durante la ejecuci6n de las pruebas, todos los miembros del equipopueden registrar no conformidades que se encuentren. Cada no conformidad se registracon una descripci6n reconocible, una Imagen de donde fue hallada, el mensaje de error,pasos exactos que se pueden repetir para reproducir el error, ademas si se conoce unaposible soluci6n, se puede aadir una soluci6n recomendada.Solo el jefe de prueba es el que tiene el derecho de cambiar el estado de la no conformidad.

Cuando - no conformidad- se corrige, cambia el estado de abierto a corregido. Las noconformidades con el estado corregido se vuelven a asignar a Una persona, preferiblementea quien la haII6, para realizar las pruebas de regresi6n. Despues de comprobado que nohay error cambia el estado a cerrado.

Otra actividad importante desarrollada en esta etapa son las reuniones de conciliaci6ndiarias, en el|as se describen y se analizan cada nueva no conformidad registrada en elseguimiento, se Ilega a un entendimiento del problema entre los miembros del grupo,se revisa la gravedad de la no conformidad, el cliente asigna Una prioridad, se vuelven arevisar las no conformidades corregidas para cerrarlas.

Tabla 8. Ejecuci6n de las pruebas.

Entrada Pasos a seguir Salida_________________

1 Plan de pruebas2 Herramienta de pruebasinstaladas y configuradas3 Ambiente de pruebaslista4 Especificaci6n de loscasos de pruebas.

1 Ejecutar las pruebas, la eje-cuci6n de los casos de pruebas.2 Determinar y registrar losresultados.3 Reuni6n diaria de conciliaci6n yprioridad de las NC.

4 Entrega a los involucrados delInforme diario de NC.5 Analizar fa|las diarias y tomarprovidencias adecuadas( fallospropios de las pruebas)6 Aplicar las listas de chequeos deinterfaz de usuario y de atributosde calidad.

1 Registros de laspruebas realizadas2 Informe diario deno conformidades

5.- Analllsis finalEn esta actividad se realiza el analisis final del ciclo de pruebas de aceptaci6n, elaboraci6nde los informes finales (Microsoft Corporation, 2001) e identificaci6n de artefactosreutilizables (Ver Tabla 9).Tabla 9. An|Isis final.

Entrada Pasos a seguir Salida_________________

1 Plan de pruebas. 1 Describir el status de las prue- 1 Componentes de2 Informe diario de no bas pruebas reutilizables.conformidades. . Variaciones. 2 Informe final de no3 Registro de las Pruebas . prob|efnas no resueltos, conformidades.

realizadas' 2 Confeccionar el informe final de 3 Informe final de acep-no conformidades. taci6n del software.

4 Aprobar el informe final de noconformidades.5 Identificar artefactos reutilizables.6 Elaborar las solicitudes de cam-bio.7 Aprobar las solicitudes de cam-bio.8 Elaborar el documento de evalu-aci6n de las pruebas de aceptaci6n.

6.- Examen de la aceptaci6nDurante el examen de la aceptaci6n, el equipo de desarrollo, clientes y los terceros sereunen para discutir si se va a aceptar o no el producto. Si el examen es satisfactorio, seacepta el producto si no es satisfactorio se revisan y corrigen los problemas y se pasa auna segunda iteraci6n de este proceso de pruebas.

Funciones y responsabilidadesEn la siguiente tabla se resumen los roles que participan en el flujo de trabajo y lasresponsabilidades que tienen cada uno.Tabla 10. Responsabilidades de cada rol.

Roles Responsabilidad

Oa

O._a

va

wOa~oOav4...,L_IO

V

O

Gestionar el proceso de pruebas.Definir los objetivos de las pruebas.Elaborar y aprobar el plan de pruebas detallado.Aprobar la especificaci6n de los casos depruebas detalladosDefinir el mtodo de registro de las no conformidades~Revisar el documento de no conformidades ylos errores introducidos.Dirigir la reuni6n diaria de conciliaci6n conlos clientes de las no conformidades de conjunto con el grupo certificador.Generar los documentos finales de la ejecuci6n de las pruebas.Revisar criterios de aceptaci6n del productofinal.Conciliar plan de pruebas de aceptaci6n conclientes y desarrolladores.Revisar el producto vs. lista de requisitos delsoftware.Aprobar inicio de la ejecuci6n de las pruebasde aceptaci6n.Oisear los casos de pruebas.Auditar la configuraci6n del software.Auditar pruebas realizadas por el equipo depruebas.Supervisar la reuni6n diaria de conciliaci6ncon los clientes de las no conformidades deconjunto con el grupo certificador.

Jefe del equipo de pruebas

Grupo Certificador