Especificación y resultados de las pruebas de software

UNIVERSIDAD DE COSTA RICA
VICERRECTORÍA DE ACCIÓN SOCIAL
Extensión Docente
Observatorio del Desarrollo
SAEP PitA - SIRZEE
Especificación y Resultados de las Pruebas de Software
(borrador)
Elaborado por:
Carlos Andrés Méndez Rodríguez
Última Actualización 01-02-2013
Versión 01-02-2013

Ciudad Universitaria Rodrigo Facio, 01 febrero del 2013
CONTENIDOS

PREFACIO
Propósito
Audiencia

Documentos relacionados

I ESPECIFICACIÓN DE LOS CASOS DE PRUEBAS
1 Introducción
2 Pruebas de Funcionalidad
3 Pruebas de Desempeño
4 Pruebas de Seguridad
5 Pruebas de Usabilidad
6 Pruebas de Integración conceptual

II INFORME DE INCIDENTES (RESULTADOS)
7 Introducción
8 Pruebas de Funcionalidad
9 Pruebas de Desempeño
           10 Pruebas de Seguridad
           11 Pruebas de Usabilidad
           12 Pruebas de Integración conceptual

REFERENCIAS
GLOSARIO
ANEXOS

COLABORADORES

Participantes en la Prueba Piloto

Muchas personas colaboraron en la prueba piloto que se realizó en San Carlos para verificar
y validar el software SAEPPitA SIRZEE. A continuación se detallan los participantes:

Académicos participantes

Álvaro Fernández González, Observatorio del Desarrollo (OdD), UCR
Marlen Treviño, SIRZEE, ITCR

Colaboradores institucionales

UCR

Javier Vásquez, Escuela de Computación e Informática (ECCI)
Carlos Andrés Méndez Rodríguez, Escuela de Computación e Informática (ECCI)
Emma Tuk, consultora en gestión de residuos y educación.

ITCR

Andrés Guzmán, SIRZEE
Oscar Lopez, SIRZEE

Colegio Técnico Profesional Regional de San Carlos (COTAI, Ciudad Quesada)

Xinia Rodríguez Salazar, directora
Cándida García Gutiérrez, Matemática
Evelyn Vega Cruz, Estudios Sociales
Gladys Quirós Vargas, Español
Heidy Murillo Quesada
Oscar Mario Vargas, Agroecología

Liceo Experimental Bilingüe Los Ángeles (LEBLA, Fortuna)

Luis Alberto Rojas Bogantes, director
Adriana Villafuerte Villafuerte, Ciencias
Ivannia Santamaria Barrantes, Computación
Ronald Soto Céspedes, Español
Danny Porras Ramírez, Computación
William Chacón López, Matemática

PREFACIO

Propósito

Este documento tiene el propósito de especificar las pruebas que se realizaron (casos de
prueba) previo a la prueba piloto 2012 e informar los resultados (incidentes).

Las pruebas de software (adicionalmente ver documento Plan de Pruebas de Software [DR
4]) verifican el cumplimiento de los requerimientos funcionales y de calidad del software (ver
documento Especificación de Requerimientos de Software [DR 3]).

Audiencia

Tipo

Audiencia

Comité asesor

Profesores de la ECCI, equipo interuniversitario
Proyecto MOE-GAUR del OdD y equipo del
Proyecto Volcán del OdD.

Clientes

Comisión de Vicerrectores de Extensión y Acción
Social (CONARE), Departamento de Educación
en Salud y Ambiente (nivel central MEP),
asesores regionales de ciencias, estudios
sociales y cívica.

Desarrolladores del software

ITCR, SIRZEE

Instituciones participantes

- Universidad de Costa Rica: Observatorio del
Desarrollo (OdD)
- Instituto Tecnológico de Costa Rica: SIRZEE
- Ministerio de Educación Pública (MEP)

Administrador del sistema

ITCR, SIRZEE

Otros

Cualquier otra organización interesada en la
aplicación de sistemas de información para el
desarrollo local o software educativo.

Documentos relacionados

ID Ref Documento Descripción
1 http://code.google.com/p/saep-pita/do
wnloads/detail?name=Modelos%20para
%20el%20an%C3%A1lisis%20espacial%2
0de%20problemas-ODD-MEP-FO_D-SIRZ
EE.doc&can=2&q=

Modelos para el
análisis espacial de
problemas-ODD-MEP-
FO_D-SIRZEE

Es un documento que
describe un modelo
para el análisis
espacial de problemas.
Utilizado para
requerimientos del
sistema (SAEP SIR-ZEE
en San Carlos)
2 http://code.google.com/p/saep-pita/do
wnloads/detail?name=San%20Carlos%20
2010v2.docx&can=2&q=

San Carlos 2010 v2

