Cambio de registro
Versión
Fecha de cambio
1.0.0
23/09/2021
Por
Miguel Ángel Pérez López
Ariadna Huesca Coronado
Octavio Andrick Sánchez
Perusquia
Javier Emilio Moreno Márquez
Rubén Sánchez Mayén
Claudia Sarahi Armenta Maya
Descripción
Diseño
Introducción
Alcance
Dentro de alcance
Fuera de alcance
Objetivo de calidad
Roles y responsabilidades
2
2
2
2
3
3
Metodología de Prueba
Overview
Niveles de prueba (Unitarias e integración)
Triaje de Errores
Criterios de suspensión y requisitos de reanudación
Prueba de Integridad
3
3
4
4
5
5
Entregables de prueba
5
Necesidades de Recursos y de Entorno
Herramientas de Prueba
Entorno de Prueba
5
6
6
Términos/Acrónimos
6
Release Control
7
Análisis de Riesgo
8
Revisión y Aprobaciones
9
1
1 Introducción
Con respecto a las pruebas, se usará una metodología iterativa, debido a que se alinea más a nuestra forma
de trabajo y a la recepción continua de retroalimentación. A su vez, se calcularon los riesgos para realizar
planes de acción y mitigación para cada escenario.
Se establecieron los elementos funcionales y no funcionales que se podrán probar con el plan plasmado en
el documento, así como los requerimientos físicos mínimos de nuestros dispositivos, para que las pruebas
puedan ser fácilmente replicables.
Por último, se pueden observar los roles; tanto de las personas encargadas de desarrollar el proyecto como
de revisar las iteraciones, así como la forma en la que nosotros podemos ver el historial de los cambios
realizados (Github).
1.1 Alcance
1.1.1 Dentro de alcance
●
●
●
●
●
●
●
●
●
●
●
●
Registro de usuario.
Inicio de sesión.
Actualización de datos.
Confirmación por correo electrónico
Entrega de certificados digitales
Publicación en redes sociales.
Diseño responsivo.
Donar
Histórico de donaciones
Navegación
Conección con la base de datos
Base de datos
1.1.2 Fuera de alcance
●
●
●
●
Seguridad de la información
Capacidad de la base de datos
Servidor hosteado en Azure.++
Debe seguir los lineamientos de diseño sobre Material Design.
2
1.2 Objetivo de calidad
●
●
●
Asegurar que la aplicación bajo prueba cumpla con los requisitos funcionales y no funcionales
Asegurar que el AUT cumpla con las especificaciones de calidad definidas por el cliente.
Los errores / problemas se identifican y solucionan antes de su lanzamiento.
1.3 Roles y responsabilidades
Durante el desarrollo del proyecto, estas serán las tareas principales de los integrantes del equipo :
Miguel Ángel Pérez López. Lógica de la interacción entre componentes de la aplicación tanto de forma
interna(slides y animaciones) como externa(API).
Octavio Andrick Sánchez Perusquia. Desarrollo de la programación
Rubén Sánchez Mayén. Desarrollo de la programación.
Javier Emilio Moreno Márquez. Coordinación de la información que se tomará y su procesamiento.
Ariadna Huesca Coronado. Coordinación de las fases del proyecto y evaluación del apego del proyecto
a los requerimientos establecidos inicialmente. Desarrollo de pruebas y corrección de software.
Claudia Sarahi Armenta Maya. Estética, manejo de colores y programación del contenido de
interacción de la aplicación.
2 Metodología de Prueba
2.1 Overview
Realizaremos una metodología iterativa, debido a que necesitamos hacer cambios pequeños y graduales y
se van a ir probando para saber de qué manera está afectando a la funcionalidad deseada y si cumple las
métricas establecidas.
Con esta prueba se tiene la ventaja de tener retroalimentación inmediatamente después del final del ciclo
y que las tareas se pueden realizar en menos tiempo debido a que con cada iteración los desarrolladores
tienen más experiencia del proyecto..
3
2.2 Niveles de prueba (Unitarias e integración)
Por cada cambio de funcionalidad en cualquiera de los módulos, se realizan pruebas unitarias de caja
negra sobre ese módulo para minimizar la inyección de errores críticos sobre dicha fracción del código.
Posteriormente, dado al tiempo limitado de desarrollo, se harán pruebas Big Bang para probar la
integración de los módulos. Después, se usarán principalmente pruebas de usabilidad para identificar la
facilidad de uso de la aplicación con personas conocidas, y se documentará las observaciones que se
encontraron gracias a las siguientes pruebas. También, por nuestra parte se implementarán pruebas
funcionales para sobre cada uno de los requerimientos interpretados, generando la mayor cantidad de
ideas posibles que puedan provocar que dicho requisito no se cumpla. Finalmente,con ayuda de elementos
de la Fundación Dibujando un Mañana, se realizan pruebas de aceptación para corroborar una vez más
que la interpretación de los requerimientos por parte de dicha organización se ven plasmados en la
aplicación, y que las operaciones o procesos de negocio se encuentren satisfechos.
2.3 Triaje de Errores
El orden de prioridad de la corrección de los errores en la aplicación se realizará conforme a la severidad
del incumplimiento de los siguientes criterios:
-
-
Requerimientos funcionales: Que un requerimiento no se plasme bajo un proceso esperado o
deseado. Estos a su vez pueden subdividirse con base en el nivel de importancia para el objetivo
empresarial de la fundación.
Usabilidad: Características o comportamientos que dificultan el uso de la aplicación.
Seguridad: Los datos suministrados por el usuario o generados por un proceso alterno se ven
comprometidos en términos de confidencialidad, integridad o disponibilidad.
Entonces, los errores se clasifican en los siguientes niveles:
-
-
-
Errores urgentes: Dichos errores se tienen que gestionar en el mínimo marco de tiempo posible
(preferiblemente 24 horas). Principalmente se buscará darle una solución para disminuir la
severidad del error o arreglarlo del todo. Se puede acelerar el plan de lanzamiento de la aplicación
para corregir dicha eventualidad.
Errores de media prioridad: Estos errores no afectan el resultado de un requerimiento funcional o
de seguridad. Generalmente harán referencia a un error de formato o compatibilidad no
destructivo.
Errores de baja prioridad: Generalmente abarcan características visuales o de usabilidad no
disruptivas para la aplicación. No es necesario corregirlos para el siguiente lanzamiento de la
aplicación.
4
2.4 Criterios de suspensión y requisitos de reanudación
● Sí un componente tiene muchas fallas durante las pruebas, se suspenderá la prueba para arreglar
el componente, tener un promedio de defectos en cada componente y si se excede el promedio de
defectos suspender la prueba.
2.5 Prueba de Integridad
Como criterios a considerar para considerar el producto como test complete tomaremos en cuenta,
primeramente, que haya completado con éxito todas las pruebas unitarias, es decir, que las pruebas
pertinentes a cada módulo del programa sean completadas. Aunado a ello, se tomará en cuenta que el
producto complete una prueba big bang, es decir, que supere una (o varias) prueba del producto en su
totalidad.
3 Entregables de prueba
Pre fase de pruebas
●
●
●
Plan de pruebas
Estrategia de pruebas
Casos de prueba
Durante la fase de pruebas
●
●
Logs
Scripts de prueba
Pos fase de pruebas
●
●
Registro de funcionalidad
Reporte de errores/bugs
5
4 Necesidades de Recursos y de Entorno
4.1 Herramientas de Prueba
●
●
●
●
Requirements Tracking Tool
Node JS
Android Studio Unit Testing
Automation Tools
4.2 Entorno de Prueba
Requerimientos mínimos de hardware que se usarán para probar la aplicación.
●
●
Procesador Qualcomm Snapdragon 400 en adelante, Exynos 5420 en adelante, Kirin 410 en
adelante o MediaTek MTK6753T en adelante.
Memoria RAM de 2GB
Se requieren los siguientes programas además del software específico del cliente.
●
●
●
●
Android Lollipop 5.0 en adelante
SQL Server Management Studio
Android Studio
Node Js
5 Términos/Acrónimos
Mencione cualquier término o acrónimo utilizado en el proyecto.
TÉRMINO/ACRÓNIMO
DEFINICIÓN
API
Application Program Interface
AUT
Application Under Test
SQL
Structured Query Language
Js
JavaScript
6
1.
Release Control
El código se almacenará en GitHub, cada vez que se agreguen nuevos módulos se probarán y se agregará
la descripción de los cambios en el comentario del commit. Al final se realizará una prueba Big Bang
para probar que todo funcione de manera correcta.
2.
Análisis de Riesgo
Número
Descripción
Probabilidad/
Impacto
Prioridad
(P*I)
1
Uno de los integrantes del equipo se enferma o se lesiona.
Alta/Medio
6
2
La base de código del desarrollo de aplicación se pierde
en un siniestro de ataque cibernético o fallo del hardware
de almacenamiento donde se encuentra.
Baja/Medio
2
3
La elicitación de requerimientos no determinó
precisamente el modo de implementación de una
característica de la aplicación, provocando su revisión o
reimplementación desde cero.
Media/Alto
6
4
La OSF encuentra un proyecto con mayor potencial de
cumplimiento de las metas empresariales, por lo que deja
de realizar seguimiento oportuno (o del todo) del
proyecto de implementación.
Media/Alto
6
Acciones de mitigación
Contar con planes de salud para los trabajadores, debería haber la disposición para permitir hacer
el proyecto desde casa; en caso de una enfermedad, sería necesario contar con la documentación
necesaria para que otro integrante o un nuevo empleado continúe con sus tareas. (Caso 1)
Utilizar métodos de versionamiento basados en la nube como Github y utilizar medios de
almacenamiento físicos externos como USB, memoria flash o sistemas NAS. (Caso 2)
Desarrollar historias de usuario para delimitar la percepción inicial del cliente y diseñar un
prototipo minimalista con funciones limitadas para ser mostrado al cliente. De tal suerte que el
cliente evalúe y confirme la percepción anterior de los requerimientos plasmados en las historias
7
de usuario con dicho prototipo. Idealmente, este proceso se realiza por cada módulo o con
prioridad en los requerimientos críticos para mitigar el impacto sobre los objetivos de la empresa
y el desarrollo del proyecto. (Caso 3)
Documentar y almacenar el proyecto para que otro equipo de desarrolladores pueda continuar su
implementación en el futuro. Generar una memoria técnica del proyecto a medida que el
proyecto se desarrolla. (Caso 4)
3.
Revisión y Aprobaciones
Las actividades y los cambios son revisados y aprobados por el equipo de desarrollo.
El resumen de los cambios se puede encontrar en el log del repositorio en el que se encuentra el
código.
Muchos desarrolladores podrían estar realizando cambios al mismo tiempo, por lo que se
trabajará por ramas, cuyo desarrollo será supervisado antes de ser unido a la rama principal o se
hablará con el desarrollador en caso de encontrar alguna falla o incompatibilidad.
Las revisiones se realizan de manera semanal y se hablarán tanto de manera individual
(desarrollador - supervisor) como en equipo, para que exista la mejor comunicación posible.
8