A través del blog, hemos expuesto todos los detalles que se han llevado a cabo para la realización de la herramienta que centra la temática del concurso, así como información relacionada que permita comprender mejor los conceptos tratados. Una vez implementada la herramienta, es turno de verificar la viabilidad y cumplimiento de los requisitos especificados al inicio de la propuesta. En la presente página se presentará la utilización de la propuesta de automatización de Casos de Uso sobre la herramienta eOPSOA, así como las funcionalidades que ofrece al Analista y Testeador. También se mostrará el aspecto final de la interfaz de usuario de la herramienta.
Para demostrar las posibilidades que ofrece la herramienta, se utilizará como ejemplo real, la propia herramienta eOPSOA, junto con la propuesta de automatización de Casos de Prueba implementada.
Entrega herramienta eOPSOA
Debido a que en la presente página pretendemos demostrar la viabilidad de la herramienta en un entorno real, nos pondremos en la situación de un marco corporativo. Una primera entrega parcial de la herramienta eOPSOA, al departamento de pruebas de la empresa, podría incluir las siguientes funcionalidades las cuales no pasaremos a describir debido a que ya han sido referenciadas en el presente documento:
- Creación de proyectos eOPSOA
- Creación de artefactos Datapool
- Edición de artefactos Datapool
Antes de la entrega del aplicativo implementado, para hacer eficiente la construcción del plan de pruebas y los correspondientes contenedores de Casos de Prueba, le acompañaría una entrega de documentación que incluiría un documento funcional donde se describiría el comportamiento de los artefactos entregados; un posible modelo lógico donde se detallarían los elementos estructurales, entidades, bloques de construcción del sistema y transacciones entre ellos; y finalmente una maqueta gráfica donde se puede apreciar la apariencia de las pantallas e interfaces de usuario presentadas en el documento funcional.
En el mejor de los casos, la maqueta presentada en la entrega comentada, reflejaría las pantallas reflejadas en las siguientes figuras:
Una vez que disponemos de toda la documentación entregada, el equipo de pruebas puede ir desarrollando todos los artefactos necesarios para la validación del aplicativo de forma simultánea, mientras que el equipo de desarrollo termina de implementar la aplicación. De esta forma cuando la aplicación este finalmente terminada y lista para la entrega al equipo de pruebas, éste podrá comenzar la fase de pruebas sin ningún tipo de problemas.
Utilización de eOPSOA con automatización de Casos de Prueba
A lo largo de esta sección se mostrará cómo ha sido utilizada la nueva versión de eOPSOA durante la tarea de certificación OPSOA dentro de la propia herramienta, explicada a lo largo de la presente memoria. Es necesario comentar, que en la presente sección sólo se abordarán las actividades de Generación, Ejecución y Análisis de pruebas. La razón es que estas actividades son las novedades que presenta la propuesta presentada en este concurso.
A) Actividad de Generación de Pruebas
Una vez estudiada de forma minuciosa la documentación, el primer paso sería identificar los escenarios de cada una de las unidades funcionales entregadas Para la creación de proyectos eOPSOA, nos basaremos en el caso de uso que define dicha funcionalidad:
Título | UC-1: Crear proyecto |
Descripción | El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario solicite crear un nuevo proyecto. |
Precondición | Ninguna. |
Secuencia normal | 1. El usuario solicita crear un nuevo proyecto. 2. El sistema solicita al usuario un nombre para el proyecto. 3. El usuario introduce el nombre para el proyecto. 4. El sistema comprueba que no exista otro proyecto con el mismo nombre. 5. El sistema crea un nuevo proyecto vacío. 6. El sistema crea una jerarquía de directorios, y copia los documentos de Cuestionario, Glosario de Términos y de Visión desde plantillas. |
Postcondición | El sistema pone a disposición del usuario un nuevo proyecto. |
Flujo alternativo | Paso 2. El usuario cancela la creación del proyecto. Se deshacen los pasos anteriores y el caso de uso queda sin efecto (A1). Paso 3. El usuario introduce un nombre con caracteres no válidos para el proyecto. El sistema informa que existe un error en la nomenclatura del proyecto y vuelve al paso 2 (A2). Paso 4. El sistema informa que existe un proyecto con el mismo nombre, y salta al paso 2 (A3). |
Los escenarios identificados para esta primera funcionalidad estarían formados por un escenario compuesto por el flujo básico únicamente, que denotaría un escenario donde todo ha sucedido con normalidad, y por otra parte los escenarios compuestos por el flujo básico más cada una de las alternativas que se pueden dar durante el trascurso de la actividad normal. Por lo tanto, los escenarios resultantes son:
Nombre Escenario | Flujos afectados |
Escenario 1 – Proyecto exitoso | Flujo básico |
Escenario 2 – Proyecto repetido | Flujo básico + A1 |
Escenario 3 – Proyecto incorrecto | Flujo básico + A2 |
Escenario 4 – Proyecto cancelado | Flujo básico + A3 |
Por lo tanto pasamos a crear un Conjunto de Casos Pruebas (STCS) que contendrá estos escenarios tal y como se muestra en la siguiente figura:
Una vez se han identificado todos los escenarios, el próximo paso es identificar los Casos de Prueba. Para ayudarnos en la definición de Casos de Prueba y extraer las futuras instrucciones de pasos previos y validación, analizaremos los componentes gráficos aceptados por eOPSOA en cada una de sus formularios:
1. Shell: Opsoa Project Wizard
2. Label: Project name:
3. Text (input)
4. Checkbox: Use default
5. Label: Use default location
6. Label: Location
7. Text (input)
8. Button: Browse…
9. Button: Finish
10. Button: Cancel
También se puede hacer esto analizando los escenarios y repasando también la descripción textual del caso de uso. Debe haber al menos un Caso de Prueba por cada escenario, aunque puede haber más dependiendo de la condición que establezcan. En la siguiente tabla se describen los Casos de Prueba identificados por cada Escenario.
ID Caso Prueba | Escenario | Project name | Location |
00 | Escenario 1 | Dato 1 | N/A |
01 | Escenario 1 | Dato 2 | N/A |
02 | Escenario 1 | Dato 3 | N/A |
03 | Escenario 1 | Dato 4 | N/A |
04 | Escenario 1 | Dato 5 | N/A |
05 | Escenario 1 | Dato 6 | N/A |
06 | Escenario 2 | Dato 7 | N/A |
07 | Escenario 3 | Dato 1 | N/A |
08 | Escenario 3 | Dato 2 | N/A |
09 | Escenario 3 | Dato 3 | N/A |
10 | Escenario 3 | Dato 4 | N/A |
11 | Escenario 3 | Dato 5 | N/A |
12 | Escenario 3 | Dato 6 | N/A |
13 | Escenario 4 | Dato 1 | N/A |
14 | Escenario 4 | Dato 2 | N/A |
15 | Escenario 4 | Dato 3 | N/A |
16 | Escenario 4 | Dato 4 | N/A |
17 | Escenario 4 | Dato 5 | N/A |
18 | Escenario 4 | Dato 6 | N/A |
19 | Escenario 4 | Dato 7 | N/A |
Los datos anteriormente referidos en la columna Project name, se detallan a continuación:
- Dato 1, ABCDEFGHIJKLÑMNOPQRSTUVWXYZ: Cualquier cadena de caracteres. Es una entrada válida para el nombre de un proyecto.
- Dato 2, 1234567890: Cadena de números. Los números son caracteres válidos para el nombre de un proyecto.
- Dato 3, asdfghjklñ1234567890: Cadena alfanumérica. La mezcla de letras y números son caracteres válidos para el nombre de un proyecto.
- Dato 4, Símbolos aceptados. El símbolo “_” es un carácter válido para el nombre de un proyecto.
- Dato 5 Símbolos no aceptados. Los símbolos !"·$%&/()=: no son caracteres válidos para el nombre de un proyecto, dado que no los admite el SO.
- Dato 6, Cadena vacía.
- Dato 7, proyecto_repetido: Cadena con nombre de un proyecto existente. Una cadena que contenga el mismo nombre que el de un proyecto ya existente, no son caracteres válidos para el nombre de un proyecto.
Como hemos visto en el manual de usuario, los escenarios son automatizados mediante Master Scripts (MS) que contienen las instrucciones de interacción con el Software Bajo Pruebas. Si las instrucciones en los diferentes escenarios son coincidentes, y sólo hay cambios en los datos utilizados por estos, dada las facilidades de la herramienta, sería buena práctica definir un solo Master Script para todos ellos. Cada escenario sería entonces ejecutado con el mismo juego de instrucciones pero proporcionándole datos de entrada salida diferentes, según se hayan descrito en los Casos de Prueba asociados. En la siguiente figura se ilustra cómo han sido automatizados cada uno de los escenarios.
Cada Caso de Prueba probará sólo un aspecto a tratar, por lo tanto cada caso contendrá una sola instrucción de validación.
Una vez añadidas todas las instrucciones en el MS que define cada escenario, es momento de especificar los posibles datos de entrada a través de la creación de un DTP. El mismo DTP puede ser utilizado por diferentes Escenarios, si ambos coinciden en cuanto a los datos necesarios. En la siguiente figura podemos observar el DTP creado para alimentar el primer escenario:
Tras asociar el DTP con cada escenario, asociamos cada instrucción de entrada con una de las variables del DTP, tras lo cual podemos generar los script de prueba automáticamente.
B) Actividad de Ejecución de Pruebas
El objetivo de esta actividad es ejecutar el conjunto de Scripts de pruebas obtenido anteriormente, para poder sacar conclusiones en la siguiente actividad OPSOA Análisis de Resultados. Primero se configurará la ejecución de la prueba, identificando que Casos de Prueba se van a ejecutar y posteriormente ejecutamos el conjunto seleccionado.
C) Actividad de Análisis de Resultados
Una vez generados todos los artefactos necesarios en las actividades anteriores, es turno de analizar los resultados obtenidos para completar la fase de pruebas. Ese es precisamente el objetivo de esta actividad, el análisis de los resultados existentes a fin de determinar el nivel de certificación del producto software.
En el presente punto sacaremos conclusiones de los resultados obtenidos en cada uno de los escenarios ejecutados, justificando los posibles errores hallados en la ejecución. Antes de comenzar a describir los conjuntos de pruebas, analizamos los datos de entrada que se definieron en el DTP, donde la información proporcionada se habría obtenido del documento de análisis funcional. Estos datos son analizados y construidos durante la Actividad de Generación de Pruebas de OPSOA. Los resultados de la ejecución se presentan en las siguiente figura.
