Aplicación de un Método para Especificar Casos de Prueba de Software en la Administración Pública
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Actas de Talleres de Ingeniería del Software y Bases de Datos, Vol. 1, No. 5, 2007 47
Aplicación de un Método para Especificar Casos de Prueba de
Software en la Administración Pública
Edumilis Méndez, María Pérez, Luis E. Mendoza
Departamento de Procesos y Sistemas, Edificio de Matemáticas y Sistemas, Laboratorio de Investigación en Sistemas de
Información (LISI), Universidad Simón Bolívar, Apartado 89000, Baruta, Caracas, 1080-A, Venezuela
{emendez, movalles, lmendoza}@usb.ve
Resumen y después de esta fase se realizan actividades de
Una diferencia interesante entre las Pruebas y verificación (¿se está construyendo el producto
otras disciplinas del proceso de desarrollo de correctamente?).
software es que esencialmente es una tarea que El objetivo de la Disciplina de Pruebas es evaluar
encuentra y pone de manifiesto las debilidades del la calidad del producto a lo largo de todo el ciclo
producto de software. Existen cuatro elementos de vida apoyándose en un conjunto de buenas
que son relevantes al momento de definir las prácticas, entre las que destacan [4]:
pruebas: Confiabilidad, Costo, Tiempo y Calidad. • Verificar que el producto de software trabaja
En la medida que se deseen pruebas confiables y según el diseño.
un software de calidad, el tiempo y el costo se • Validar que los requerimientos son
incrementarán. Pero ¿qué se puede hacer para que implementados apropiadamente.
los involucrados comprendan que las pruebas En [2] indican que esta disciplina, generalmente
deben ser vistas como una red de seguridad? Si la no se implementa de forma organizada y
Calidad no está ahí antes de comenzar las pruebas, sistemática. Además, algunos autores como [1, 3,
entonces no estará cuando se terminen. En base a 5, 6, 7] afirman que el proceso de ejecución de
esto, ¿cómo se puede hacer una traza entre las Pruebas debe ser considerado durante todo el ciclo
Pruebas y los requerimientos funcionales y no de vida de un proyecto, para así obtener un
funcionales del sistema de software? El objetivo producto de alta calidad. Su éxito dependerá del
de este artículo es proponer un método que seguimiento de una Estrategia de Prueba
permite especificar Casos de Prueba a partir de adecuada. La Estrategia de Prueba de software
Casos de Uso incorporando elementos que integra un conjunto de actividades que describen
permiten verificar y validar la trazabilidad entre la los pasos que hay que llevar a cabo en un proceso
Gestión de Requerimientos, el Análisis y Diseño y de prueba, tomando en consideración cuánto
las Pruebas. Esta iniciativa se originó como esfuerzo y recursos se van a requerir, con el fin de
respuesta a una necesidad del sector público obtener como resultado una correcta construcción
venezolano que desarrolla software. del software [6].
Las empresas desarrolladoras de software
1. Introducción invierten en las pruebas entre el 30% y 50% del
costo total del software [6]. Esto representa un
La Disciplina de Pruebas de Rational Unified esfuerzo considerable indicando que es una
Process (RUP) se aborda desde la fase de inicio disciplina cuyos resultados (confiabilidad de la
[3]. Esto quiere decir que las pruebas se deben prueba) pueden impactar sobre la percepción del
comenzar a planificar y además se debe establecer cliente o usuario en cuanto a la calidad del
cuál es la estrategia de pruebas a seguir una vez software que se le está entregando.
que han aprobado todos los Casos de Uso (CU) En el año 2004 el Estado Venezolano promulgó el
correspondientes a la iteración. Esta disciplina decreto 3.390, que establece el uso prioritario de
amerita un mayor esfuerzo en la fase de Software Libre (SL), basado en estándares
construcción ya que es el momento en el que se abiertos en los servicios y sistemas informáticos
valida (¿se está construyendo el producto de los organismos pertenecientes a la
correcto?) el producto de software. Antes, durante Administración Pública Nacional (APN). Por lo48 Actas de Talleres de Ingeniería del Software y Bases de Datos, Vol. 1, No. 5, 2007
tanto, la responsabilidad recayó en el Ministerio Confiabilidad, Eficiencia, Mantenibilidad y
del Poder Popular para las Telecomunicaciones y Portabilidad.
la Informática (MPPTI), tomando como • Las especificaciones de diseño del Sistema, ya
responsabilidad definir los lineamientos y que se debe verificar que el software fue
políticas para llevar a cabo los procesos implementado según el diseño y que los
institucionales de migración gradual y progresiva elementos arquitectónicos garantizan la
a SL a través de proyectos de desarrollo de calidad del software.
software. Para ello, se propuso una metodología Esto garantiza que los procedimientos de pruebas
basada en Unified Process (UP). sean compatibles con las necesidades de los
Pero, como empresa, ¿qué estrategia se puede usuarios/clientes. En la práctica se tiende a asumir
utilizar, qué metodología o método se debe seguir que un CU en si mismo es un CP y que el equipo
para establecer una trazabilidad entre las pruebas del proyecto trabaje correctamente sobre los CU
y los requerimientos y garantizar un mejoramiento sin planificar los CP. Cuando se sienta a probar
de las actividades de verificación y validación? los CU, intuitivamente asume datos y
Garantizándose así la entrega de un producto de procedimientos de pruebas sin que estas queden
software de Calidad. documentadas. Esto es un error ya que el CP
En respuesta a ello, el Laboratorio de extiende o amplia la información contenida en un
Investigación en Sistemas de Información (LISI) CU; por ejemplo, en los CU no indicamos valores
atendió al llamado del MPPTI al proponer un ni condiciones para la pruebas.
método que permite especificar CP a partir de los Los CP son esenciales para todas las actividades
CU como punto de partida para la estandarización de pruebas [4]:
y la trazabilidad de todo el proceso de desarrollo • Son la base para diseñar y ejecutar los
de software y de forma eficaz, obteniendo procedimientos de pruebas.
productos de calidad con una alta productividad. • La profundidad de las pruebas es proporcional
Este artículo presenta la siguiente estructura: al número de casos de pruebas.
inicialmente se tratan los Casos de Prueba y la • El diseño y desarrollo, y los recursos
relación de la disciplina de pruebas con otras necesarios son gobernados por los casos de
disciplinas presentes en el proceso de desarrollo pruebas requeridos.
de software. En la sección 3, se muestra el Método Si los CP no son correctos, la Calidad del Sistema
propuesto indicando los roles, actividades y se pone en duda y las pruebas dejan de ser
artefactos asociados. Por último, las conclusiones confiables.
y próximos pasos. La Figura 1 muestra un modelo conceptual sobre
los conceptos que están asociados a los CP. En
2. Casos de prueba ella se puede observar que los CU son la fuente
principal de los CP, estos se encuentran como
Un CP es una especificación, usualmente formal, entregables del documento Plan de Pruebas de
de un conjunto de entradas de prueba, condiciones RUP. Es importante señalar que en la plantilla de
de ejecución y resultados esperados, identificados este documento no se encuentra un formato
con el propósito de hacer una evaluación de establecido para especificar los CP. Los CP se
aspectos particulares de un elemento objeto de pueden agrupar mediante Suite de Pruebas. Los
prueba [4]: CP están relacionados con el nivel de la prueba y
• Los CP reflejan trazabilidad con los CU con el tipo de prueba, la cual a su vez contiene la
(Funcionalidad), ya que estos muestran una técnica que permite ejecutar el tipo de prueba. Los
secuencia ordenada de eventos, al describir CP proveen las instrucciones para el
flujos básicos, flujos alternos, precondiciones procedimiento de las pruebas. En el método que se
y postcondiciones. propone en este artículo se indica que el
• Las especificaciones suplementarias de procedimiento de la prueba se conforma de pasos,
requerimientos ya que existen otras condiciones, valores y resultados esperados y
características de calidad a evaluar, además de obtenidos. A su vez, el procedimiento de las
la funcionalidad, como Usabilidad, pruebas puede ser automatizado a través de los
script de pruebas. Todos los conceptos indicadosActas de Talleres de Ingeniería del Software y Bases de Datos, Vol. 1, No. 5, 2007 49
anteriormente permiten visionar el enfoque de las componen, los roles o personas que participan
pruebas: ¿qué se probará, cómo, quién, cuándo, en ella y el artefacto que se genera. Así mismo,
para qué? Una vez ejecutados todos los CP, estos ayuda a documentar las ideas previas a las
resultados deben reflejarse de manera global. Con pruebas, los CP y cómo estos fueron generados,
ello, se establece si al validar el sistema se todo esto se utiliza para verificar la trazabilidad
cumplió con los criterios de aceptación definidos de las pruebas con respecto a las fases previas y
con el usuario. las disciplinas de Requerimientos, Análisis y
Diseño. Además, se garantiza la gestión del
conocimiento de la organización en lo que a
Aseguramiento de la Calidad se refiere.
Este método incorpora los 4 roles que se
proponen dentro de la Disciplina de Pruebas:
Gerente de Pruebas, Diseñador de las Pruebas,
Analista de Pruebas y Probador. A continuación
se describe cada fase. Por limitaciones de espacio,
se hará notar los aportes de los autores destacando
el elemento mediante letra cursiva.
Cabe resaltar que MECAP es activado por el
analista de pruebas una vez que se hayan
Figura 1. Modelo Conceptual asociado a los CP. verificado las narrativas de los CU; al estar
aprobadas las funcionalidades del sistema por
En la siguiente sección se explica en detalle el parte de los stakeholders.
método propuesto.
3.1. Fase 1: Identificar escenarios.
3. Método para especificar casos de
prueba (MECAP) Las actividades de esta fase, a ser realizadas por el
Analista de Pruebas son las siguientes:
El método propuesto consiste en construir CP a 1. Se identifican los escenarios tomando como
partir de CU ya que se parte del supuesto que se base las narrativas de los CU y considerando cada
debe probar el comportamiento del software en uno de los escenarios específicos que ocurren para
base a las solicitudes o requerimientos. El moverse cada CU. El flujo normal, cada flujo alterno o la
de un CU a un CP es un proceso razonablemente combinación de ellos es un escenario, que puede
amplio y no trivial. En [4] señalan cuatro (4) pasos ser ejecutado y probado. Esto deriva que siempre
para lograrlo. Estos pasos indican qué debe el primer escenario sea el que evoca todo el flujo
hacerse pero no se enseña el cómo de una forma normal de ese CU en particular y que la relación
detallada; es decir, hay cosas que no están escritas entre CU y escenarios sea de uno a muchos.
y que después de la revisión bibliográfica y de la 2. Presentar gráficamente la secuencia de eventos
experiencia con el MPPTI y otras empresas fueron que se plantea en cada CU: esto permite, como lo
propuestas y recogidas a través de MECAP. muestra la Figura 2 abstraer los eventos que
Tomando como base los pasos que establecen [4] ocurren en un CU: el flujo normal o básico y los
se propone un método para especificar CP a partir flujos alternos, y sirve de apoyo para visualizar
de CU, constituido por cuatro fases principales: fácilmente las posibles combinaciones que
1. Identificar Escenarios. representarían un escenario ya que establece en
2. Identificar CP. qué punto del flujo básico ocurre y además qué
3. Especificar los CP. sucede después que se activa ese flujo alterno:
4. Ejecución y Aprobación del CP. finaliza el CU o retorna al flujo básico.
El aporte de MECAP es que incorpora elementos 3. Chequear que se hayan representado
de trazabilidad de las pruebas con respecto a gráficamente todos los Flujos alternos con su
todo el proceso de desarrollo, y a su vez mejora la acción de finalización o retorno.
estrategia de las pruebas al disciplinar este 4. Establecer a través de una tabla (como lo refleja
proceso, estructurándolo en fases, actividades que la Figura 3), todos los escenarios asociados a un50 Actas de Talleres de Ingeniería del Software y Bases de Datos, Vol. 1, No. 5, 2007
CU de la Figura 2. Esta nomenclatura debe ser establecida por la
5. Identificar cada escenario del CU indicando el organización. Además, es importante que se
flujo normal y/o el o los flujo(s) alterno(s) que lo agregue un nombre corto durante la
componen. La Figura 4 constituye el primero de identificación de los flujos alternos que
los 3 artefactos que se generan en MECAP: Tabla representan o conforman un escenario. La
de Escenarios por CU. En esta se puede observar información de los escenarios que se muestran en
que se incorpora el ID del Escenario con el la Figura 4 está asociada a la narrativa de un CU
propósito de establecer un elemento de (Validar Usuario del Sistema Tarjeta Académica
trazabilidad de las pruebas lo que facilita, a su Inteligente –TAI–), el cual sirve de ejemplo para
vez, las actividades de verificación y aprobación explicar el método propuesto.
de las pruebas, así como el CU asociado a este. 6. Verificar que se hayan identificado y descritos
Como se puede observar en la Figura 4 el ID todos los escenarios posibles para cada CU.
puede estar conformado por el Nro. CU y Nro. En síntesis, cada escenario representa el número
Escenario. de posibilidades o formas a través de las cuales se
Inicia el CU puede ejecutar el CU. Esto evita que sólo se
Flujo básico prueben algunas de las combinaciones posibles.
Flujo alterno 3
Flujo alterno 1
3.2. Fase 2: Identificar los CP
Flujo alterno 4
Flujo alterno 2 El proceso de pruebas varía según la empresa y el
proyecto, pero en cada situación un CP documenta
un número de elementos comunes.
Fin del CU Fin del CU
De un escenario de un CU pueden derivarse varios
Fin del CU CP. Después que se han identificado todos los
escenarios de un CU, se analizan cada uno de
Figura 2. Visualización de los Flujos en un CU [4] ellos en la búsqueda de los posibles CP. Esto se
Nro. Escenario Flujo Originario Flujo alterno Próximo alterno Próximo alterno
traduce en las siguientes actividades a ser
Escenario 1 Flujo Básico realizadas por el Diseñador de las Pruebas:
Escenario 2 Flujo Básico Flujo alterno 1 1. Se organizan las ideas de pruebas en base a los
Escenario 3 Flujo Básico Flujo alterno 1 Flujo alterno 2
elementos que se desean probar: funcionalidad
Escenario 4 Flujo Básico Flujo alterno 3
(CU), atributos de calidad, validaciones de
Escenario 5 Flujo Básico Flujo alterno 3 Flujo alterno 1
entradas y salidas, base de datos, interfaces, etc.
Escenario 6 Flujo Básico Flujo alterno 3 Flujo alterno 1 Flujo alterno 2
Escenario 7 Flujo Básico Flujo alterno 4
Esto va a depender del tipo de aplicación, de las
Escenario 8 Flujo Básico Flujo alterno 3 Flujo alterno 4
restricciones tecnológicas, del alcance del
proyecto, del propósito y la motivación de las
Figura 3. Escenarios por CU [4] pruebas, y experiencia del equipo de pruebas
(sobretodo, del probador).
2. Se comienza a llenar la Tabla que se muestra a
través de la Figura 5, la cual representa el segundo
artefacto del método propuesto y cuyos datos
están asociados a considerar los CP para el
Escenario 02-02 (Error en Login). Con la
información proveniente de las ideas de pruebas
se puede decir que para este caso se podría tener
un CP para validar “error en login” cuando se
introducen caracteres inválidos, un CP cuando el
login está en minúsculas, un CP cuando el login es
mayor a 10 caracteres, un CP cuando el login está
Figura 4. Escenarios para CU002
en blanco. Se completa la información asociada a
Esto nos indicaría, por ejemplo, que si se tiene 03- cada CP identificado: ID Caso de Prueba,
02, se traduce como el escenario 02 del CU 03. Nombre del CP, Resultados esperados (valores,Actas de Talleres de Ingeniería del Software y Bases de Datos, Vol. 1, No. 5, 2007 51
mensajes de error, etc.), Nivel de prueba y Tipo CP y la fecha en la que fue ejecutado.
de prueba. Con respecto al ID del CP se propone 6. Identificar las condiciones que deben estar
incluir en la nomenclatura estándar que presentes para ejecutar el CP. ¿Cuáles son las
determine la organización una estructura que condiciones que originan o causan que un usuario
refleje CU-Escenario-CP para así saber por ejecute un evento específico o una secuencia de
ejemplo que 02-02-01 significa el CP 01 del eventos? En la Figura 6, se tiene el CP 02-02-02
Escenario 02 del CU 02. en cual se propone el CP para Login con
3. Se verifica que se hayan identificado todos los minúsculas. En esta figura se observa que se
CP para cada escenario. Después de esto, se deben haber implementado todas las
procede a la siguiente fase. funcionalidades asociadas con Validar Usuario,
así mismo, los Datos que se utilizaran en este CP
hayan sido validados y aprobados por la instancia
correspondiente, etc.
Figura 5. Casos de Prueba para el Escenario 02-02
3.3. Fase 3: Especificaciones de los CP
Uno de los aportes más importantes de esta
investigación es el tercer artefacto (su diseño) que
se utiliza para especificar con detalle el CP y que
se muestra a través de la Figura 6: Tabla de
Especificaciones de CP (ECP). Su llenado es Figura 6. Especificación del CP (ECP) 02-02-02
también, responsabilidad del diseñador de las 7. Describir el procedimiento del CP. Este
Pruebas. Para cada CP, se deben llevar a cabo las procedimiento está compuesto de los pasos que se
siguientes actividades: deben hacer para probar el Escenario del CU a
1. Identificar el nombre del Sistema, ID CU, ID de través de lo que plantea el CP, de las condiciones
Requerimiento, ID Escenario, ID del CP y versión particulares que pudieran aplicar para un
del CP. Esto permite hacer una traza bidireccional determinado paso, los valores utilizados, los
entre estos elementos: por ejemplo, se puede resultados esperados y los resultados obtenidos.
conocer si se especificaron todos los CP para Cabe resaltar, que este último se incluye en la
todos los CU y se probaron todos los CU Tabla ECP una vez que el CP es ejecutado.
(cobertura de las pruebas). Sin la incorporación de datos no es posible
2. Identificar el nivel y tipo de prueba asociada al ejecutar las pruebas y determinar los resultados.
CP y cuya información proviene de la Tabla CP Se deben observar las especificaciones
por Escenario. suplementarias para encontrar medidas de
3. Indicar el ambiente de las pruebas. Se puede desempeño (mínimo y máximo), rangos válidos de
señalar el nombre de la empresa, si es el ambiente entrada, protocolos de interfaces, entre otros.
de desarrollo o producción, o si tengo varios Como se puede observar en la Figura 6, se tiene
ambientes en la empresa se indica en cuál de ellos como pasos: 1) introducir login y 2) presionar Ok.
se ejecutará ese CP en particular. Para que se ponga en práctica el paso 1 se tiene
4. Identificar el nombre del autor del CP y del como condición que el usuario debe haber hecho
Probador. Se recomienda que sean personas menos de 3 intentos. De lo contrario el paso no
diferentes las que ocupen estos roles a fin de darle puede activarse. Así mismo, se indican los valores
seriedad y confiabilidad al proceso de las que se deben introducir en el login, para cuáles se
pruebas. debe tratar de utilizar datos aplicables al negocio y
5. Señalar la fecha de creación de la versión de ese a la lógica de lo que propone el CP. Por ejemplo:52 Actas de Talleres de Ingeniería del Software y Bases de Datos, Vol. 1, No. 5, 2007
si el CP plantea login con minúsculas, el valor 4. Discusión de resultados y próximos
debe tener al menos una letra en minúsculas y el pasos
resultado esperado (mensaje de error). Este paso
puede repetirse varias veces a fin de comprobar El método propuesto MECAP fue utilizado en el
que el sistema da un mensaje de error si el login MPPTI para 4 proyectos obteniendo resultados
tiene en alguna de sus caracteres una letra en significativos en cuanto a 1) la calidad de los
minúsculas, lo que representaría repetir este paso productos desarrollados: al momento de culminar
al menos 11 veces dentro del CP. la fase de construcción los sistemas de software ya
8. Se indica cuál es el Criterio de Aprobación del habían alcanzado un 90% de calidad esperada; 2)
CP. Como se observa en el ejemplo de la Figura el proyecto más grande llegó a implementar 51
6. El Criterio es que se deben cumplir en un 100% CU lo que se tradujo en documentar, ejecutar y
todos los resultados esperados. También puede aprobar 460 CP y la Tabla de ECP puede ser
indicarse a nivel de pasos cuando el CP involucra utilizada para definir procedimientos de CP
pasos diferentes y alguno(s) de ellos son más asociados a requerimientos no funcionales; 3) la
importante que otros; p.e., El CP está superado si experiencia sentó un precedente y será replicada
se cumplen en un 100% los resultados esperados para futuros proyectos y además estableciendo
del Paso 2, 4 y 5. indicadores de gestión que pueden reflejar por
9. El analista y diseñador de las pruebas verifican ejemplo: el número promedio de CP por
que todos los CP se hayan especificado aplicación. Actualmente, MECAP está siendo
correctamente. utilizado por otras organizaciones del sector
público y privado que recogen 16 proyectos por lo
3.4. Fase 4: Ejecución y aprobación del CP que un próximo paso es publicar los resultados
detallados de la aplicación de este método en cada
Esta fase consiste en poner en práctica el una de estas organizaciones.
procedimiento de los CP que se encuentran en la
Tabla ECP. A continuación se indican las 5. Conclusiones
actividades de esta fase:
1. Debe comprobarse que está dado el ambiente y
En este artículo se describe un método que
las condiciones para ejecutar los CP. Los involu-
permite especificar Casos de Prueba a partir de
crados en las pruebas deben cooperar en esto.
Casos de Uso incorporando elementos que
2. El Gerente y Diseñador de las pruebas deben
permiten verificar y validar la trazabilidad entre la
autorizar que se active el ciclo de prueba.
Gestión de Requerimientos, el Análisis y Diseño y
3. El Probador ejecuta todos los CP e incorpora
las Pruebas. Esta iniciativa se originó como
los datos de los resultados obtenidos en cada
respuesta a una necesidad del sector público
Tabla ECP.
venezolano que desarrolla software.
4. El Gerente de Pruebas toma la decisión de si
Adicionalmente, se puso en evidencia que los
aprobó o falló el CP en base al criterio de
costos de las pruebas pueden verse reducidos a
aprobación y, además, indica la fecha de la
mediano y largo plazo ya que se pueden utilizar
aprobación y en algunos casos, estampa su firma.
Probadores que no sean Especialistas si se tiene
5. El equipo de pruebas verifica si se cumplió el
definido con anterioridad ¿qué se debe probar,
criterio de salida del ciclo de prueba para decidir
cuándo y cómo?.
si se aprueba el ciclo de prueba o hay que hacer
pruebas de regresión y pruebas adicionales a
ciertos CP en un próximo ciclo de prueba hasta Referencias
que se obtengan los criterios de aceptación.
6. El equipo de pruebas guarda todos estos [1] Cardoso, R. (2001). Pruebas del Software.
entregables y publica los resultados de los ciclos Mérida, Venezuela.
de prueba, cambios, etc. que se obtuvieron [2] Grimán A., Pérez, M. & Mendoza, L. (2003).
durante el proceso de pruebas. Estrategia de pruebas para software OO que
garantiza requerimientos no funcionales. IIIActas de Talleres de Ingeniería del Software y Bases de Datos, Vol. 1, No. 5, 2007 53
Workshop de Ingeniería de Software, Chillán,
Chile.
[3] Kruchten, P. (2000). The Rational Unified
Process as Introduction. 2nd Edition. Addison
– Wesley.
[4] Leffingwell D. and Widrig D. (2006).
Managning Software Requirements, a Use
Case Approach. Second Edition. Addison-
Wesley, Pearson Education.
[5] Pfleeger, S. (1998). Software Engineering.
[6] Pressman, R. (2002). Ingeniería del Software:
Un enfoque Práctico. McGraw Hill.
[7] Sommerville, I. (2000). Software Engineering.
Pearson Education.También puede leer