Requerimientos del
SAEP-PitA en una
versión siguiente.
3 https://docs.google.com/document/d/
1KgAhvSOwn9hNRglzPUWSQ8IEeVf
opHZ3zSte6FkCjss/edit
Especificación de
Requerimientos
Software
Especificación más
reciente de
requerimientos
SAEP-PitA
4 https://docs.google.com/document/d/
1cE8GcoF3tm580PrXdZHy939mIlnF0
enidZS7IDeP5HE/edit
Plan de Pruebas de
Software
Documento pruebas
de sistema y pilotaje
del SAEP-PitA
5 https://docs.google.com/spreadsheet/
ccc?key=0ArY8yia97Bp0dHFyVmg0d
29vdnkxVzJTclJybVRZS3c#gid=0
Seguimiento Prueba
Piloto 2012
Bitácora diaria del
seguimiento y
acompañamiento a
docentes.
6 [DVD] Disponible en el Observatorio
del Desarrollo UCR
Videos de Taller 1, 2 y
3 (Capacitaciones y
presentación de
informes finales)
Tipo de archivo: .mp4
7 [DVD Informe SAEP SIRZEE 2012]
Disponible en el Observatorio del
Desarrollo UCR
Archivos de código
fuente del programa
“Foros y Comentarios”
y Respaldo de la Base
de Datos.
Archivos php,
javascript, html y sql.

II ESPECIFICACIÓN DE LOS CASOS DE PRUEBAS

1. Introducción

Este documento especifica los casos de prueba y el resultado obtenido de cada uno al
ejecutarlo. Los casos de prueba fueron diseñados conforme a las técnicas descritas en el
Plan de Pruebas de Software [DR 4]. A continuación se especifican las pruebas de
funcionalidad, seguridad, rendimiento, usabilidad e integración conceptual realizadas.

2. Pruebas de Funcionalidad

Prueba ID: 1
item: Creación de métricas
operación: crear una métrica
Precondición:
Conexión a internet desde un PC.
Estar registrado en el sistema.

Datos/Pasos a realizar:
Ingresar con Google Crome a http://www.sirzee.itcr.ac.cr/maep
Autenticarse en el sistema
Digitar un nombre a la métrica
Seleccionar en Categorías: Distritos

Seleccionar en Subcategorías: Información distrital
Seleccionar en Tema: Información distrital
Seleccionar en Características: Producción de Nance
Oprimir el botón “+”
Seleccionar en Subcategorías: Información distrital
Seleccionar en Tema: Información distrital
Seleccionar en Características: Producción de Tinte Azul
Oprimir “Crear”

Resultados esperados: Se devuelve un mensaje de confirmación y luego en el administrador
de métricas debe aparecer la nueva métrica.
Postcondiciones: Una nueva métrica en la base de datos.
Anexo 1:

Resultados obtenidos: Aprueba _X_ Falla __
Comentarios al ejecutar prueba: Se obtienen los resultados esperados.
Anexos:

Prueba ID: 2
Precondición:

Digitar el nombre a la métrica: “CantPapelRecXDistrito”
Seleccionar en Categorías: División Política
Seleccionar en Subcategorías: Distritos
Seleccionar en Tema: Distritos
Seleccionar en Características: Cantidad de Escuelas
Oprimir el botón “*”
Oprimir: “100”
Oprimir: “Crear”

Anexo 1:

Anexos:

Prueba ID: 3
Precondición:

Digitar el nombre a la métrica: “cantAguaReciclada”
Seleccionar en Características: Cantidad de Hoteles
Oprimir: “2”

Seleccionar en Características: Cantidad de Escuelas
Oprimir: “2”
Seleccionar en Características: Cantidad de Cabinas
Oprimir: “2”
Oprimir: Crear

Anexo 1:

Anexos:

Prueba ID: 4
Precondición:

Seleccionar en Categorías: Infraestructura
Seleccionar en Subcategorías: cualquier opción
Seleccionar en Tema: cualquier opción
Seleccionar en Características: cualquier opción

Resultados esperados: Al seleccionar entre las subcategorías, tema y características se va a
encontrar opción (es) para seleccionar. El caso de prueba debe fallar si el no hay opciones

para seleccionar.
Postcondiciones: ninguna.
Anexo 1:

Resultados obtenidos: Aprueba __ Falla _X_
Comentarios al ejecutar prueba: En características no hay opciones para seleccionar.
Anexos:

Prueba ID: 5
item: Administración de métricas
operación: mostrar métricas que han sido creadas.
Precondición:
Que existan algunas métricas creadas en el sistema.

Oprimir botón “Administrador de métricas” en menú general.

Resultados esperados: Se muestra una ventana con las métricas existentes con información
general como: nombre, fecha, autor, documento pdf y operaciones como eliminar, ejecutar y
modificar.

Anexo 1:

Anexos:

Prueba ID: 6
item: Ejecución de métricas
operación: ejecutar una métrica.
Precondición:
Que exista la métrica “prueba SIRZEE I” en el sistema.

Oprimir botón “Ejecutar” en la métrica “prueba SIRZEE I”.

Resultados esperados: Se muestra una ventana con los resultados de la métrica, la cual es
una información tabular por distrito de la Región Huetar Norte.

Anexo 1:

Anexos:

Prueba ID: 7
Precondición:
Que exista la métrica “cantPapelRecXDistrito” en el sistema.

Autenticarse en el sistema.
Oprimir botón “Ejecutar” en la métrica “cantPapelRecXDistrito”.
Corroborar los resultados obtenidos con los existentes en la BD (utilizando operador
“identifier”) y haciendo el cálculo manualmente “Distritos . Cantidad de Escuelas * 3”.


Anexo 1:

Anexos:

Prueba ID: 8
Precondición:
Que exista la métrica “cantAguaReciclada” en el sistema.

Oprimir botón “Ejecutar” en la métrica “cantAguaReciclada”.
“identifier”) y haciendo el cálculo manualmente “Distritos . Cantidad de Escuelas * 2 +
Distritos . Cantidad de Hoteles * 2 + Distritos . Cantidad de Cabinas * 2 ”.


