Plan de Pruebas |Gym-Phone

INSTITUTO TECNOLOGICO DE COSTA RICA

PLAN DE PRUEBAS
Gym-Phone

Curso: Especificaciones de software

Profesor: Jaime Solano Soto

Elaborado por:

Andrs Ramrez 201013880 Larissa Rivas 201022184

08/04/2013

pg. 1

Plan de Pruebas |Gym-Phone

Tabla de contenido
1. 2. 3. 4. 5. 6. 7. 8. 9. 9.1 9.2 9.3 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Identificador del plan de pruebas ....................................................................................... 3 Referencias ........................................................................................................................... 3 Introduccin ........................................................................................................................... 3 Objetos a evaluar ................................................................................................................. 4 Riegos del software .............................................................................................................. 5 Caractersticas que van a ser evaluadas .......................................................................... 5 Caractersticas que no van a ser evaluadas .................................................................... 6 Enfoque .................................................................................................................................. 7 Criterios de evaluacin /fallo para los objetos ................................................................. 8 Criterios de aceptacin .................................................................................................... 8 Descripcin de los criterios de fallo en alguna funcionalidad .................................... 8 Documentacin de los errores........................................................................................ 9 Criterios de suspensin y requisitos de reanudacin ................................................. 9 Entregables ..................................................................................................................... 10 Pruebas pendientes ....................................................................................................... 12 Necesidades del ambiente ............................................................................................ 12 Dotacin de personal y necesidad de capacitacin .................................................. 12 Responsabilidades ......................................................................................................... 13 Calendario ....................................................................................................................... 13 Planificacin de Riesgos y Contingencias .................................................................. 14 Aprobaciones .................................................................................................................. 15 Glosario ............................................................................................................................ 16

pg. 2

Plan de Pruebas |Gym-Phone

1. Identificador del plan de pruebas El siguiente documento corresponde a un plan de pruebas de la aplicacin GymPhone en su versin de desarrollo 1.0, la cual est creada para dispositivos mviles con plataforma android SDK 2.2. El producto ha sido solicitado por la empresa de un gimnasio para todas las sucursales del pas. Este documento ser identificado como TP-01 lo que ayudar al control de versiones de software o testing que se generen durante el proyecto. Es importante mencionar que este documento est sujeto a cambios por motivo de su naturaleza dinmica, por lo cual se llevar un control de actualizaciones en la siguiente tabla: identificador TP-01 Fecha 07-04-2013 Descripcin Desarrollo del Autor

plan de pruebas v1

2. Referencias El propsito del documento es validar los requerimientos y respaldar el plan de pruebas TP-01. Para ello se cuenta con el respaldo de los siguientes documentos: Test Plan Outline ( ). Especificacin de requerimientos de software (v1)

3. Introduccin El propsito de este documento es servir de referencia a la hora de llevar a cabo las pruebas sobre el producto para corroborar la calidad del software desarrollado. El poder definir previamente los aspectos a evaluar, permitir que el programa sea revisado en cada aspecto importante para el cliente y el usuario sin olvidar o hacerlo de manera parcial.

pg. 3

Plan de Pruebas |Gym-Phone

El objetivo ser validar que la aplicacin cuente con estndar de calidad y funcionalidad requerida en ptimas condiciones bajo entornos previamente definidos. El plan de pruebas describe en las secciones siguientes todas las pruebas que se realizan con el software con el fin de validar su eficacia en las reas que se determinen. Los objetivos que se pretenden alcanzar con el plan de pruebas se enuncian a continuacin: Encontrar las fallas que posea la aplicacin con la prueba de sus componentes. Verificar que se cumplan los requerimientos que han sido definidos en el documento de Especificacin de requerimientos de software. Encontrar errores en el funcionamiento de la aplicacin para determinar los riesgos y posibles soluciones contra las fallas encontradas. Poder determinar la calidad del producto y rendimiento de la aplicacin.

