UNIVERSIDAD DE COSTA RICA VICERRECTORA DE ACCIN SOCIAL Extensin Docente Observatorio del Desarrollo

SAEP PitA - SIRZEE

Plan de Pruebas de Software
Elaborado por:

Carlos Andrs Mndez Rodrguez

ltima Actualizacin Versin

01-02-2012 01-02-2012

Ciudad Universitaria Rodrigo Facio, 01 febrero del 2012

CONTENIDOS
PREFACIO Propsito Audiencia PLAN DE PRUEBAS DE SOFTWARE 1 Identificador del plan de pruebas 2 Introduccin 2.1 Objetivos

2.2 Antecedentes 2.3 Alcance 2.4 Referencias 3 Itemes de prueba 4 Caractersticas que se probaran 5 Caractersticas que no se probaran 6 Enfoque 7 Criterios para pasar o fallar un tem de prueba 8 Criterios para suspender las pruebas y requerimientos de reanudacin 9 Criterio para terminar las pruebas 10 Entregables de pruebas 11 Tareas de pruebas 12 Necesidades de ambiente 13 Responsabilidades 14 Personal y necesidades de capacitacin 15 Horario 16 Riesgos y contingencias 17 Aprobaciones REFERENCIAS GLOSARIO ANEXOS

COLABORADORES
Participantes en la Prueba Piloto
Muchas personas forman parte de la prueba piloto que se realiza en San Carlos para verificar y validar la calidad del software SAEP-PitA. A continuacin se detallan los participantes. Acadmicos participantes lvaro Fernndez Gonzlez, Observatorio del Desarrollo (OdD), UCR Marlen Trevio, SIRZEE, ITCR

Colaboradores institucionales UCR Javier Vsquez, Escuela de Computacin e Informtica (ECCI) Carlos Andrs Mndez Rodrguez, Escuela de Computacin e Informtica (ECCI) Emma Tuk, consultora en gestin de residuos y educacin. ITCR Andrs Guzmn, SIRZEE Roco Quirs: prctica de especialidad, Escuela de Computacin, Sede Santa Clara. Oscar Lopez, SIRZEE MEP Andrs Rodrguez, asesor nacional, Programa Nacional de Informtica Educativa Karla Quesada, asesora regional, Programa Nacional de Informtica Educativa, Direccin Regional de Educacin de San Carlos. Walter Mora, Jefe de Asesora Pedaggica de la Regional de Educacin de San Carlos. Natalia Rojas, profesora de Informtica Educativa, Colegio Teodoro Picado, Alajuelita.

PREFACIO
Propsito
Este documento tiene el propsito de definir un plan de pruebas para el desarrollo del software SAEP-PitA SIRZEE e implementarlo durante todo el ao 2012. Las pruebas de software verifican el cumplimiento de los requerimientos que fueron estipulados entre el cliente y los ingenieros de software. Adems, validan si el software se adapta a las necesidades de los usuarios. En este documento Plan de Pruebas, se definen los objetivos, estrategias, criterios, calendario y dems aspectos del plan estratgico.

Audiencia

El documento es especialmente creado y actualizado para los ejecutores de pruebas de software, no obstante cualquier parte interesada en el desarrollo del software puede accesarlo para conocer el plan de pruebas. A continuacin se ilustran posibles interesados:

Tipo

Audiencia

Comit asesor

Profesores de la ECCI, equipo interuniversitario Proyecto MOE-GAUR del OdD y equipo del Proyecto Volcn del OdD.

Clientes

Comisin de Vicerrectores de Extensin y Accin Social (CONARE), Departamento de Educacin en Salud y Ambiente (nivel central MEP), asesores regionales de ciencias, estudios sociales y cvica.

Desarrolladores del software

ITCR, SIRZEE

Instituciones participantes

- Universidad de Costa Rica: Observatorio del Desarrollo (OdD) - Instituto Tecnolgico de Costa Rica: SIRZEE - Ministerio de Educacin Pblica (MEP)

Administrador del sistema

ITCR, SIRZEE

Otros

Cualquier otra organizacin interesada en la aplicacin de sistemas de informacin para el desarrollo local o software educativo.

PLAN DE PRUEBAS DE SOFTWARE 1. Identificador del plan de pruebas

Versin 01-02-2012