Anexo 1:

Anexos:

Prueba ID: 9
Precondición:

Digitar el nombre a la métrica: “CantEmpaquesSint”
Seleccionar en Categorías: Información Distrital
Seleccionar en Subcategorías: Información Distrital
Seleccionar en Tema: Total de Población
Seleccionar en Características: Población 2000
Oprimir: “0.011”
Oprimir: “365”

Oprimir: “Crear”

Anexo 1:


Anexos:

Prueba ID: 10
Precondición:
Que exista la métrica “cantEmpaquesSint” en el sistema.

Oprimir botón “Ejecutar” en la métrica “cantEmpaquesSint”.
“identifier”) y haciendo el cálculo manualmente “Distritos . Información Distrital . Población
2000 * 0.011 * 365 ”.


Anexo 1:

Anexos:

Prueba ID: 11
item: Creación de componentes
operación: crear un contenedor.
Precondición:
Debe existir al menos 1 métrica guardada en el sistema.

Oprimir botón “Crear contenedor” en menú general.
Digitar un nombre
Seleccionar algún icono para visualizar en el mapa.
Seleccionar alguna métrica.
Oprimir “Crear Contenedor.

Resultados esperados: Se muestra un mensaje de confirmación y luego en el administrador
de contenedores podemos observar el nuevo contenedor.

Postcondiciones:Se agrega un nuevo contenedor a la BD.
Anexo 1:

Anexos:

Prueba ID: 12
item: Foros y comentarios
operación: crear un tema de discusión.
Precondición:
Debe existir al menos 1 contenedor guardado.

Oprimir botón “administrador de contenedores” en menú general.
Oprimir botón “ver comentarios” de algún contenedor.

Digitar descripción de nuevo tema de discusión.
Oprimir “Publicar tema”.

Resultados esperados: Se muestra un mensaje de confirmación y luego debe reflejarse el
nuevo tema a discutir en los foros de dicho contenedor.

Postcondiciones:Se agrega un nuevo tema a la BD.
Anexo 1:

Anexos:

Prueba ID: 13
item: Foros y comentarios
operación: crear comentarios.
Precondición:
Debe existir al menos 1 tema de discusión.

Oprimir botón “administrador de contenedores” en menú general.
Oprimir botón “ver comentarios” de algún contenedor.
Digitar algún comentario en un tema de discusión.
Oprimir “Publicar comentario”.

Resultados esperados: El nuevo comentario debe reflejarse el tema a discutir en los foros de
dicho contenedor.

Postcondiciones:Se agrega un nuevo comentario a la BD.
Anexo 1:

Anexos:

Prueba ID: 14
item: Subir Datos
operación: subir archivo de excel.
Precondición:
Estar registrado en el sistema como profesor.

Ingresar con Google Crome a
www.sirzee.itcr.ac.cr/modules/GIS/maep/htdocs/map_default.phtml?config=profesores
Oprimir botón “Subir datos” en menú general.
Seleccionar el archivo “economia_bambu.xls” que se adjunta.
Oprimir “Subir archivo”.
Ir al administrador de archivos y aprobar la solicitud del nuevo archivo a subir.
Ir a “Creación de métricas” para visualizar la nueva información.

Resultados esperados: Debe mostrarse un mensaje de confirmación que el archivo se sube
satisfactoriamente. Luego, una vez aprobado, en la ventana de “Creación de métricas” debe
visualizarse la nueva información: Categoría:Información Distrital, Subcategoría: Economia
Distrital, Tema: bambu, Propiedades: Hectareas_2000, Hectareas_2005 y Num_fincas.

Postcondiciones:Se agrega un nuevo tema y datos a la BD.
Anexo 1:

Anexos:

Prueba ID: 15
item: Administrador de métricas
operación: descargar un documento de una métrica.
Precondición:
Que exista una métrica con un documento pdf.


Buscar la métrica con el pdf.
Oprimir en el botón de descargar pdf.

Resultados esperados: Se muestra que el pdf es descargado.

Anexo 1:

Anexos:

Prueba ID: 16
item: Taller creación de componente
operación: crear un componente con archivo pdf adjunto.
Precondición:
Que exista alguna métrica en el sistema y tener un documento para subir menor a 1 MB.

Oprimir botón “TallerCreación de componentes” en menú general.
Poner el nombre “Prueba16”.
Seleccionar el archivo a subir.
Seleccionar un ícono.
Seleccionar una métrica.
Hacer click en el mapa para crear el componente transformador y ubicarlo en el mapa.

Resultados esperados: Se muestra un mensaje de creación satisfactoria. Luego en el
administrador de archivos existe el componente “prueba16” y tiene asociado una métrica y
tiene un documento para descargar.

Anexo 1:

Comentarios al ejecutar prueba: Se creó el componente, sin embargo el documento pdf no se
visualiza.

Anexos:

Prueba ID: 17
item: Sistema de puntuación
operación: Agregar automáticamente puntos al crear un componente.
Precondición:

Anotar los puntos del equipo al que pertenece el usuario.
Crear una métrica.
Oprimir el botón “Sistema de puntuación”.

Resultados esperados: Los puntos se incrementaron para el equipo al que pertenece el
usuario.

Anexo 1:

Anexos:

Prueba ID: 18
item: Métricas
operación: Ejecutar métrica con operación mínimo
Precondición:

Poner un nombre a la métrica.
Crear la siguiente métrica: Min(2 , 9 , 8)
Nota: oprimir los botones de la interfaz en lugar del teclado.
Oprimir el botón “Crear métrica”.
Revisar el administrador de métricas y ejecutar la métrica.

Resultados esperados: La ejecución de la métrica muestra que el resultado es un “2”.
Postcondiciones: existe una nueva métrica en el sistema utilizando operación <<mínimo>>.
Anexo 1:

Comentarios al ejecutar prueba: El resultado es correcto ya que se muestra “2”, sin embargo
no tiene semántica pues se muestra una tabla con distritos con el mismo resultado para
todos. Ver siguiente anexo.

Anexos:

3. Pruebas de Rendimiento

Prueba ID: 1
item: Aplicación completa
operación: cargar aplicación en explorador de internet
Precondición:
Conexión a internet desde un PC 100 Mb/s.

Oprimir Enter en teclado
Contar los segundos hasta que la aplicación se cargue completamente. (La barra de proceso
muestra finalización)

Resultados esperados: El sistema se carga en no menos de 30 segundos.
Anexo 1:

Comentarios al ejecutar prueba: Se obtienen los resultados esperados. La aplicación finaliza
la carga a los 12 segundos.
Anexos:

4. Pruebas de Seguridad

Prueba ID: 1
item: Autenticación
operación: autenticarse en el sistema
Precondición:
Estar registrado en el sistema

Oprimir el botón de login/ingreso
Digitar el usuario y contraseña

Resultados esperados: El sistema envía un mensaje de confirmación y muestra las opciones
que el usuario tiene privilegio.

Anexo 1:

Anexos:

Prueba ID: 2
Precondición:


Digitar el usuario (válido) y una contraseña (inválida)

Resultados esperados: El sistema envía un mensaje de error para que el usuario intente de
nuevo. Además, el nombre de usuario vuelve a visualizarse para que el usuario lo verifique y
la contraseña está oculta. El usuario no queda autenticado.

Anexo 1:

Comentarios al ejecutar prueba: No se obtienen los resultados esperados. El nombre de
usuario y la contraseña se visualizan en la URL.

Anexos:

Prueba ID: 3
Precondición:

Digitar el usuario inválido y una contraseña inválida.

Resultados esperados: El sistema envía un mensaje de error para que el usuario intente de
nuevo. El usuario no queda autenticado y no visualiza más opciones.

Anexo 1:

Anexos:

Prueba ID: 4
Precondición:

Digitar el usuario inválido y una contraseña inválida.

Resultados esperados: El sistema muestra al usuario que ha sido autenticado y le permite
visualizar más opciones.

Anexo 1:

Comentarios al ejecutar prueba: La prueba falla ya que, a pesar de que el usuario puede
visualizar más opciones, el visor de mapa deja de funcionar.

Anexos:

Prueba ID: 5
operación: registrarse y autenticarse en el sistema como profesor
Precondición:


Registrarse en el sistema.
Salir del sistema.
Ingresar con Google Crome a:
www.sirzee.itcr.ac.cr/modules/GIS/maep/htdocs/map_default.phtml?config=profesores
Autenticarse.

Resultados esperados: El sistema muestra al usuario un mensaje que no se puede autenticar
como profesor y le indica solicitar al administrador los permisos. No obstante, le hace ver que
se ha autenticado como estudiante.

Anexo 1:

Comentarios al ejecutar prueba: La prueba falla ya que, tal como se muestra en las
imágenes, se pudo lograr ingresar al perfil de profesor sin necesidad de solicitar los
privilegios.

Anexos

5. Pruebas de Usabilidad

Una de las propiedades cualitativas más importantes que debe cumplir hoy día un software,
especialmente cuando está dirigido a un público meta muy grande, es la usabilidad. En la
actualidad se hace un esfuerzo para desarrollar técnicas de medición o calificación de los

factores claves en la usabilidad. Sin embargo, esto es aún un asunto subjetivo.

A continuación se revisarán unas preguntas heurísticas que Myers y Jakob Nielsen crearon
para el análisis de la usabilidad en los sistemas informáticos. Luego, con el simple método de
conteo, evaluaremos el grado de cumplimiento de estas heurísticas.

5.1 Heurísticas de Myers

1. ¿Cada interfaz ha sido adaptada para las bases educativas y presiones de
ambiente del usuario final?

De los 17 usuarios (9 profesores y 8 estudiantes) sólo dos tenían pocas bases en el
uso de la computadora y todos tenían una alta presión en sus ambientes laborales y
educativos.

Entonces, sólo en 2 de 17 usuarios requerirían más tiempo para la revisión de
interfaces, documentación y manual del usuario.

Por lo tanto, se concluye que el 88% de los usuarios tienen la interfaz adaptada a sus
bases educativas y presiones de ambiente.

2. ¿Las salidas del programa son significativas, no abusivas y vacío de códigos
de programación?

Inicialmente el sistema contaba con conceptos que el usuario podría no comprender
bien tales como “métricas”, pero se corrigieron oportunamente. Por lo tanto, se puede decir
que el sistema también cumple con este aspecto.

3. ¿El diagnóstico de los errores, como los mensajes de error, son
comprensibles o el usuario necesita un PhD en computación para entenderlos?