4. Objetos a evaluar Este documento se centrara en las funcionalidades que se enumeran a continuacin para verificar su funcionamiento del software Gym-Phone 1.0: Log in. Perfil. Ejercicios. Rutinas. Ayuda. Estadsticas. Ranking. Los cuales estn compuestos por elementos del SDK android 2.2 que se citan a continuacin y sern revisados: TextBox. Botones.
pg. 4

Plan de Pruebas |Gym-Phone

Base de datos tanto lectura, como escritura de datos. TextView. Activity. Intents. Eventos del teclado. Eventos del usuario. Listas. Por lo tanto, se pretende realizar un plan de pruebas que abarque todos los requerimientos mencionados juntos con los elementos para que la versin 1.0 del producto se encuentre libre de fallas. 5. Riegos del software Entre los riesgos que podemos considerar de alta impacto, tenemos el cargar los datos de inicio de sesin por parte de un usuario para utilizar la aplicacin, ya que para este procedimiento es requerido el acceso a internet. Otro aspecto a tomar como riesgo, es la escritura de informacin en la base de datos, cada vez finalizado un ejercicio, ya que este proceso no deber de fallar para corromper o alterar la informacin almacenada. Adems de los riesgos mencionados anteriormente, tambin es importante

considerar riesgos del tipo de incompatibilidad con movibles, al implementar libreras externar para el desarrollo de Gym-Phone, la seguridad de los datos que viajan a travs de la red, o incluso la informacin que esta guardaba en el dispositivo, as como tambin la mala interpretacin de los requerimientos originales propuestos por los interesados. Adems tener que realizar grandes modificaciones a los requerimientos al encontrar grandes fallos durante la revisin. 6. Caractersticas que van a ser evaluadas A continuacin se presentara una lista de funcionalidades desde el punto de vista del cliente las cuales se probaran en este plan de pruebas. Se utilizara una escala de medicin con los siguientes aspectos: Alto, medio y bajo los cuales sern compresibles para el cliente.

pg. 5

Plan de Pruebas |Gym-Phone

Funcionalidad Iniciar Sesin

Descripcin El usuario de ingresa usuario

Impacto el Alto y

nombre

contrasea para utilizar la aplicacin. Perfil El usuario configura sus Medio datos conforme proporciones Ejercicios El usuario elige actividades las Alto e para a medirlo sus

instrucciones que puede realizar gimnasio Ranking Le Muestra de las Bajo mas dentro del

actividades rendimiento Estadsticas

Le Muestra el esfuerzo Bajo realizado en cada rutina.

Ayuda

Le Muestra cmo utilizar Bajo el software.

Rutinas

El usuario determina la Medio rutina a realizar.

7. Caractersticas que no van a ser evaluadas A continuacin se mostraran las caractersticas que no van va a ser evaluadas en este plan de pruebas desde la vista del usuario, ni por parte del sistema: Actualizacin de las actividades del software por medio de la conectividad de datos ni por wi-fi.

pg. 6

Plan de Pruebas |Gym-Phone

Creacin de rutinas propias que se podrn utilizar como parte de las rutinas a realizar. La aplicacin en segundo plano. Una vez que se salga del progra, este volver a su pantalla de log in. 8. Enfoque En esta seccin se plantea la estrategia a utilizar para el plan de pruebas TP-01 de la aplicacin Gym-Phone. La aplicacin se desarrolla bajo un entorno de android SDK 2.2 por lo cual la revisin del correcto funcionamiento de sus componente y libreras es vital para lograr obtener un punto de medicin. Por esta razn, se probara cada uno de los widget que aporta el entorno de desarrollo y se proceder a medirlos con los siguientes parmetros: Entorno grfico de diseo: Se deber determinar si el tamao, posicin, distribucin en el rea de visualizacin son los correctos para el usuario. Ya que es de suma importancia, que estos presenten unos valores apropiados para su manipulacin. Tiempos de respuesta: Se medir el tiempo que tarda un componente en realizar una determinada accin y valorar si el tiempo de respuesta es el adecuado para la aplicacin. Funcionalidad: Deber de responder ante la funcin que se le est invocando, y verificar que cumpla con el propsito para el cual ha sido asignado. Con relacin al hardware, vamos a utilizar 2 forma de probar el producto. El primer componente que se utilizar ser un dispositivo virtual tambin conocido como emulador, que es una herramienta para el testing de aplicaciones. Gracias a esta herramienta de emulacin, podremos probar el software en configuraciones con bajo nivel de RAM y bajo nivel de display. Entre las configuraciones que manejaremos encontramos dispositivos de baja gama, gama media, y dispositivos de gama alta.

