Anexo 10. Pruebas verificadas

1 Anexo 10. Pruebas verificadas Introducción El proceso de pruebas inició con una revisión conceptual para la identificación de las pruebas por reali

2 downloads 210 Views 344KB Size

Recommend Stories


ANEXO No. 10. Modelo de Contrato
ANEXO No. 10. Modelo de Contrato CONTRATO DE PRESTACIÓN DE SERVICIOS DE ASESORIA CELEBRADO ENTRE EL BANCO DE COMERCIO EXTERIOR DE COLOMBIA S.A. – BAN

ANEXO SNIP 10: PARÁMETROS DE EVALUACIÓN
Directiva General del Sistema Nacional de Inversión Pública Resolución Directoral N° 003-2011-EF/68.01 Anexo SNIP 10 ANEXO SNIP 10: PARÁMETROS DE EVA

Story Transcript

1

Anexo 10. Pruebas verificadas Introducción El proceso de pruebas inició con una revisión conceptual para la identificación de las pruebas por realizar, a partir de las características del proyecto. En el presente informe se encuentra descrito el proceso de pruebas desde su conceptualización, planificación, ejecución, hasta el análisis de resultados. A partir del resultado de la revisión se planificaron la realización de pruebas funcionales para la validación de los requisitos descritos en el informe de arquitectura; y pruebas de usabilidad para la validación de criterios de usabilidad para entornos virtuales 3D.

Conceptualización del proceso de pruebas El único instrumento adecuado para determinar el estatus de la calidad de un producto software es el proceso de pruebas. En este proceso se ejecutan pruebas dirigidas a componentes del software o al sistema de software en su totalidad, con el objetivo de medir el grado en que el software cumple con los requerimientos. En las pruebas se usan casos de prueba, especificados de forma estructurada mediante técnicas de prueba. El proceso de pruebas, sus objetivos y los métodos y técnicas usados se describen en el plan de prueba. (‘Pruebas de software’, 2005). Para la planeación de las pruebas que se van a aplicar a los componentes que se requieren implementar, se integraron distintos tipos de pruebas que se explicarán a continuación:

2

Pruebas de caja negra: estas pruebas se enfocan en los requerimientos establecidos y en la funcionalidad del sistema; no consideran la codificación dentro de sus parámetros por evaluar, es decir, no están basadas en el conocimiento del diseño interno del programa o sistema. Pruebas de caja blanca: estas se basan en el conocimiento de la lógica interna del código del sistema, contemplan los distintos caminos que se pueden generar gracias a las estructuras condicionales, a los distintos estados de este, etc. Pruebas de integración: las pruebas de integración buscan probar la combinación de las distintas partes de la aplicación para determinar si funcionan correctamente en conjunto. Pruebas del sistema: son similares a las pruebas de caja negra, solo que estas buscan probar el sistema como un todo. Están basadas en los requerimientos generales y abarcan todas las partes combinadas del sistema. Haciendo uso de las pruebas explicadas anteriormente, se definieron dos grupos con base en los cuales se van a definir los puntos por evaluar. Estos grupos son: Pruebas de funcionalidad: Este tipo de pruebas examina si el sistema cubre

sus

necesidades

de

funcionamiento,

acorde

con

las

especificaciones de diseño. En ellas se debe verificar si el sistema lleva a cabo correctamente todas las funciones requeridas, se debe verificar la validación de los datos y se deben realizar pruebas de comportamiento ante distintos escenarios. Estas pruebas deben estar enfocadas a tareas, a límites del sistema, a condiciones planeadas de error y de exploración. Para estas, usamos los esquemas de pruebas de caja negra, ya que nos interesa

3

saber si funciona o no, independientemente de la forma en que lo haga. Instrumentos por utilizar para realizar estas pruebas: casos de prueba.