No se encontraron mensajes de error poco comprensibles al usuario. Sólo al crear un
contenedor el sistema tira un mensaje “Ocurrió un error a la hora de guardar el contenedor”,
esto a pesar de que sí se guarda exitosamente.

4. ¿Exhibe el total de interfaces integridad conceptual, consistencia, sintaxis
uniforme, convenciones, semánticas, formatos, estilo y abreviaciones?

Si un usuario no pertenece a un equipo, entonces no podía crear métricas. Esto
dificultó la dinámica de práctica cuando aún no estaban creados los equipos de trabajo, o
compañeros aún no estaban incorporados.

La opinión de un estudiante respecto los equipos de trabajo y usuarios es:

“Es muy bueno, pero tiene un problema, que si uno no esta en algun grupo de trabajo no puede crear las
métricas” (Jarol 03/12/12)

Por otra parte, en algunas ocasiones al crear una métrica, cuando se selecciona una
categoría y luego una subcategoría, no existen opciones para el tema.

5. ¿Cuando la exactitud es vital, como en los sistemas online bancarios, existe
suficiente redundancia presente en la salida?

Algunos mensajes de notificación no son muy claros pues se ubican en una zona
alejada. Esto es al crear una métrica, crear un contenedor (tira un mensaje de error que no
debería) y registro de usuario.

6. ¿El sistema contiene un excesivo número de opciones que casi no se usan?

Afirmativo, en la siguiente imagen observamos un menú general tiene 22 opciones en
su primer y único nivel. Las opciones que casi no se utilizaron son: Visualización completa,
zoom a la selección, seleccionar, autoidentificar, adicionar un punto de interés, contacto,
descargar e imprimir.

Además, en la siguiente imagen observamos el panel de capas geográficas. Por los
ejercicios que los profesores y estudiantes realizaron (guardados en el sistema y en
documentación externa), podemos decir que no se utiliza más del 10% de estas capas de
información.

Imagen: Capas de Datos

7. ¿El sistema ofrece al usuario algún tipo de conocimiento en todas las
solicitudes? Por ejemplo, ¿cuando se hace click a una entrada de datos, el color
cambia o se habilita algún botón?

No se encontraron debilidades en este aspecto.

8. ¿Es el programa fácil de usar, por ejemplo, si hay navegación a través de
menús, puede el usuario fácilmente cambiarse de nivel?

Abrir un componente no se puede realizar desde el visor del mapa (en los iconos),
sólo se puede desde la ventana del administrador de componentes.

Sólo seleccionando la herramienta identificar o autoidentificar es que el sistema
ofrece información de una geometría tipo punto en el mapa. Esto contrasta con el sistema por
ejemplo de google maps.

Sólo seleccionando la herramienta Mover es que el sistema permite al usuario
navegar en el mapa. Esto contrasta con el sistema por ejemplo de google maps que acepta
la operación de “arrastrar” en el mouse.

El scroll del mouse permite hacer zoom in y zoom out, sin embargo está al revés de
los GIS más populares, lo que puede incomodar al usuario.

Insertar números al crear una métrica sólo se puede realizar oprimiendo los botones
de la interfaz y no del teclado del computador. Comentarios de estudiantes al respecto sobre
las métricas son:

“Está bien pero quizás se debe ser muy estricto a la hora de hacer el cálculo ya que los elementos deben
ser los que posee y los números sólo se pueden digitar dando click” (Anthony 31212)

“Es una muy buena opcion, pero en algunas ocaciones es complicado elaborarlas” (Jarol 031212)

El manual al usuario es más difícil de usar cuando dentro del pdf no hay enlaces.
Asimismo, se encuentra entre los usuarios que el manual es muy teórico y se prefiere algo
más práctico y dinámico.

5.3 Heurísticas de Usabilidad de Nielsen

1. La visibilidad del estado de la página.

En la página de inicio se presenta el visor de mapa. Sin embargo, no se le indica al
usuario de que se encuentra en dicha página de inicio/home.

Asimismo, en la sección de Registro de Personas no se visualiza el estado, ni se
puede deshacer la operación. Esto debido a que oprimo el botón “Atrás” no ocurre nada.

2. Utilizar el lenguaje de los usuarios.

Los términos “Administrador de Componentes” y “Administrador de Métricas” fueron
difíciles de explicar al usuario.

3. El control y libertad del usuario.

No se encontraron oportunidades de mejora de este tipo.

4. La consistencia y cumplimiento de estándares .

El scroll del mouse permite hacer zoom in y zoom out, sin embargo está al revés de
los GIS más populares, lo que puede incomodar al usuario.

La opción de salir y configuración del perfil de usuario normalmente se ubican en la
parte superior derecha del sitio.

5. La prevención de errores.

Tal como se visualiza en la imagen de Registro de Personas, no se le indica al
usuario en qué formato digitar la cédula (Ej 11111100).

6. Minimizar la carga de la memoria del usuario.

El usuario necesita recordar el nombre de la métrica creada para luego poder ir a la
ventana de administración de métricas, buscarla y ejecutarla.

El usuario debe estar recordando la funcionalidad de cada ícono. A pesar de que al
sobreponer el mouse en los íconos se da información, esta información dura 1 segundo y
hace esperar al usuario.

7. La flexibilidad y eficiencia de uso.

El buscador dentro de la ventana de métricas y componentes es una muy buena
eficiencia de uso.