pg. 7

Plan de Pruebas |Gym-Phone

Como segundo mtodo, utilizaremos un Smartphone Samsung Galaxy Dous el cual contar con los requerimientos mnimos para el funcionamiento del programa. Se echar mano de los casos de uso definidos en el documento de especificaciones del software para comprobar que las funciones que se realicen sean las que se esperan por parte del programa, adems de contar con un actor que vendra siendo el usuario para la manipulacin del producto y estudiar la interaccin que tiene el sistema con el usuario. Las pruebas son unitarias, y la tcnica utilizada para la realizacin de estas pruebas es del tipo caja negra, el cual probara con datos de entrada introducidos por el actor y los datos de salida, los cuales sern mostrados por el sistema. 9. Criterios de evaluacin /fallo para los objetos En este apartado, se determinaran los criterios con los cuales van a ser evaluados los resultados que se obtendrn en las pruebas realizadas sobre el producto. As se podr medir la flexibilidad y aceptacin. 9.1 Criterios de aceptacin Los elementos que sern probados sern considerados como aprobados si cumplen con los siguientes requerimientos y aspectos que se detallan a continuacin: La funcionalidad concluye con normalidad sin ningn factor de error. El tiempo de respuesta por parte del componente no supera los 5 segundos. Los casos de uso debern de ser cumplidos al 90% con algunos pequeos defectos. Todo el cdigo ha sido utilizado por las funciones que lo requeran.

9.2 Descripcin de los criterios de fallo en alguna funcionalidad Los siguientes eventos sern tomados como errores en el programa: Una funcin termina de forma inesperada. El porcentaje de completado del caso de uso, no es superior al 90%.
pg. 8

Plan de Pruebas |Gym-Phone

Existen muchos defectos en la funcionalidad de los componentes. Difcil uso de la interfaz por parte del usuario. Definiremos tres tipos de error que se pueden presentar mientras se ejecutan las pruebas. Error Leve: es una error de diseo grfico, que no representa ningn efecto nocivo sobre el funcionamiento del software, pero que si puede incomodar al usuario o dificultarle su tarea. Error medio: error que no ejecuta su funcin de forma adecuada, pero que el programa puede seguir funcionando de forma normal. Error Grave: El programa se cae, y presenta un error en el flujo normal del software irreversible. 9.3 Documentacin de los errores Los errores que son encontrados debern de ser anotados en una tabla que especifique los detalles para su correccin. La siguiente tabla muestra los detalles que debern ser guardados por cada error encontrado. Versin Fecha Funcionalidad Descripcin Autor

10. Criterios de suspensin y requisitos de reanudacin El propsito de este apartado, es determinar cundo es necesario hacer una pausa en las pruebas o cuando es posible considerar una reanudacin en el caso de que se presenten errores, ya que en casos de que se presente un error y se deba de considerar si es necesario seguir o detenerse para no gastar recursos innecesariamente. A continuacin se darn los criterios con los que se suspender la prueba:

pg. 9

Plan de Pruebas |Gym-Phone

Si al realizar el intento de log in, el sistema

no permite el acceso al