Pruebas de usabilidad: estas pruebas tienen la finalidad de verificar que tan fácil de usar es un sistema, deben verificar aprendizaje (qué tan fácil es para los usuarios realizar tareas básicas la primera vez que tienen contacto con el sistema), eficiencia (una vez que los usuarios han aprendido algo del sistema, que tan rápido pueden llevar a cabo las tareas), manejo de errores (cuántos errores comete el usuario, qué tan graves son estos y qué tan fácil es para el usuario recuperarse de ellos) y grado de satisfacción. Para obtener resultados realistas en este tipo de pruebas, es importante dejar que las personas que están probando el sistema resuelvan los problemas que se les presentan por sí mismos, ya que si uno los ayuda, ya está contaminando las pruebas (Nielsen 03). Según Jacob Nielsen, para identificar los problemas más importantes de usabilidad de un sistema es suficiente con que lo prueben cinco personas (Nielsen 00).

Figura 1. Curva de crecimiento

4

Como podemos apreciar en la Figura 1, la curva de crecimiento es logarítmica. El porcentaje de problemas encontrados por las cinco primeras personas es de 80%, y después de estas, el crecimiento es ya muy poco. Instrumentos por utilizar para realizar estas pruebas: cuestionarios. Una vez definidas las pruebas, el siguiente paso es buscar a los usuarios que nos ayudarán a realizarlas. Los tipos de usuarios que se deben contemplar para este sistema son: Docentes y estudiantes: las pruebas que realizarían estos usuarios son de usabilidad. Desarrolladores: estos realizarán pruebas de funcionalidad.

Planificación A partir de la definición de los tipos de pruebas por realizar, se elaboró el ‘Plan global del proceso de pruebas’, en el cual se establecieron los cuestionarios y las listas de chequeo, especificados por categorías, y los criterios y escalas de valoración por utilizar en cada prueba.

Ejecución Las pruebas se ejecutaron en dos momentos: Durante el proceso de desarrollo: se validaron los requisitos funcionales de la plataforma tecnológica, a través de la cual se realizaron pruebas técnicas, en dos ciclos. El primero, verificando la completitud de los requisitos, y el segundo, verificando sólo aquellos

5

requisitos no alcanzados o incompletos y la corrección de los errores evidenciados en el primer ciclo. Cada una de las pruebas realizadas se registró como se muestra en la Tabla 1.

Tabla 1. Pruebas durante el proceso de desarrollo

Prueba

Fecha de ejecución de la prueba

Resultado (aprobado/ No aprobado/ Incompleto)

IP-LMS-01. Configuración general, módulo ‘Actividad A’

04/07/2011

Aprobado

IP-LMS-02. Actualización configuración general, módulo ‘Actividad A’

04/07/2011

Aprobado

IP-LMS-03. Eliminación módulo ‘Actividad A’

04/07/2011

Aprobado

IP-LMS-04. Configuración general, módulo ‘Actividad B’

04/07/2011

Aprobado

IP-LMS-05. Actualización configuración general, módulo ‘Actividad B’

04/07/2011

Aprobado

IP-LMS-06. Eliminación módulo ‘Actividad B’

04/07/2011

Aprobado

IP-LMS-07. Configuración general, módulo ‘Actividad C’

05/07/2011

Aprobado

Observaciones Generales

6

Prueba

Fecha de ejecución de la prueba

Resultado (aprobado/ No aprobado/ Incompleto)

IP-LMS-08. Actualización configuración ‘Actividad C’

05/07/2011

Aprobado

IP-LMS-09. Eliminación módulo ‘Actividad C’

05/07/2011

Aprobado

IP-LMS-10. Configuración de actividades para definir los parámetros para establecer la comunicación entre la plataforma (LMS) y el mundo virtual (MV3D)

09/07/2011

Aprobado

IP-LMS-11. Probar que la plataforma (LMS) permite hacer seguimiento a las actividades realizadas por los estudiantes

09/07/2011

Aprobado

IP-MV3D-01. Mensajero Visita

09/07/2011

Aprobado

IP-MV3D-02. Mensajero Interacción

09/07/2011

Aprobado

IP-MV3D-03. Mensajero Retroalimentación

09/07/2011

Aprobado

IP-MV3D-04. Mensajero Pregunta

16/07/2011

Aprobado

IP-MV3D-05. Registro de seguimiento

16/07/2011

Aprobado

IP-MV3D-06. Consulta de seguimiento

16/07/2011

Aprobado

Observaciones Generales

7

Prueba

Fecha de ejecución de la prueba

IP-REST-01. Log de visita, Log de interacción, Retroalimentación, Pregunta

16/07/2011