2. Introduccin
Desde finales del 2009, el software SAEP-PitA SIRZEE se ha estado desarrollado con el esfuerzo de muchos participantes de varias instituciones, tiene un pblico meta bastante amplio y se espera que se pueda ampliar en complejidad para su uso en contextos ms amplios. Adems, se est adaptando a la plataforma del Sistema de Informacin Regional (SIR) de la Zona Econmica Especial (ZEE) Regin Huetar Norte; el cual es de suma importancia para el desarrollo de dicha regin. Por lo anterior es en definitiva, de mucho inters poder contar con un proceso de aseguramiento de la calidad del software y alcanzar los objetivos del proyecto. La definicin de este plan de pruebas se realiza en el contexto de los inicios del 2012. El ITCR tiene a cargo principalmente la programacin de software y la UCR la implementacin de este

plan de pruebas bajo la metodologa de desarrollo espiral. Tal como se muestra en la siguiente imagen se compone de fases: Lnea de tiempo: Fases de desarrollo de software 2012 Especificacin de Requerimientos Programacin SAEP Pruebas de Sistema _________________________________ | Prueba Piloto ___________________________| | |Talleres 1 y 2 Taller 3 |

| Febrero

| Julio

| Diciembre

Para la prueba piloto se tiene la colaboracin de tres colegios en San Carlos y Fortuna. Se estar realizando dos talleres para capacitar a profesores y estudiantes y luego analizar su interaccin con el sistema. Adems, en el transcurso del semestre, los profesores realizarn sesiones con los estudiantes, siguiendo un cronograma y gua didctica. Debido a que el software tiene fines educativos, tambin se estar investigando el cumplimiento de los correspondientes objetivos (elaborado por profesionales en el campo educativo).

2.1 Objetivos.
Verificar el grado alcanzado de los requerimientos mnimos indispensables para la funcionalidad y motivacin del software SAEP-PitA, segn lo estipulado. Analizar y validar con usuarios finales la funcionalidad y los siguientes atributos de calidad del software: seguridad, desempeo usabilidad e integracin conceptual.

2.2 Antecedentes.
Para finales del 2009 el profesor Javier Vsquez elabor el modelo MAEP, descrito en el documento Modelos para el anlisis espacial de problemas-ODD-MEP-FO_D-SIRZEE. Desde entonces se inici un trabajo en conjunto con el ITCR-SIRZEE para plasmarlo en un software. Este documento sirvi como base para especificar los requerimientos de software en ese momento. El trabajo de diseo de programacin detallado e implementacin del software inicia con la prctica de especialidad de Andrs Guzmn y Roco Quirs, en aquel momento estudiantes de

la Escuela de Computacin del ITCR. Estos estudiantes toman la propuesta del MAEP y ya para finales del 2010 se realiza una prueba piloto con docentes y estudiantes. Durante el 2011 se negocian contrataciones para ampliar y desarrollar el software que se contaba en ese momento. Es a finales del 2011 que se reanuda el proyecto y se negocian los requerimientos funcionales que el software deba contar. Este Plan de Pruebas se circunscribe en este contexto de trabajo para el 2012.

2.3 Alcance.
En este proyecto no se pretende realizar pruebas exhaustivamente para encontrar todos los errores, esto es econmicamente no viable. Se estar realizando pruebas hasta que el componente probado tenga una baja tasa de incidentes (Ver Criterios para Terminar Pruebas). Las pruebas se realizarn en todos los componentes de software del SAEP PitA, podemos mencionar el componente de mtricas, el de contenedores, foros y comentarios, subir datos, registro y autenticacin, creacin de usuarios y equipos de trabajo, entre otros. La plataforma SIRZEE (visor de mapa, herramientas para navegacin y consulta, etc) del ITCR no se estar probando.

2.4 Referencias.

ID

Ref

Doc um ent o

Des crip cin

1 En CD Cdi go Fue Com nte pon ente Foro sy Com enta rios Esp Esp

https://docs.goo

gle.com/docum ent/d/1KgAhvS Own9hNRglzP UWSQ8IEeVfo pHZ3zSte6FkCj ss/edit

ecifi caci n de Req ueri mie ntos de Soft war e Esp ecifi caci n y Res ulta dos de las Pru eba s de Soft war e