programa se cataloga como un error grave, la prueba se suspender, ya que no se podr evaluar ninguna otra funcionalidad. Si al ejecutar alguna accin el programa tira un error por parte del sistema operativo, se considerara un error grave, y la prueba se suspender, no se proceder a reanudar la aplicacin. Si la carga de informacin desde la base de datos falla en el ranking o estadsticas, se considerar un error grave, y la prueba se suspender, por falta de un funcionamiento correcto del sistema. A continuacin se darn los criterios con los que se podrn reanudar la prueba: Un error en un componente de la interfaz grfica que no se visualice correctamente, pero que deja la manipulacin para llevar a cabo su funcin, se considerar un error leve, y se podr continuar con el proceso de prueba. Al ingresar una rutina nueva, no se guarda en la base de datos, se considerara un error medio, y se proceder a la reanudacin con otro ejemplo de rutina. No se guarda los datos del perfil, se considera un error medio, y se procede a reanudacin con los datos predefinidos por el sistema. 11. Entregables Se concretar los entregables que se le entregar al cliente como parte de este plan: El documento del plan de pruebas: Un documento donde se renan las especificaciones del plan de pruebas del software debidamente documentando siguiendo el estndar IEEE 829 Format. Casos de pruebas:

pg. 10

Plan de Pruebas |Gym-Phone

Entregar un documento con los distintos escenarios de las funciones presentes en la aplicacin. El formato de este documento ser una tabla que describa la tarea y el escenario por tarea semejante al siguiente: Tarea Iniciar sesin Escenario El usuario ingresa a la

aplicacin y debe digitar su correspondiente nombre de usuario y contrasea. A continuacin da clic en el botn Iniciar Sesin y de esta manera accede a la aplicacin. El sistema proceder a presentarle el men para realizar sistema las operaciones del

Pruebas de especificaciones de diseo: Este entregable recolecta la informacin relacionada con la interfaz y el diseo grfico del sistema, contendr las especificaciones de cada componente del SDK de la interfaz puesto como parte de la interaccin con el usuario. Entre los puntos que podemos recopilar son: o Distribucin de componentes: Verificar que todos los componentes estn situados de la mejor manera posible para el agrado y facilidad del usuario. o Tamaos: comprobar que los tamaos son los idneos para la manipulacin de cada uno de los elementos. o Colores: sean relacionados con los colores de la compaa, naranja y gris.

pg. 11

Plan de Pruebas |Gym-Phone

o Legibilidad: Consiste en determinar si es posible leer el tamao de los componentes sin hacer mucho esfuerzo por parte del cliente. Reporte de problemas y acciones correctivas: Se deber presentar un documento que contiene la tabla de problemas detectados junto con sus acciones correctivas. 12. Pruebas pendientes Esta seccin enunciara las actividades o requerimientos funcionales que deberan estar presenten en este producto pero que estn pendientes de revisin hasta la prxima versin ya que no ha sido contemplado en este primer ciclo de pruebas. Estas actividades son: Verificacin va Internet del nombre de usuario y contrasea. Actualizacin de la lista de actividades de la aplicacin. Creacin de una nueva rutina, y su insercin en la lista de rutinas. Opciones de ayuda actividades desde pantallas externas al ayuda del men. 13. Necesidades del ambiente Para la realizacin de las pruebas ser importante contar con un computador de suficientes recursos para poder correr el emulador con sus distintas

caractersticas. Configurar correctamente los dispositivos para que corran bajo el SDK versin 2.2. Adems de poseer una conexin al Telfono Samsung Galaxy duos para poder instalar y probar el sistema en el telfono. 14. Dotacin de personal y necesidad de capacitacin La aplicacin no es compleja, es de interfaz simple e intuitiva, por lo que no se ha tenido que invertir en una capacitacin de personal para la ejecucin del plan de pruebas. La informacin recopilada para la elaboracin de este proyecto ha sido gracias a los manuales de proceso por partes de los especialistas que aportan manuales de gua para los desarrolladores.

pg. 12

Plan de Pruebas |Gym-Phone

15. Responsabilidades A continuacin se presentara un cuadro con responsabilidades del plan de pruebas con sus respectivos encargados: Responsabilidad Encargado

Coordinacin del cumplimiento del plan Administrador de plan de pruebas de pruebas. Probar aplicacin Comprobar los estndares de calidad Determinar que ser probado Usuarios para prueba Inspector de calidad Desarrolladores de calidad, cliente,

