plan de pruebas de software
DESCRIPTION
pruebsde software paTRANSCRIPT
Plan de Pruebas de Software
Aplicación web para el control y monitoreo de especies acuáticas
Tabla de contenido
Historial de Versiones..............................................................................................4
Información del Proyecto..........................................................................................4
Aprobaciones...........................................................................................................4
Resumen Ejecutivo..................................................................................................5
Alcance de las Pruebas............................................................................................5
Elementos de Pruebas.........................................................................................5
Nuevas Funcionalidades a Probar........................................................................6
Pruebas de Regresión..........................................................................................6
Funcionalidades a No Probar...............................................................................7
Enfoque de Pruebas (Estrategia)..........................................................................7
Criterios de Aceptación o Rechazo..........................................................................8
Criterios de Aceptación o Rechazo.......................................................................8
Criterios de Suspensión........................................................................................8
Criterios de Reanudación.....................................................................................9
Entregables..............................................................................................................9
Recursos................................................................................................................10
Requerimientos de Entornos – Hardware...........................................................10
Requerimientos de Entornos – Software............................................................10
Herramientas de Pruebas Requeridas................................................................11
Personal..............................................................................................................11
Entrenamiento....................................................................................................12
Planificación y Organización..................................................................................12
Procedimientos para las Pruebas.......................................................................12
Matriz de Responsabilidades..............................................................................13
Cronograma........................................................................................................13
Premisas.............................................................................................................14
Dependencias y Riesgos....................................................................................14
Referencias............................................................................................................15
Glosario..................................................................................................................15
Plan de Pruebas de Software
Historial de Versiones
Fecha Versión Autor Organización Descripción
10/2015 1.0 Fco. Vizñay – Omar Vargas IRBA - INP
Presentación de primeras páginas del sistema y validación
de campos
11/2015 1.1 Fco. Vizñay – Omar Vargas IRBA - INP
Revisión de validaciones y pruebas de resultados
12/2015 1.2 Fco. Vizñay – Omar Vargas IRBA - INP
Pruebas de funcionamiento y entrega del proyecto
Información del Proyecto
Empresa / Organización Instituto Nacional de Pesca
Proyecto Aplicación web para el control y monitoreo de especies acuáticas
Fecha de preparación Septiembre/ 2015
Cliente Departamento IRBA
Patrocinador principal Universidad de Guayaquil - FFM - CISC
Gerente / Líder de Proyecto Ing. Jorge Crespín
Encargados de Pruebas de Software Francisco Vizñay – Omar Vargas
Aprobaciones
Nombre y Apellido CargoDepartamento u
OrganizaciónFecha Firma
Director INP Dic/2015
Ing. Jorge Crespín LíderGestión de procesos
Dic/2015
Blgo. Coordinador Proceso IRBA Dic/2015
Blgo. Investigador Proceso IRBA Dic/2015
Resumen
Durante el proceso de pruebas se buscara establecer el debido funcionamiento de los
módulos que conforman el sistema de Control y monitorio de especies bioacuáticas, a su
vez demostrar la interoperabilidad entre los módulos y evaluación de resultados
entregados al usuario.
Se busca establecer los ajustes necesarios para dar como culminado el proceso de
desarrollo y poder entregar al cliente el recurso informático adaptado a las necesidades
establecidas desde el levantamiento de los requerimientos.
A nivel técnico probar que los recursos hardware interactúan de manera eficiente con las
exigencias del software a nivel de consumo de recursos. Se concluye con el documento
de aceptación del producto terminado y la puesta en producción de la aplicación.
Como objetivos generales del presente plan de pruebas esta la validación de
requerimientos, el debido cumplimiento de las funcionabilidades y orientar a que el
software cumpla de la manera más óptima posible características fundamentales como:
Aseguramiento de la calidad.
Solicitudes de cambios.
Riesgos de calidad.
Verificación de los casos de uso.
Comprobación de los requerimientos funcionales y no funcionales.
Alcance de las Pruebas
Elementos de Pruebas
Para la ejecución de las pruebas se contemplaron todos los módulos del sistema, los
cuales fueron definidos como:
Pruebas módulo Administrador, diseñado para generar nuevos usuarios y para
crear nuevos parámetros o variables para utilizarse en los otros módulos del
software.
Pruebas módulo Investigador, diseñado para el personal encargado de
alimentar el sistema de información, se ingresan todos los servicios de muestreo,
generación de informe de la actividad realizada y monitoreo de los resultados
obtenidos en el periodo de tiempo.
Pruebas módulo Coordinador, estructurado para el jefe de área encargado de
organizar al personal, dar aprobación a los ingresos de los muestreos y
monitorear los estatus de los reportes estadísticos.
A nivel de componentes se dio consideración a las actividades más importantes para el
departamento IRBA, las cuales se mencionaran según el orden de prioridad:
Ingresos de los informes de muestreo
Generación de los reportes estadísticos
Elaboración del agendamiento de las comisiones de servicio
En líneas generales se orientó el análisis a la revisión de las respectivas validaciones de
los formularios y el debido cumplimiento de los parámetros y valores utilizados para el
registro de los datos segúnlas consideraciones y recomendaciones del departamento
IRBA.
Funcionalidades a Probar
Para establecer la debida validez del software y el cumplimiento de los requerimientos del
usuario (reglas del negocio), se planteó probar actividades orientando el perfil de usuario,
por lo cual se estableció un grupo de pruebas orientadas según el perfil de usuario:
Administrador Creación, modificación y eliminación de Usuarios
Creación, modificación y eliminación de Especies
Creación, modificación y eliminación de Embarcaciones
Creación, modificación y eliminación de Puertos
Investigador Ingreso de informe de muestreo
Generación del informe del muestreo
Consulta de informes anteriores
Consulta de reportes estadísticos
Consulta de agendamiento de la comisión de servicio
Coordinador Aprobación de los ingresos de muestreos
Agendamiento de las comisiones de servicio
Consulta de informes anteriores
Consulta de reportes estadísticos
Pruebas de Regresión
Validación sobre la capacidad del sistema para responder y mantener su funcionabilidad
posterior a la realización de un ajuste según una corrección de validación o por un nuevo
requerimiento solicitado por el cliente.
Adicionalmente y con el fin de centrar el plan de pruebas en ciertos factores que son
críticos y de mayor relevancia para el proyecto, se determinan los tipos de pruebas que se
realizarán para el proyecto, diseñando los factores de calidad y las pruebas
especializadas para alcanzar estos atributos del software entregado. Con esta misión se
identifican de acuerdo a las especificaciones del cliente los factores
Para este proyecto de acuerdo a los requerimientos, se definen los siguientes factores en
los que se enfocarán las pruebas:
Corrección.
Conformidad.
Facilidad de Uso.
Portabilidad.
Facilidad de Operación.
Enfoque de Pruebas (Estrategia)
Se detalla la clasificación de las pruebas a realizar enfocando esta actividad a temas
funcionales, integrales, unitarios; para esto se detalla las áreas a analizar y las actividades
que la refieren:
Revisión de la documentación: Documentacion existente, constatando que la
información registrada tenga total concordancia con el tema o modulo en
evaluación.
Pruebas Unitarias: pruebas de grabado, consulta y eliminación. Verificación de
que el código se ejecute adecuadamente, validad que cumple con las
características solicitadas por el cliente, ejecutar por lo menos una vez el
programa en casos de error y en casos de éxito.
Pruebas de integración: verificar que la información generada replique con los
otros módulos del sistema, validar que los procesos estén debidamente
entrelazados ya que la actividad o acción que ejecute en un modulo generara
repercusiones en los otros módulos del software.
Pruebas Funcionales o de Procedimientos:Revisar que los módulos y las
actividades desarrolladas en cada uno cumpla con las reglas del negocio
establecidas por el INP al momento de establecer los requerimientos, analizar la
funcionabilidad de los componentes, el procesamiento y entrega de los reportes
solicitados.
Pruebas de sistema:plantear los casos de uso a probar según el módulo y perfil
de usuario, revisar el nivel de cumplimiento y los tiempos de respuesta.
Pruebas de Compatibilidad:plantear pruebas para validar la compatibilidad con
los diferentes tipos de navegadores y dispositivos electrónicos desde los cuales la
aplicación pueda ser accedida, verificar si se adapta de manera íntegra y segura
con el navegador que lo invoque.
Pruebas de Regresión: La estrategia para realizar estas pruebas consiste en
repetir las pruebas (funcionales y de carga) ejecutadas antes de corregir defectos
o de añadir nuevas funcionalidades, para comprobar que las modificaciones no
provocan errores donde antes no los había.
Criterios de Aceptación o Rechazo
Para lograr la finalización del plan de pruebas se definen los siguientes criterios que
permitan dar por culminado el proceso de pruebas de la aplicación:
Completar el 100% de la pruebas unitarias, estas permitirán identificar que el
software se ejecuta eficiente y adecuadamente.
Aplicar un proceso de actualización en el código y comprobar el criterio de
regresión, constatar el continuo desempeño del software por encima de los
cambios efectuados
Verificar que se haya cumplido el 100 % de las pruebas funcionales y de
interoperabilidad.
Comprobar el tiempo de respuesta por medio de las pruebas de sistemas, tiempos
de acceso a la base, tiempo de guardado y tiempo de entrega de resultados.
Validar las pruebas de compatibilidad por medio del uso eficiente desde diferentes
dispositivos, considerando puntos relevantes como la adaptación de la interface, la
visualización de los datos y los tiempos de carga.
Entregables
Durante la ejecución del plan de pruebas se plantea presentar soportes como evidencia
de la planificación, ejecución y seguimiento del plan de pruebas. Los entregables podrían
están definidos como:
Documento de Plan de Pruebas
Casos de Pruebas
Informe de ejecución de pruebas
RecursosRequerimientos de Entornos – Hardware
Para la realización del plan de pruebas se va a requerir los siguientes los
siguientes recursos hardware para realizar los procedimientos correspondientes:
Equipo PC, i5, 250 Gb y 2 RAM
Acceso a la Base de datos
Conexión a internet
Tablet para pruebas de compatibilidad
Requerimientos de Entornos – Software
A nivel de software se procederá a requerir lo siguiente:
Perfiles de cada nivel de usuario para la aplicación IRBA, del INP
Acceso a la Base de datos
Software de análisis para revisión y pruebas
Herramientas de Pruebas Requeridas
Para cumplir con la ejecución del plan de pruebas de proyecto se emplearon las
siguientes técnicas de análisis, detalladas en las siguientes fichas de identificación:
Factor de Prueba: Conformidad Técnica: Pruebas de operaciónDescripción:
Mediante las pruebas de operación se valida que el usuario está debidamente
capacitado para el manejo del software y se complementa con una bitácora de
registros que permitan guardar los caminos o acciones no contempladas en las
pruebas iniciales del software, con ello se tomarían los correctivos necesarios.
Factor de Prueba: Facilidad de Operación Técnica: Pruebas de Requerimientos
Descripción:
Validar los requerimientos no funcionales de ambiente recolectados con el cliente
versus las características requeridas por el ambiente de producción.
Personal Para los procesos de prueba se distribuye el personal según las actividades de prueba:
Francisco Vizñay - Pruebas de Operación
Omar Vargas - Pruebas de Requerimientos
Planificación y Organización
Procedimientos para las Pruebas Para realizar las pruebas necesarias procederemos a utilizar la técnica de listas de
chequeo
Objetivo de la técnica:
Verificar que la parametrización de componentes y todos
los aspectos referentes a la integración de partes del
software (consideraciones, configuraciones,ajustes)
cumplan con lo preestablecido pro el equipo desarrollo
en la fase de diseño.
Técnica Listas de Chequeo
Herramientas requeridas: Listas de chequeo con los ítems a comprobar para la integración
Criterio de éxito El 100% de los ítems han sido chequeados y cumplen con la condición para ser aprobados.
Matriz de Responsabilidades
Para poder establecer el nivel de responsabilidad que el equipo de desarrollo y los
representantes de la institución tendrán en la ejecución de la prueba del sistema, se utilizó
una matriz RACI, específicamente la variación tipo RACI-VS en la cual los roles están
detallados por:
Rol DescripciónR Responsable Persona quien realiza la tarea
A Quien rinde cuentas
Este rol se responsabiliza de que la tarea se realice y es el que debe rendir cuentas sobre su ejecución.
C Consultado Conocedor del proceso que realiza la tarea
I Informado Recibe información sobre las pruebas
V Verificador Verifica que la tarea cumpla lo solicitado
S Aprobador Aprueba el proceso auditado
Actividad / Recurso FRANCISCO VIZÑAY
OMAR VARGAS
LIDER DE SISTEMAS
COORDINADOR IRBA
Revisión de la documentación R R V IPruebas Unitarias V R C APruebas de integración R R A VPruebas Funcionales R R V APruebas de sistema A R I APruebas de Compatibilidad C C V APruebas de Regresión R V A I
Dependencias y RiesgosSe detalla un alcance de los riesgos que puedan presentarse al momento que se
ejecuten las pruebas
Factor de Prueba Requerimientos Diseño Software
Conformidad
Pasar por alto la prueba de
requerimientos no funcionales clave que
impliquen un gran impacto en la
arquitectura propuesta.
Alta complejidad en el diseño de las pruebas
que evidencien la conformidad con los requerimientos de gobernabilidad y
reusabilidad
Omitir la ejecución de pruebas en las
características menos comunes de
utilización.
Portabilidad
Identificar tardíamente problemas de
compatibilidad con plataformas externas de alto riesgo o costo.
No contar con la tecnología necesaria para probar aspectos del diseño enfocados a comprobar el bajo acoplamiento de la
solución.
No cubrir en las pruebas una
cantidad representativa de plataformas que
deben ser compatibles con la solución a futuro.
Facilidad de Uso
No lograr captar la opinión de los usuarios finales para determinar
los aspectos de facilidad de uso que
ellos esperan.
Realizar las pruebas con un enfoque muy técnico sin detectar aspectos que por diseño supongan
complejidades altas en el uso del software
Probar solo funcionalidades sin
identificar problemas o mejoras en la
facilidad de utilización del
software
Facilidad de Operación
No incluir en las listas de chequeo de
comprobación de los requerimientos, los
aspectos relacionados con la facilidad de
operación, por desconocimiento en los
mismos
No detectar a tiempo aspectos del diseño que se conviertan en impedimentos para
permitir las fácil instalación y
administración de las solución
Detectar tardíamente problemas
relacionados con la instalación y operación del
software