ecifi caci n final de requ erim ient os SAE PPitA Se det alla n las pru eba s que se reali zar on y sus res ulta dos.

https://docs.goo gle.com/docum ent/d/16mWILg 9NasJEiPLq3h Obuifc8G_eCif PsoCUlBqzeIM

3. Itemes de prueba
Creacin de mtricas Administrador de mtricas Administrador de contenedores Foros y comentarios Subir datos Registro y autenticacin Creacin y modificacin de equipos de trabajo

4. Caractersticas que se probarn

Funcionalidad: El proceso de pruebas, buscar asegurar y verificar que el sistema cumple con los requerimientos funcionales definidos en el documento Especificacin de Requerimientos de Software. Desempeo: Previo y durante la prueba piloto, se estar verificando que los tiempos de respuesta se encuentren dentro de lo normal, establecido en los requerimientos no funcionales. Seguridad: La fase de pruebas, debe asegurar que el sistema cumple con cierto nivel de seguridad, de tal forma que la informacin crtica no se puede acceder por terceros de forma simple, y que el sistema tome medidas bsicas para la autenticacin de los usuarios, o la conexin hacia las bases de datos. Usabilidad: El proceso de pruebas tambin contempla que tan sencillo es para el usuario utilizar el sistema, que tal se comporta la interfaz, y si el sistema tiene una reaccin no esperada cuando se utiliza de forma inusual o extraa. Debido a que tenemos de frente un software novedoso, adaptndose a un sistema de informacin geogrfico, surge la necesidad de validar con los usuarios qu tan fcil les resulta utilizarlo. Integracin conceptual: El software pretende ser el reflejo del modelo MAEP. Por lo tanto se debe analizar que cada uno de los componentes de software representan aspectos del MAEP y forman parte de la visin y propsito del modelo.

5. Caractersticas que no se probarn

Mantenibilidad Flexibilidad Portabilidad Interoperabilidad Accesibilidad

6. Enfoque
Herramientas: No se utilizarn herramientas especficas para pruebas de software. nicamente se utilizar los exploradores de internet: Google Chrome 22.0 y Firefox Mozilla 17.0.1. Finalmente, el proceso de pruebas debe intentar cumplir con todas las fechas fijadas, con el propsito de obtener errores y corregirlos en los mejores tiempos posibles.

Sobre los niveles y tcnicas de pruebas: Pruebas unitarias y de integracin: El ITCR ser el encargado de realizar las pruebas unitarias y de integracin con la plataforma SIRZEE. No obstante, este plan de pruebas estn fuera del alcance de tales labores. El ITCR disear su propio Plan de Pruebas para ese nivel de pruebas. Pruebas de Sistema: a. Funcionalidad y seguridad: Debido a que es impracticable realizar un exahustive input testing ni exhaustive path testing el conjunto de test cases que se crearn ser utilizando las siguiente tcnicas: Boundary-value Analysis y Error guessing (El tipo de pruebas utilizado es el dinmico y manual). Asimismo se utilizarn pruebas de regresin. Esto es que en cada etapa, y cada iteracin del sistema, las pruebas deben asegurar que cambios en el sistema no van a afectar el funcionamiento o estado previo del mismo. En caso de que lo hicieran, el proceso de prueba debe detectar la gran mayora de estos cambios para que puedan ser reparados o ignorados, dependiendo de su impacto en el sistema. b. Pruebas de desempeo: Slo se realizar una prueba, midiendo el tiempo que transcurre para ejecutar una operacin. No obstante, durante la prueba piloto se estar validando con los usuarios su conformidad con los tiempos de respuesta del sistema. c. Pruebas de usabilidad: Se utilizarn las heursticas de Myers y Nielsen. Esto corresponde a un anlisis cualitativo, sin embargo se estar utilizando el mtodo de conteo para cuantificar el nmero de heursticas que sugieren oportunidades de mejora en la usabilidad del sistema. Adems con la prueba piloto, se valida con los usuarios mediante el uso cuestionarios de evaluacin y anlisis FODA. d. Pruebas de integracin conceptual: Se realiza anlisis comparativo de los principales aspectos del modelo MAEP y los componentes de software correspondientes. Pruebas de Aceptacin: Se utilizarn las Pruebas de Sistema para la aceptacin de los productos.

7. Criterios para pasar o fallar un tem de prueba