Verificar que las funcionalidades estn Inspector implementadas Tomar decisiones que sobre no han

desarrolladores las Cliente, desarrolladores, administrador sido de plan de pruebas

funcionalidades probadas

Control de riesgos Toma de acciones sobre problemas

Desarrolladores Desarroladores, Adminsitrador de plan de pruebas

16. Calendario

pg. 13

Plan de Pruebas |Gym-Phone

17. Planificacin de Riesgos y Contingencias El plan de contingencia presenta una seccin de impacto que ser catalogada de 1 como bajo impacto y 10 como mximo impacto. Se detallara primera mente los niveles de impacto. Objetivo Costo Muy Alta 4 Incremento Alta 3 Incremento 8% Moderada 2 Incremento del del 4% Baja 1 Modificacin del sin cambios

del 11% del del presupuesto Tiempo Retraso

presupuesto

presupuesto del Modificacin sin cambios Modificacin sin cambios

del Retraso

del Retraso

proyecto 11% Alcance Cambios drsticos

proyecto 7% Cambios moderados

proyecto 3% Pocos cambios

drsticos

Con base a la tabla anterior podemos plantear en trminos medibles el impacto de cada uno de los riesgos. Riesgo La falta de recursos de personal cuando la Plan de Contingencia Impacto

Se deber buscar 4 la optimizacin del

pg. 14

Plan de Pruebas |Gym-Phone

prueba es empezar

tiempo para que los integrantes del equipo logren el objetivo

La

falta

de de

Se

recurrir

a 1

disponibilidad hardware necesarios

emuladores adquirir hardware necesario

para el

Entrega

tarda

del

Se

deber

de 3

software, hardware o herramientas

planificar con das de antelacin para cumplir horario, calculando tiempo un con

comodn

por imprevistos Los cambios en los requisitos originales o diseos Se reestructura 5

los requerimientos necesarios para la creacin producto del

18. Aprobaciones La aprobacin del sistema se encuentra en manos de Tech-Fitness; empresa que desarrollo la solicitud de la aplicacin para su gimnasio, ellos indicarn si la manera en la que se esta desarrollando la aplicacin es de su agrado y cumple con sus necesidades. Para obtener la aprobacin se cuenta con un prototipo que muestra como se va a trabajar con dicha aplicacin. Este contiene todas las pantallas por desarrollar as como sus funciones. Tambin un documento de Especificaciones de Desarrollo
pg. 15

Plan de Pruebas |Gym-Phone

para simplificar su comprensin. Se debe verificar que el manejo sea sencillo, ya que lo utilizar cualquier miembro del gimnasio. Para no tener problemas a nivel tcnico con involucrados externos, la informacin utilizada ser administrar de manera segura. Trato de confidencialidad realizado con la empresa.

19. Glosario

Android: Es el sistema operativo basado en Linux en el que se realiza esta aplicacin, es usado mayormente por el Smartphone Samsung. Cliente: Persona que utiliza los servicios de un profesional o una empresa. Cronograma: herramienta de gestin de proyectos que detalla las actividades desempeadas o por desempear. Desarrollador: persona encargada de la gestin de proyectos de desarrollo de software. Entregable: Cualquier producto medible y verificable que se elabora para completar un proyecto o parte de un proyecto. ERS: Especificacin de Requerimientos de Software. Fallo: Es el resultado de un defecto; desde el punto de vista de un usuario, el sistema deja de funcionar. Hardware: componentes tangibles en una maquina informtica. Plan de pruebas: determina el alcance, enfoque, manejo de riesgos, recursos, calendario de un conjunto de pruebas. SDK: Conjunto de herramientas que permiten desarrollar aplicaciones Sistema operativo: Es un programa o conjunto de programas que gestionan los recursos de hardware y proveen servicios. Software: conjunto de componentes lgicos utilizados en un sistema de informtica. Usuario: Aquel que usa algo. En este caso el repartidor que utilizara esta aplicacin.

pg. 16