No se ofrece al usuario el uso de “Breadcrumbs” como mecanismo para llegar
rápidamente a un área ya visitada dentro del sitio. Además, le serviría para ubicarse dentro
del sitio y conocer la relación jerárquica con el resto del sistema.

8. La estética y diseño minimalista.

Se ha encontrado entre las entrevistas a los usuarios que la interfaz está muy cargada
de elementos. Existen muchos iconos y algunos casi no se usan.

9. La ayuda ante errores.

No se encontraron mensajes de error poco comprensibles al usuario. Sólo al crear un
contenedor el sistema tira un mensaje “Ocurrió un error a la hora de guardar el contenedor”,
esto a pesar de que sí se guarda exitosamente.

10.La ayuda y documentación.

El manual del usuario o ayuda del sistema no cuenta con glosario y preguntas
frecuentes. Tampoco información general del sitio, misión, visión, entre otros. Además,en el
pdf no hay enlaces o buscador para dirigir rápidamente al usuario.

Un comentario al panel de las capa de datos “Al sistema hay que agregarle instrucciones,
división política se basa en … y ahí va encontrar … por ser tan metódicos necesitamos
instrumentos o guías” (Adriana video 00401)

6. Pruebas de integración conceptual

Las pruebas de integración conceptual verifican que exista una correspondencia entre los

elementos del MAEP y el SAEP. Los usuarios finales del software deben percibir una
analogía entre su enfoque conceptualteórico y lo concretado en el software.

En seguida, se realizarán pruebas de software que el mismo modelo MAEP sugiere y
posteriormente un análisis comparativo de los componentes de transformación.

6.1 Pruebas que debe satisfacer el producto de software

A continuación se toma el documento Modelos para el análisis espacial de
problemasODDMEPFO_DSIRZEE [DR 1] y se verifican las pruebas que se solicitan en la
sección 7.D. Se asigna un 1 cuando se observa que se cumple y 0 cuando no.

ID Operación Se observa en el
SAEP
1 Creación de componentes de datos 1
2 Actualización de componentes de datos 0
3 Consulta de componentes de datos 1
4 Eliminación de componentes de datos 0
5 Permitir el almacenamiento de datos generados por la
plataforma de juegos.
1
6 Creación de componentes de transformación 1
7 Actualización de componentes de transformación 0
8 Consulta de componentes de transformación 1
9 Eliminación de componentes de transformación 1
10 Consulta de datos en los componentes de transformación 1
11 Actualización de datos en los componentes de
transformación
1
12 Eliminación de datos en los componentes de
transformación
1
13 Permitir el ensamblaje de componentes. 0
14 Permitir el anidamiento de componentes. 1
15 Permitir la importación/exportación de componentes. 0

16 Permitir el guardado y cargado de componentes 1
17 Creación de componentes de ambientes 1
18 Actualización de componentes de ambientes 0
19 Consulta de componentes de ambientes 1
20 Eliminación de componentes de ambientes 1
21 Permitir la generación de simulaciones de interacciones
entre componentes en un intervalo de tiempo dado.
0
Total 14

Contando las pruebas aprobadas nos da un total de 14. Esto es indicador de que 66% del
modelo MAEP es reflejado en el SAEP.

6.2. Conceptos computacionales que se pueden reforzar en secundaria mediante el
Maep.

A continuación se enlistan los conceptos que se pudo reforzar en secundaria mediante el
MAEP. Igual, esto corresponde al documento Modelos para el análisis espacial de
problemasODDMEPFO_DSIRZEE [DR 1] de la sección 9. Sin embargo, puede notarse
que son muy pocos los conceptos que los estudiantes reforzaron mediante el uso del SAEP y
la guía didáctica.

Cuadro N. Lista de conceptos de Sección 9 del MAEP

1. Programación orientada a objetos
a. Clase
b. Objeto
c. Instancia
d. Herencia
e. Polimorfismo
f. Delegación
g. Abstracción—Encapsulación
h. Atributo
i. Método
j. Parámetro
2. Ensamble de objetos (relaciones de asociación, composición)

3. Programación procedimental
a. Asignación

b. Ejecución condicional
c. Ciclo de repetición
d. Entrada – salida de datos

4. Otros conceptos
a. Trabajo en equipo
b. Diseño iterativo
c. Diseño incremental
d. Servicio web
e. Pizarra
f. Chat
g. Blog
5. Foro
6. Estructuras de datos
7. Tablas y Bases de Datos
8. Llave
9. Integridad referencial
10. Capa de un SIG

Los conceptos que se lograron reforzar son los siguientes: Atributo, Ejecución condicional,
EntradaSalida de datos, Trabajo en equipo, Diseño incremental, Servicio Web, Foro, Tablas
y Bases de Datos y Capa de un SIG.

Resultado: 9/27 conceptos. Es decir, un 33,3% del total de conceptos propuestos en el
MAEP.

6.3 Análisis comparativo de los componentes de transformación

A continuación realizamos análisis comparativo de uno de los principales elementos del
MAEP y su reflejo en el SAEP: los componentes de transformación como actores sociales.

En el siguiente cuadro de comparación observamos el modelador de entornos:

Modelo MAEP Software SAEP

A continuación comparamos cómo se integran (anidación) los componentes transformadores
en el MAEP y en el SAEP:

Modelo MAEP Software SAEP

Taller en MAEP para integrar componentes:

Taller en SAEP para integrar componentes:

Ventana para crear componentes:

Integración de componentes por medio de
anidación de métricas:

En el caso del MAEP se observa que los componentes de transformación se integran unos
con otros mediante sus interfaces de entrada y salida. En el caso del SAEP, la integración se
realiza mediante la anidación de métricas.

Quizá de lo anterior podemos concientizar que:

1. El modelador de entornos del MAEP se refleja en el SAEP muy bien, debido a que los
componentes de transformación se pueden ubicar espacialmente, además en el SAEP se

visualiza un mapa real (lo cuál lo hace interesante y útil para otros fines).

2. En el modelo MAEP, en el Taller, no se especifica cómo los componentes de
transformación van a realizar este proceso ni en qué magnitudes, pues sólo se tratan de
“cajas negras” con entradas y salidas que se conectan con drag and drop. A diferencia, en el
SAEP el usuario sí debe especificar el proceso de transformación (mediante el archivo pdf) y
en qué magnitudes (creando una métrica).

3. El usuario final puede encontrar conceptualmente más fácil la integración de componentes
en el MAEP que en el SAEP, esto debido a que:
En el taller, en el MAEP la asignación de fórmulas no se visualiza o es secundario. En el
SAEP, para crear anidación es obligatorio la selección de fórmulas.
La interfaz gráfica del taller de los componentes transformadores en el SAEP, no aclara al
usuario que de lo que se trata es integrar componentes.
Los gráficos de integración de componentes del MAEP son muy intuitivos.

II INFORME DE INCIDENTES (RESULTADOS)

7. Introducción

A continuación se realiza un resumen de los resultados obtenidos al ejecutar las pruebas de
software. Se incluyen los casos de prueba especificados por los testers, así como lo
manifestado por los usuarios finales de la prueba piloto.

8. Pruebas de Funcionalidad

Las pruebas de funcionalidad no es más que la verificación del cumplimiento de los
requerimientos funcionales estipulados entre el ITCR y la UCR (ver documento [DR 3]). En el
gráfico N8 se muestra el porcentaje de pruebas de funcionalidad que fueron aprobadas y
falladas.

Gráfico N8: Porcentaje de pruebas de funcionalidad aprobadas y fallidas.

FUENTE: Elaboración propia con base en los resultados obtenidos de las pruebas

El grado anterior indica que un 83% de las pruebas de funcionalidad arrojaron los resultados
esperados. Se observa en el cuadro N8 los componentes de software y las operaciones que
se ejecutaron que pasaron o fallaron la prueba.

Cuadro N8: Resumen de componentes de software probados y sus resultados.

ID Componente de software operación Aprobada/
Fallida

1 Métricas creación 1
5 Administración de Métricas mostrar 1
6 Administración de Métricas ejecución 1
11 Taller de Componentes creación 1
12 Foros y comentarios crear tema 1
13 Foros y comentarios crear comentario 1
14 Subir datos subir excel 1
15 Administración de Métricas descargar pdf 1
16 Taller de Componentes adjuntar pdf 0
17 Sistema de puntuación agregar puntos 1
18 Métricas ejecutar 0
total 15 / 18

9. Pruebas de Desempeño

Durante el pilotaje se observó que el tiempo de duración de ejecución de las diferentes
operaciones se encontraban en un tiempo no mayor a los 30 segundos. Asimismo, los
usuarios no externaron disconformidad en esto.

10. Pruebas de Seguridad

Las pruebas de seguridad verifican que los estudiantes no tengan privilegios de profesor, que
las contraseñas no sean accedidas por los usuarios, entre otros aspectos. A continuación en
el gráfico 10, se muestra el porcentaje de pruebas de seguridad que se aprobaron y las que
no.

Gráfico 10. Porcentaje de Pruebas de Seguridad Aprobadas y Fallidas

FUENTE: Elaboración propia con base en los resultados obtenidos de las pruebas.

11. Pruebas de Usabilidad
El análisis cuantitativo de la usabilidad de un sistema informático es aún algo complicado de
realizar. Por lo tanto, se aplicaron las heurísticas de Myers y Nielsen, y a continuación
presentamos los resultados obtenidos.

11.1 Resultados en las Heurísticas de Usabilidad de Myers

Si a cada pregunta heurística de Myers le asignamos un 1 o un 0, donde un 1 significa que el
sistema cumple con dicho aspecto y un 0 que no lo cumple en alguna medida; podemos
tener el siguiente resultado:

# Pregunta (no) Cumple valor
1 sí 1
2 sí 1

3 sí 1
4 no 0
5 no 0
6 no 0
7 sí 1
8 no 0

Total 4/8

Un 4 de 8 significa el cumplimiento de un 50% de las preguntas.

Ahora, seleccionando la posición media de la siguiente escala:

Muy buena, buena, regular, mala, Muy mala

Por lo tanto, el sistema tiene una usabilidad regular.

11.2 Resultados en las Heurísticas de Usabilidad de Nielsen

Con el apoyo de las diez heurísticas de Nielsen (excepto la número 3) se lograron encontrar
oportunidades de mejora.

11.3 Conclusión Pruebas de Usabilidad

Aunque resulta subjetivo medir el grado de usabilidad del sistema, el método de conteo de la
lista de chequeo de las heurísticas de Myers y Jakob Nielsen, indican que el sistema tiene
una usabilidad regular. En definitiva, uno de los elementos que hay que mejorar es en la
creación de métricas.