Utilizando el sistema de prioridades propuesto, vamos a asociar los criterios de fallo para los items, de tal forma que para los items de baja prioridad, cuando un 70% de todos los casos de prueba tenga un resultado favorable, el item pasa, de lo contrario falla. Para los items de prioridad Media,si el 80% de todos los casos de prueba de un item tienen un resultado

favorable, entonces el item pasa, de lo contrario falla. Finalmente para los mdulos con una prioridad alta, se debern satisfacer un 95% de los casos de prueba con resultado positivo.

8. Criterios para suspender las pruebas y requerimientos de reanudacin

A partir del momento que se haya ejecutado el 10% de las pruebas de un mdulo, suspender las pruebas de ese mdulo en el momento en el que el porcentaje de fallo alcance el 50%. O no se cuente con algn mdulo clave para la ejecucin de la aplicacin.

9. Criterios para terminar las pruebas (Test Exit Criteria)

Cuando un componente no tenga una tasa mayor al 10% de incidentes, entonces se puede dejar de realizar pruebas a tal componente.

10. Entregables de pruebas

-El plan de pruebas -La especificacin de los casos de prueba y resultados (Reportes de incidentes) Ver punto 13 para conocer el calendario de entregables.

11. Tareas de pruebas

ver punto 13.

12. Necesidades de ambiente

12.1. Los siguientes son sistemas operativos para los cuales el sistema fue diseado, no obstante no sern probados. Windows Server 2003 Windows XP Home Edition Windows XP Professional Windows Vista

12.2. Los siguientes es el sistema operativo y navegadores de internet para ejecutar los casos de prueba y la prueba piloto: Windows 7 Google Chrome 22.0 y Firefox Mozilla 17.0.1.

12.3. Plataforma educativa como apoyo de la prueba piloto La siguiente es la direccin web de la plataforma educativa que se pone a disposicin de los profesores como apoyo de la prueba piloto: http://iesa.conare.ac.cr Este es un curso virtual, pretende ser anlogo a un curso presencial. En l se pueden encontrar recursos como documentos, fotos, videos, foros, noticias, calendario, enlaces, entre otros y actividades como tareas, quices, lecciones y dems. La plataforma educativa adems permite generar metadatos y estadsticas.

13. Responsabilidades

Actividad
Especificar el plan de pruebas Preparar la especificacin del diseo de pruebas y casos de pruebas. Ejecutar las pruebas llevando bitcora de ejecucin de pruebas. Crear Informe final una

Encargado Grupo de trabajo Grupo de trabajo Grupo de trabajo Grupo de trabajo

Fecha Enero 2012 Enero 2012 Marzo - Diciembre 2012 Enero 2013

14. Personal y necesidades de capacitacin

Las siguientes son las capacitaciones que los encargados requieren para realizar sus respectivas actividades: A los docentes se les debe capacitar en el uso del SAEP-PitA.

15. Riesgos y Contingencias

El proceso de la ejecucin de los casos de pruebas puede durar ms de lo esperado. Si el problema fuera muy grave entonces se debe modificar el diseo de pruebas de modo que la especificacin sea un proceso ms rpido. Sin embargo, esta opcin debe ser aprobada previamente por el comit asesor SAEP SIRZEE y dar explicaciones del origen del problema.

16. Horario
Ver punto 13.

17. Aprobaciones
____________________________________ Responsable del Plan de Pruebas ____________________________________ Desarrollador de Pruebas _______________ Fecha _______________