Resultado (aprobado/ No aprobado/ Incompleto)

Observaciones Generales

Aprobado

El resultado de la validación de cada ítem de cada prueba fue registrado, al igual que los defectos y/o errores encontrados. La segunda instancia de realización de pruebas se llevó a cabo al finalizar la aplicación del caso de estudio; aquí se hicieron pruebas de usabilidad realizadas por los docentes y estudiantes que interactuaron con la plataforma MV3D. Para estas pruebas se dispuso en la plataforma LMS (http://metaverso.udea.edu.co) el instrumento por aplicar y se invitó a los estudiantes y docentes participantes a diligenciar la evaluación respectiva, toda vez que hubiesen interactuado con el entorno virtual 3D.

Análisis de resultados Pruebas funcionales En la ¡Error! La autoreferencia al marcador no es válida. 2 se puede observar que el 100% de estas pruebas fueron aprobadas, esto quiere decir que al validar cada ítem de cada prueba en los componentes desarrollados se evidenció el cumplimiento del requisito funcional. Por lo anterior, se puede decir que los componentes desarrollados desde la perspectiva funcional cumplen con requisitos establecidos en el informe de arquitectura.

8

Tabla 2. Resumen de la aplicación de pruebas funcionales Listas de chequeo Categoría

Componentes para la plataforma (LMS) Componentes para el mundo virtual (MV3D) Componentes del servidor de recursos

Definidas

Ejecutadas

Aprobadas

11

11

11

6

6

6

1

1

1

Evaluación de usabilidad

Para la calificación de los ítems de las categorías de usabilidad evaluadas se utilizó una escala cualitativa (No se cumple, Insatisfecho, Aceptablemente satisfecho, Alto grado de satisfacción y Satisfacción plena); y a continuación se hace la correlación con una escala de calificación cuantitativa (1 a 5, siendo 5 el máximo valor de calificación, correspondiente a Satisfacción plena). En las conclusiones del análisis de resultados se sumaron los porcentajes de las calificaciones de 4 y 5, como criterio para determinar el grado de satisfacción de los usuarios que corresponde al horizonte de mayor satisfacción.

9

Tabla 3. Resultados de la evaluación de usabilidad, estudiantes Categoría

Grado de Satisfacción (%)

Exploración y orientación del MV3D

84,4%

Aspecto visual del MV3D

68,7%

Comunicación en el MV3D

87,5%

Interacción del MV3D

87,5%

Navegación en el MV3D

56,3%

Personalización de avatar del MV3D

100%

Documentación y ayuda del MV3D

79,2%

Satisfacción general con el MV3D

95,8% Promedio

86,25%

De los resultados de la Tabla 3 se puede concluir que el 86,25% de los estudiantes manifestaron un alto grado de satisfacción al usar el MV3D. Por lo anterior, se puede decir que el mundo virtual tridimensional implementado, desde la perspectiva de los estudiantes tiene un alto grado de usabilidad (Anexo 1. Análisis de resultados de la evaluación de usabilidad).

Tabla 4. Resultados de la evaluación de usabilidad, docentes Categoría

Grado de Satisfacción (%)

Exploración y orientación del MV3D

66,7%

Aspecto visual del MV3D

100%

Comunicación en el MV3D

83,3%

10

Interacción del MV3D

91,7%

Navegación en el MV3D

100%

Personalización de avatar del MV3D

100%

Documentación y ayuda del MV3D

33,3%

Satisfacción general con el MV3D

100% Promedio

84,4%

De los resultados de la

Tabla 4.4 se puede decir que el 84,4% de los docentes manifestaron un alto grado de satisfacción al usar el MV3D. Por lo anterior, se puede afirmar que el mundo virtual tridimensional implementado desde la perspectiva de los docentes tiene un alto grado de usabilidad (Anexo 1. Análisis de resultados de la evaluación de usabilidad).

Referencias ‘El plan de pruebas’ (2011) [en línea], disponible en , consultado: junio de 2011. ‘Pruebas de software’ (2005) [en línea], disponible en http://www.pruebasdesoftware.com/laspruebasdesoftware.htm, consultado: febrero de 2010.

Get in touch

Social

© Copyright 2013 - 2024 MYDOKUMENT.COM - All rights reserved.