12. Resultados de las pruebas de integración conceptual

Las pruebas de software sugeridas en el documento Modelos para el análisis espacial de
problemasODDMEPFO_DSIRZEE [DR 1] de la sección 7.D. se aprueban en un 66%.

El porcentaje de conceptos propuestos en el mismo documento [DR 1] en la sección 9 que se
logran reforzar con los estudiantes es un 33,3%.

Finalmente, realizando análisis comparativo entre el MAEP y el SAEP, en lo que respecta a
componentes de transformación, se encuentra que es más fácil comprender el concepto de
integración (anidación) de componentes en el MAEP que en el SAEP. Cabe advertir, que
debido a que se realizó análisis cualitativo, esta apreciación no se logra cuantificar.

REFERENCIAS

[1] Kaner, Cem; Falk, Jack; Nguyen, Hung Q. Testing Computer Software. 2d ed., John Wiley
& Sons, 1999.
[2] IEEE Computer Society. IEEE Std 610.12.1990 Standard Glossary of Software
Engineering Terminology. 1990.
[3] Lewis, William. Software Testing and Continous Quality Improvement. 3rd ed, CRC Press,
2009.
[4] Myers, Glenford J. The Art of Software Testing. WileyInterscience,1979.

GLOSARIO

Caso de prueba “A set of test inputs, execution conditions,
and expected results developed for a
particular objetive, such as to exercise a
particular program path or to verify
compliance with a specific requirement”
IEEE (Std 610.121990). “Es un conjunto de
datos de entrada y resultados esperados
que ejercitan a un componente con el
propósito de causar fallas y detectar
errores” Bruegge.
Pruebas de Aceptación “Formal testing conducted to enable a user,
customer, or other authorized entity to
determine whether to accept a system or
component” IEEE (Std 610.121990).
“Measures how the final system meets
users’ expectations” Pezze & Young (2007).
Pruebas de Sistema Prueban todos los componentes de software
juntos, vistos como un solo sistema, para
identificar errores en el comportamiento del
sistema respecto a la especificación de

requerimientos funcionales y no funcionales.
Según Bruegge, pueden incluir pruebas
funcionales, de desempeño, piloto y de
aceptación.
Pruebas de Software “A set of activities designed to evaluate the
quality of development or manufactured
products” IEEE (Std 610.121990). “El
proceso de encontrar errores” Kaner (1999).
“Planning, design, building, maintaining, and
executing tests and test environments. A
risk management strategy. Includes
verification and validation activities” Lewis
(2009).
Prueba piloto “Prueba de la funcionalidad común entre un
grupo seleccionado de usuarios finales en el
ambiente de destino” Bruegge.
Pruebas de usabilidad Pruebas que determinan qué tan bien el
usuario va poder utilizar y comprender el
software. Algunos componentes que son
evaluados son la pantalla, los colores, el
formato, los campos de entrada, el flujo del
programa, la ortografía, entre otros.
Validación: “Evaluar el grado en el que el software
realmente satisface las necesidades reales
del usuario” Pezze & Young (2008)
Verificación “Checking the consistency of an
implementation with a specification” Pezze &
Young (2008).

ANEXOS

Anexo 1. Documento Cuestionario de Evaluación para estudiantes y profesores

Documento Cuestionario de Evaluación

SAEPPitA SIRZEE Evaluación del 1 al 10 donde 1 es la nota más baja y el 10 la más alta. NA si no
sabe o no desea contestar. Puede agregar algún comentario (opcional)
Ventana Principal (Visor de Mapa) Nota ( ) Cometario___________________________________
Login de Usuarios Nota ( ) Cometario___________________________________
Registro de Personas Nota ( ) Cometario___________________________________
Creación de equipos de trabajo Nota ( ) Cometario___________________________________
Formulario de Contacto Nota ( ) Cometario___________________________________
Ayuda del sistema (Manual del usuario) Nota ( ) Cometario______________________________
Creación de Componentes Nota ( ) Cometario___________________________________
Ejecutar fórmulas Nota ( ) Cometario___________________________________
Creación de fórmulas Nota ( ) Cometario___________________________________
Administración de componentes Nota ( ) Cometario__________________________________
Administración de fórmulas Nota ( ) Cometario___________________________________
Modificar fórmulas Nota ( ) Cometario___________________________________
Subir datos Nota ( ) Cometario___________________________________
Administrar Archivos Nota ( ) Cometario___________________________________
Sistema de Puntajes Nota ( ) Cometario___________________________________
Crear una Categoría Nota ( ) Cometario___________________________________
Agregar Subcategorías Nota ( ) Cometario___________________________________
Modificar Equipos de trabajo. Nota ( ) Cometario___________________________________

Un software ideal qué debería tener para realizar análisis ó simulación en gestión ambiental

En cuáles proyectos del colegio considera que el SAEPPitA ser utilizado como herramienta
(quiénes serían los usuarios):

Qué datos desearía subir al sistema y compartir a la comunidad:

Qué datos deberían ser de carácter público o privado a nivel del equipo del colegio:

Cualquier otro comentario para mejorar:

Especificación y resultados de las pruebas de software

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (14)

Ähnlich wie Especificación y resultados de las pruebas de software

Ähnlich wie Especificación y resultados de las pruebas de software (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Especificación y resultados de las pruebas de software