REFERENCIAS
Kaner, Cem; Falk, Jack; Nguyen, Hung Q. Testing Computer Software. 2d ed., John Wiley & Sons, 1999. IEEE Computer Society. IEEE Std 610.12.1990 Standard Glossary of Software Engineering Terminology. 1990. Lewis, William. Software Testing and Continous Quality Improvement. 3rd ed, CRC Press, 2009. Myers, Glenford J. The Art of Software Testing. Wiley-Interscience,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.12-1990). Es un conjunto de datos de entrada y resultados esperados que ejercitan a un componente con el propsito de causar fallas y detectar errores Bruegge. Describe por completo al sistema desde el punto de vista de los requerimientos funcionales y no funcionales, y sirve como una base contractual entre el cliente y los desarrolladores de software (Bruege) Segn Pressman, es un modelo de proceso de software evolutivo que conjuga la naturaleza iterativa de la contruccin de prototipos con los aspectos controlados y sistemticos del modelo en cascada. Proporciona el material para el desarrollo rpido de versiones incrementales del software. Un modelo de transformacin es un documento que explica cmo poder transformar un objeto en otro. En el proyecto se elaboraron cinco modelos que describe cmo transformar desechos slidos en productos finales tiles. En estos documentos se especifican los insumos, la teora de sustento, el proceso de transformacin, los productos generados y una aplicacin prctica con el software SAEP-PitA SIRZEE. Formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component IEEE (Std 610.12-1990). Measures how the final system meets users expectations Pezze & Young (2007). Prueban todos los componentes de software juntos, vistos como un solo sistema, para identificar errores en el comportamiento del sistema respecto a la especificacin de requerimientos funcionales y no funcionales. Segn Bruegge, pueden incluir pruebas funcionales, de desempeo, piloto y de aceptacin.

Documento de Especificacin de Requerimientos de Software Metodologa de Desarrollo Espiral

Modelo de Transformacin

Pruebas de Aceptacin

Pruebas de Sistema

Pruebas de Software

A set of activities designed to evaluate the quality of development or manufactured products IEEE (Std 610.12-1990). 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 de la funcionalidad comn entre un grupo seleccionado de usuarios finales en el ambiente de destino Bruegge. 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 ortografa, entre otros. Evaluar el grado en el que el software realmente satisface las necesidades reales del usuario Pezze & Young (2008) Checking the consistency of an implementation with a specification Pezze & Young (2008).

Prueba piloto

Pruebas de usabilidad

Validacin: Verificacin

ANEXOS
Anexo 1. Reporte de pruebas el 12/3/2012 Correo: 2012/3/12 CAndres Mndez <candres.com@gmail.com>

REQUERIMIENTOS MINIMOS Y DESEABLES PARA EL PITA-SAEP SIRZEE

Indispensables para la funcionalidad del sistema: Ejecucin de mtricas y contenedores 1. Tener resultados mltiples (Ej: resultado obtenido por distrito). Falta poder ejecutar las mtricas 2. Permitir incluir en la descripcin de la mtrica y contenedor un archivo PDF. Falta que sea opcional al crear mtrica. 3. Permitir incluir como atributo Equipo a la mtrica y contenedor (forma automtica). Falta que en el administrador de mtrica muestre el autor/equipo. 4. Operadores nuevos: Mn(x,y) y Mx(x,y) as como el uso de parntesis ( ) No se ha podido probar ya que falta poder ejecutar mtricas.

5. Al crear una mtrica, no mostrar sub-categoras o temas sino existen atributos para tales. Las categoras 'Organizacin' y 'Sector Productivo' casi no tienen caractersticas. 6. Interrelacionar usuarios con equipos: Un equipo puede tener uno o ms usuarios. 7. Al hacer click en el contenedor que salga una opcin de mostrar detalles del contenedor. El administrador puede editar los contenedores, no obstante falta que los estudiantes puedan conocer los detalles del contenedor. Por ejemplo ver la descripcin, las mtricas asociadas y link al documento pdf. Asimismo, al hacer click en una mtrica puede ver sus detalles como la descripcin, la frmula y el link del documento pdf asociado. Mostrar iconos en el mapa de los contenedores. Ocultar el icono de pdf cuando no hay pdf. Indispensables para la motivacin de estudiantes 1. Noticiero: Falta q se actualice automticamente al crear una mtrica. 2. Sistema de puntuacin 3. Tener operadores bsicos de edicin de mtricas y contenedores. Los equipos slo pueden editar sus propias mtricas o contenedores. 4. Comentarios: Equipos pueden ver y comentar contenedores de otros equipos.(NO PRIORIDAD) 5. Facilitar un link para ingreso al sitio ms usable. 6. Encargado de evaluacin: Revisa si las mtricas y contenedores agregados al sitio cumplen con los requerimientos mnimos. (El resultado de la evaluacin final lo puede dar un encargado de evaluacin o mediante un sistema de mayora de votos de los profesores, para esta ltima opcin habra que crear el usuario tipo profesor). (NO PRIORIDAD) 7. Diferenciar el tipo de usuario estudiante/profesor