Plan de Pruebas
| Date | Version | Description |
|---|---|---|
| 26/02/2023 | 0.1 | Creación del Doc SRS |
| 02/04/2023 | 1 | Plan de Pruebas by Pulse Studios |
El objetivo del presente documento, es proveer una propuesta respecto a las pruebas de software necesarias para el desarrollo y la funcionalidad correcta de la aplicación web de adquisición de autos. Estas contribuirán en la creación de un producto con un control de calidad alto por lo que serán detalladas y argumentadas en este escrito.
En cuanto al plan de pruebas que se realizará, este incluirá la especificación de elementos de software que serán probados, el nivel y la secuencia en la que serán probados, los criterios de salida y la manera en la que se aplicará la estrategia en el ambiente de pruebas. Junto con lo anterior, se considerarán los siguientes puntos:
- Lo que está dentro y fuera del alcance
- Supuestos
- Roles y responsabilidades del equipo QA
- Herramientas
- Entregables
- Gestión de Defectos
- Riesgos
- Calendario
Es relevante recalcar que el presente documento será organizado de manera que se especifiquen claramente las dos vertientes principales de pruebas: dinámicas y estáticas.
El proyecto que será desarrollado por Pulse Technologies, se trata de una solución para grupos automotrices y compradores de autos en donde se permitirá digitalizar una parte del proceso de compra, evitando visitas excesivas a las agencias. Dicha solución está planteada como una aplicación web que permitirá a los usuarios interactuar con el agente, explorar distintas opciones de autos, obtener cotizaciones estimadas automáticamente, comparar autos, subir y editar sus documentos, solicitar pruebas de manejo y mantener un seguimiento adecuado (con la misma calidad de atención que en una agencia tradicional) de sus compras.
La aplicación beneficiará a los clientes de las agencias ya que les ahorrará tiempo, les proporcionará opciones de distintas marcas y agencias (con distintos planes de financiamiento) en una misma plataforma, y les permitirá tener una visión más clara de lo que quieren. Asimismo, beneficiará a las agencias y grupos automotrices, dándoles un espacio en el que tendrán visibilidad, la posibilidad de agilizar ciertos procesos (como lo es el de la entrega de documentos del cliente) para poder atender a más clientes y la posibilidad de obtener ciertas estadísticas que les podrán ayudar a analizar sus ventas.
En cuanto a la audiencia, es necesario separar claramente a las entidades involucradas para las pruebas dinámicas y para las pruebas estáticas.
Puesto a que las pruebas dinámicas requieren de la ejecución del código, su audiencia principal son los desarrolladores (quienes generan en código, lo modifican y verifican que funcione dicho código). De igual manera, aquellos encargados de diseñar las pruebas estarán involucrados en las pruebas dinámicas ya que tendrán que planearlas.
En cuanto a las pruebas estáticas - que se basan en la revisión de productos de trabajo sin código -, estas involucrarán a los encargados de diseñar las pruebas (ya que mediante la revisión del trabajo podrán planear mejores pruebas), al Product Owner (quien tiene la visión de la perspectiva del cliente por lo que puede evaluar si se cumplen las necesidades del mismo), el Project Manager (quien supervisará que se lleve a cabo el proyecto correctamente y se entreguen las pruebas adecuadas), y cualquier otro participante del producto que quiera revisar los documentos y asegurar la calidad del mismo.
Etapa 1 – Comprensión de los Requerimientos, Especificaciones del Proyecto y Pruebas Estáticas:
Antes de crear una estrategia de pruebas, primero se comprenden y establecen de manera detallada los requerimientos del proyecto. Para ello se tiene una serie de interacciones semanales con el cliente NDS en el cual se documentan de forma clara las características de la solución que cumplen con sus necesidades y objetivos. Al finalizar esta etapa se espera que haya pocos o nulos cambios, ya que el resto del proyecto se desarrollará en base a lo establecido en esta etapa, por lo cuál queda fuera de las etapas de iteración.
Etapa 2 - Pruebas Informales:
En un principio, se comenzará realizando pruebas informales durante el desarrollo del software. Esto incluiría pruebas realizadas individualmente por cada uno de los desarrolladores sin supervisión, teniendo un enfoque en comprobar la funcionalidad de componentes creados. En esta etapa comienza el proceso iterativo de las pruebas y va dentro de las pruebas dinámicas.
Etapa 3 – Realización de Pruebas Unitarias:
Esta etapa también va dentro de las pruebas dinámicas y se pretende comenzar realizando las pruebas unitarias para cada componente de software de la plataforma. Esto concentrándose en pruebas de caja negra (black box tests) tomando especial atención en la entrada y salida esperadas en su correcto funcionamiento. Simultáneamente a esto, se acordará de manera iterativa con NDS las pruebas de historias de usuario van de acuerdo a sus criterios de aceptación. Esto ayudará a garantizar que la página web satisfaga correctamente las necesidades de NDS y de sus clientes.
Etapa 4 - Pruebas de Caja Blanca de cobertura (White Box Testing):
En esta etapa, que también va dentro de las dinámicas, se realizan las pruebas de caja blanca a los componentes definidos en este documento, especialmente dando prioridad a aquellos componentes que generaron errores en las Pruebas de Caja Negra. De esta manera, se podrá analizar el código de dichos componentes, así permitiendo arreglar errores persistentes en pruebas anteriores o eliminar redundancias. Para hacer más eficaz nuestro proceso de pruebas de caja blanca, usaremos la técnica de cobertura en donde se probaran los caminos más utilizados para hacer uso de cada función de cada tipo de usuario.
Etapa 5 - Pruebas de Integración:
En esta etapa, que es la última dentro de las etapas dinámicas, después de que todas las pruebas unitarias hayan pasado con éxito se pasan a las pruebas de integración donde de manera ascendente se van uniendo los diferentes componentes para validar su correcto funcionamiento en conjunto. Las pruebas de integración se llevarán a cabo mediante pruebas de caja negra de casos de uso aleatorias, las cuales serán elegidas y supervisadas por el Project Manager responsable del equipo de desarrollo.
Etapa 6 – Pruebas de Validación/Aceptación:
En esta etapa, se requiere que haya pocos o ningún cambio, ya qué, después de que las pruebas de integración hayan sido exitosas se realizan las pruebas de validación en las que se revisará con el cliente NDS que los criterios de validación definidos en etapas anteriores se cumplen hasta el momento del proceso de pruebas.
Etapa 7 – Pruebas de Estática de Recorridos:
Una vez que se haya tenido la aprobación de NDS se realizará la prueba del funcionamiento del sistema como un todo, verificando el comportamiento y correcto funcionamiento de toda la plataforma en el nivel más alto posible.
Etapa 8 - Manual de Usuario:
En esta etapa, una vez que se haya completado las etapas anteriores y son pocos o nulos los cambios, se crea el manual de usuario en el que se le proveerá información e instrucciones al usuario de cómo usar el software desarrollado. En el manual de usuario se incluirán los caminos previamente establecidos en las pruebas de caja blanca de cobertura. El manual toma en cuenta la versión más actualizada y funcional de la aplicación.
Es relevante mencionar, que en esta estrategia se mantiene un flujo iterativo, donde de ser necesario se actualizará el documento de pruebas o se podrá regresar a etapas de pruebas anteriores para así solucionar cualquier fallo o error en cualquier nivel de la plataforma.
El flujo de las pruebas se puede observar a continuación:
Etapa 9 - Pruebas de estrés Como etapa final, se realizarán pruebas de estrés para comprobar el correcto funcionamiento de la aplicación en situaciones de alta carga de usuarios. Para esto se utilizará una herramienta como JMeter, la cual permite simular un gran número de usuarios simultáneos, y comprobar el correcto funcionamiento de la aplicación en dichas situaciones. Estas pruebas serviran como "benchmark" para medir el rendimiento de la aplicación, y su capacidad de soporte.
El objetivo de las pruebas que se realizarán durante el transcurso del proyecto es la validación de las funcionalidades fundamentales de la aplicación, al igual que comprobar la correcta implementación de los requerimientos establecidos en el documento SRS. En consideración de este objetivo, las pruebas a realizarse comprenderán:
- Pruebas que aseguren la correcta autorización de usuarios, al igual que la asignación de los premios asociados.
- Pruebas que comprueben el correcto funcionamiento en la búsqueda y filtrado del catálogo de autos.
- Pruebas que comprueben el correcto funcionamiento del guardado de automóviles en la base de datos.
- Pruebas que garanticen el funcionamiento de la recopilación, análisis, y generación de estadística relacionada con usuarios agentes de la aplicación.
- Pruebas relacionadas al servicio de chat implementado en la aplicación. Pruebas con el objetivo de comprobar el correcto funcionamiento del proceso de compra de un automóvil.
- Pruebas asociadas a la creación de usuarios con diferentes permisos.
- Pruebas asociadas al funcionamiento de un software estable y listo para producción.
- Se dará prioridad a las pruebas funcionales debido a limitantes de tiempo y presupuesto.
- Todas las pruebas se harán en el mismo ambiente.
- Todas las pruebas se harán inicialmente con pruebas Informales y posteriormente en Caja Negra.
- Las pruebas funcionales serán las más relevantes del plan de pruebas.
- Realizar las mismas pruebas conlleva a los mismos resultados.
- Las pruebas con variedad en el rol de acceso no son equivalentes, y debe definirse una prueba por cada rol.
- Si el ambiente de pruebas deja de estar disponible; el equipo de pruebas creará uno lo más similar lo antes posible.
- Todas las funciones han sido probadas meticulosamente.
- Las pruebas de caja blanca y pruebas paso a paso solo se ejecutarán si los resultados son distintos a lo esperado.
- El equipo de pruebas documentará sus resultados de acuerdo a lo evaluado.
- El equipo de pruebas asume que todas las entradas o inputs requeridos durante el diseño y la ejecución de las pruebas estarán apoyados por el desarrollador/analista respectivamente.
- Todos los documentos personales del usuario serán guardados con el mismo formato y nomenclatura.
- El PM verificará los resultados de todas las pruebas efectuadas.
- El PM aprueba todos los casos de prueba propuestos previo a la ejecución de los mismos
- El equipo de pruebas manejará todo el esfuerzo de ejecución de prueba de forma coordinada con el PM.
- El recorrido y manual de usuario se realizará en los últimos sprints.
Flujo del Cliente:
- Probar la funcionalidad de Login.
- Probar la funcionalidad de búsqueda de catálogo.
- Probar la funcionalidad de filtrado de catálogo.
- Probar la funcionalidad del agendado de la prueba de manejo.
- Probar la funcionalidad de la subida de documentos para la solicitud de prueba de manejo.
- Probar la funcionalidad de la subida de documentos para la compra de un auto.
- Probar la funcionalidad de la transacción del pago para la prueba de manejo.
- Probar la funcionalidad de la transacción de la compra de auto.
- Probar la funcionalidad del seguimiento de acciones del usuario (prueba de manejo o compras).
- Probar la funcionalidad del sistema de Chat.
- Probar la funcionalidad del sistema de favoritos (wishlist).
- Probar la funcionalidad de la edición de datos en el perfil.
Flujo del Super Administrador:
- Probar la funcionalidad de Login.
- Probar la funcionalidad de búsqueda de usuarios.
- Probar las funcionalidad de filtrado de usuarios.
- Probar la funcionalidad de la modificación de datos de un grupo automotriz.
- Probar la funcionalidad de la búsqueda de solicitudes.
- Probar la funcionalidad del filtrado de solicitudes.
- Probar funcionalidad de la aprobación/negación de una solicitud.
- Probar la funcionalidad del registro de un grupo automotriz.
- Probar la funcionalidad del dashboard estadístico.
Flujo del Grupo Automotriz:
Etapa 1:
- Probar funcionalidad del Login.
- Probar funcionalidad para realizar una aplicación.
- Probar funcionalidad del panel de seguimiento a una aplicación.
- Probar funcionalidad de la modificación de los datos del perfil.
- Probar funcionalidad de la eliminación de una cuenta.
Etapa 2:
- Probar funcionalidad de Login.
- Probar funcionalidad del registro de una agencia.
- Probar funcionalidad de la búsqueda de usuarios.
- Probar funcionalidad del filtrado de usuarios.
- Probar funcionalidad para la modificación de datos de una agencia.
- Probar funcionalidad del registro de un gerente.
- Probar funcionalidad para la modificación de datos de un gerente.
- Probar funcionalidad del dashboard estadístico.
Flujo del Gerente:
- Probar funcionalidad de Login.
- Probar funcionalidad de la búsqueda de usuarios.
- Probar funcionalidad del filtrado de usuarios.
- Probar funcionalidad del registro de un vendedor.
- Probar funcionalidad para la modificación de datos de un vendedor.
- Probar funcionalidad para la actualización/modificación del catálogo de autos.
- Probar funcionalidad del dashboard estadístico.
Flujo del Vendedor:
- Probar funcionalidad del Login.
- Probar la funcionalidad de búsqueda de catálogo.
- Probar la funcionalidad de filtrado de catálogo.
- Probar la funcionalidad de la búsqueda de solicitudes.
- Probar la funcionalidad del filtrado de solicitudes.
- Probar funcionalidad del manejo de una solicitud.
- Probar funcionalidad del sistema de chat.
- Probar funcionalidad del dashboard estadístico.
Evaluación de estrés:
- Probar la funcionalidad de Login con una cantidad grande de usuarios simultáneamente.
- Probar la funcionalidad de búsqueda de catálogo con una cantidad grande de usuarios simultáneamente.
- Probar la funcionalidad de filtrado de catálogo con una cantidad grande de usuarios simultáneamente.
- Probar la funcionalidad de la búsqueda de solicitudes con una cantidad grande de usuarios simultáneamente.
- Probar la funcionalidad del filtrado de solicitudes con una cantidad grande de usuarios simultáneamente.
- Probar funcionalidad del manejo de una solicitud con una cantidad grande de usuarios simultáneamente.
En la siguientes tablas se resumen los requerimientos y componentes que serán probados a través de diferentes recorridos:
| Clave | Objeto | Usuario | Descripción | Prioridad |
|---|---|---|---|---|
| P_V_001 | Landing Page - Busqueda - Listado - Login | Usuario Final | Recorrido desde cuando el usuario entra a la plataforma y se le pide que inicie sesión solamente a la hora de que quiere continuar con la compra de un auto | Media |
| P_V_002 | Landing Page - Login - Busqueda - Listado - Inicio de Proceso de Compra | Usuario Final | Recorrido desde cuando el usuario entra a la plataforma, inicia sesión en la página de login, busca el coche que quiere comprar e inicia el proceso de compra | Alta |
| P_V_003 | Landing Page - Busqueda - Comparar autos | Usuario Final | Recorrido cuando el usuario utiliza la plataforma para la comparación de autos sin iniciar sesión | Media |
| P_V_004 | Landing Page - Login - Búsqueda - Inicio de Venta - Comunicación con Agente - Subida de Documentos - Pago de contado - Finalización de Compra | Usuario Final | Recorrido completo desde que el usuario inicia sesión hasta que finaliza su proceso de compra. Este proceso será una simulación ya que la comunicación con el vendedor puede durar varios días. | Alta |
| P_V_005 | Login - Página Principal - Lista de órdenes de compra - Chat con el cliente | Usuario Vendedor | Recorrido como vendedor de iniciar sesión, seleccionar una órden de compra y mandar un mensaje a un cliente | Alta |
| P_V_006 | Login - Página Principal - Página de Listado - Agregar un Coche | Usuario Gerente | Recorrido de cómo un gerente de una agencia agrega autos al catálogo | Alta |
| P_V_007 | Login - Página Principal - Solicitar creación de usuario gerente | Usuario Grupo Automotriz | Recorrido que seguiría un usuario de grupo automotriz para solicitar la creación de un nuevo gerente de una agencia | Alta |
| P_V_008 | Login - Página Principal - Aceptar la solicitud de dada de alta de un grupo automotriz | Usuario Administrador de la Plataforma | Recorrido como usuario administrador de la plataforma que se seguirá para aceptar la solicitud de dada de alta de un grupo automotriz | Alta |
Flujo del Cliente:
1. Probar la funcionalidad de Login.
- Acceso válido con Credenciales correctas de super-administrador.
- Acceso no autorizado con correo invalido/cuenta inexistente.
- Acceso no autorizado con contraseña incorrecta.
2. Probar la funcionalidad de búsqueda de catálogo.
- Se hace una búsqueda de un auto dentro del catálogo
- El sistema muestra los resultados de los autos segun la búsqueda
3. Probar la funcionalidad de filtrado de catálogo.
- Dentro de la búsqueda de un auto del catálogo se muestran los filtros disponibles para la búsqueda
- Se seleccionan los filtros deseados
- El sistema muestra los resultados de los autos según los filtros aplicados
4. Probar la funcionalidad del agendado de la prueba de manejo.
- El usuario cliente selecciona el auto de su preferencia para solicitar una prueba de manejo
- Para poder solicitar la prueba es necesario que llene un formulario y suba los documentos necesarios
- Una vez completado lo anterior su solicitud se confirma y automáticamente se le asigna un usuario vendedor que le dará seguimiento a su solicitud
- El usuario vendedor se pone en contacto con el cliente a través del chat de la plataforma, en caso de que tenga dudas, además puede ver el estatus de su solicitud en un apartado donde se listaran las solicitudes del cliente
- El vendedor revisa los documentos de la solicitud, si están correctos se aprueban, de lo contrario el vendedor le tiene que notificar al cliente para que pueda volver a subir sus documentos correctamente
- Una vez que los documentos son aprobados por el vendedor, en caso de que el auto seleccionado se requiera pagar una cuota para la prueba de manejo, se hace la transacción necesaria
- Una vez completada la transacción el cliente agenda su prueba de manejo
5. Probar la funcionalidad de la subida de documentos para la solicitud de prueba de manejo.
- El usuario cliente selecciona el auto de su preferencia para solicitar una prueba de manejo
- El cliente llena el formulario con los datos necesarios y sube los documentos que se le piden
- El vendedor revisa los documentos de la solicitud, si están correctos se aprueban, de lo contrario el vendedor le tiene que notificar al cliente para que pueda volver a subir sus documentos correctamente
6. Probar la funcionalidad de la subida de documentos para la compra de un auto.
- El usuario cliente selecciona un vehículo y solicita comprarlo
- Para poder solicitar la comprar es necesario que llene un formulario y suba los documentos necesarios
- Después de subirlos se le asignará un vendedor quien revisará sus documentos y le dará seguimiento a su compra
- Una vez que complete esto el cliente puede ver el estatus de su solicitud en un apartado donde se listaran sus solicitudes
- El vendedor al revisar los documentos si están correctos los aprueba y puede continuar con el proceso de compra, de lo contrario le tiene que notificar al usuario para que los vuelva a subir
7. Probar la funcionalidad de la transacción del pago para la prueba de manejo.
- Una vez que los documentos de la prueba de manejo fueron aprobados, si el vehículo necesita una cuota para realizar la prueba se le notifica al cliente
- El cliente revisa el seguimiento de su solicitud y hace el pago
- Una vez que termina el pago el sistema le confirma de recibido el pago y se actualiza el seguimiento
8. Probar la funcionalidad de la transacción de la compra de auto
- Una vez que los documentos de la compra fueron aprobados, se le notifica al cliente para pueda realizar el pago del vehículo
- El cliente revisa el seguimiento de su solicitud y hace el pago
- Una vez que termina el pago el sistema le confirma de recibido el pago y se actualiza el seguimiento
9. Probar la funcionalidad del seguimiento de acciones del usuario (prueba de manejo o compras).
- Una vez que el cliente sube los documentos necesarios ya sea para la prueba de manejo o para la compra de un auto puede realizar el seguimiento de su solicitud
- En el apartado indicado de seguimiento, puede ver en qué fase va su solicitud
- Mientras el vendedor asignado a su solicitud la revisa y mientras va avanzando el proceso el vendedor va actualizando la etapa en la que se encuentra el cliente
10. Probar la funcionalidad del sistema de Chat.
- Entrada a la vista de chats y contactos con acceso de cliente
- El cliente revisa si tiene algún mensaje
- Selecciona una conversación iniciada
- El vendedor y el cliente pueden tener un medio de contacto directo
11. Probar la funcionalidad del sistema de favoritos (wishlist).
- Se muestra el catálogo de autos
- Si al cliente le interesa algún auto lo marca como favorito
- En el apartado indicado el cliente puede revisar su lista de favoritos con los autos que marcó previamente
12. Probar la funcionalidad de la edición de datos en el perfil.
- El cliente puede acceder a los ajustes de su cuenta en el apartado indicado
- Dentro de los ajustes puede seleccionar la opción de modificar sus datos
- Al entrar a la opción modifica los datos necesarios y al final selecciona el botón de guardar cambios
- Los datos se actualizan tanto en la vista del cliente, como en la base de datos
Flujo del Super Administrador:
1. Probar la funcionalidad de Login.
- Acceso válido con Credenciales correctas de super-administrador
- Acceso no autorizado con correo invalido/cuenta inexistente
- Acceso no autorizado con contraseña incorrecta
2. Probar la funcionalidad de búsqueda de usuarios.
- Se hace una búsqueda de un usuario dentro del catálogo
- El sistema muestra los resultados de los usuarios según la búsqueda
3. Probar las funcionalidad de filtrado de usuarios.
- Dentro de la búsqueda de usuarios se muestran los filtros disponibles para la búsqueda
- Se seleccionan los filtros deseados
- El sistema muestra los resultados de lo usuarios según los filtros aplicados
4. Probar la funcionalidad de la modificación de datos de un grupo automotriz.
- Se accede a la página de la cuenta del grupo automotriz con acceso de super-administrador
- Se efectúa un cambio de la información del grupo automotriz desde la página de la cuenta.
- Se guardan los cambios de la cuenta del grupo automotriz.
5. Probar la funcionalidad de la búsqueda de solicitudes.
- Se hace una búsqueda de una solicitud dentro del catálogo
- El sistema muestra los resultados de las solicitudes y sus estados
6. Probar la funcionalidad del filtrado de solicitudes.
- Dentro de la búsqueda de solicitudes se muestran los filtros disponibles para la búsqueda
- Se seleccionan los filtros deseados
- El sistema muestra los resultados de las solicitudes según los filtros aplicados (aprobada/pendiente/denegada)
7. Probar funcionalidad de la aprobación/negación de una solicitud.
- Se elige una solicitud pendiente con acceso de super-administrador
- Se efectúa la aprobación de una solicitud en espera
- Se efectúa la negación de una solicitud en espera
8. Probar la funcionalidad del registro de un grupo automotriz.
- Se accede al landing-page de creación de grupo automotriz.
- Creación exitosa de un grupo automotriz
- Acceso exitoso a la cuenta del grupo automotriz
9. Probar la funcionalidad del dashboard estadístico.
- Acceso al dashboard con una cuenta de nivel valido muestra las estadísticas y métricas de la plataforma
- Las estadísticas son válidas y representativas de los datos dentro del sistema
- Las opciones y parámetros presentes dentro de la vista permiten ver estadísticas particulares de acuerdo a la selección de las mismas.
Flujo del Grupo Automotriz:
Etapa 1:
Probar funcionalidad del Login.
- Acceso válido con Credenciales correctas de super-administrador
- Acceso no autorizado con correo invalido/cuenta inexistente
- Acceso no autorizado con contraseña incorrecta
Probar funcionalidad para realizar una aplicación.
- Publicación válida de documentos.
- Publicación válida de datos.
- Subida de la creación de la aplicación en la plataforma.
Probar funcionalidad del panel de seguimiento a una aplicación
- Es posible eliminar los archivos subidos.
- Es posible volver a subir archivos después de haber eliminado los mismos.
- Es posible modificar la información subida.
- los cambios realizados a la aplicación se guardan correctamente.
Probar funcionalidad de la modificación de los datos del perfil.
- Es posible eliminar y reescribir cada rubro en la información del perfil.
- Los cambios se guardan correctamente.
Probar funcionalidad de la eliminación de una cuenta.
- El sistema muestra una opción para borrar la cuenta.
- El sistema verifica que el usuario desea eliminar su cuenta.
Etapa 2:
Probar funcionalidad de Login.
- Acceso válido con Credenciales correctas de super-administrador
- Acceso no autorizado con correo invalido/cuenta inexistente
- Acceso no autorizado con contraseña incorrecta
Probar funcionalidad del registro de una agencia.
- Se accede al landing-page de creación de una agencia
- Creación exitosa de una agencia
- Acceso exitoso a la cuenta de la agencia
Probar funcionalidad de la búsqueda de usuarios.
- Se hace una búsqueda de un usuario dentro del buscador.
- El sistema muestra los resultados de los usuarios encontrados según la búsqueda.
Probar funcionalidad del filtrado de usuarios.
- Dentro de la búsqueda se muestran los filtros disponibles para la búsqueda.
- Se seleccionan los filtros deseados.
- El sistema muestra los resultados de los usuarios según los filtros aplicados.
Probar funcionalidad para la modificación de datos de una agencia.
- Se accede a la página de la cuenta de la agencia.
- Se efectúa un cambio de la información de la agencia desde la página de la cuenta.
- Se guardan los cambios de la cuenta de la agencia.
Probar funcionalidad del dashboard estadístico.
- Acceso al dashboard con una cuenta de nivel valido muestra las estadísticas y métricas de la plataforma
- Las estadísticas son válidas y representativas de los datos dentro del sistema.
- Las opciones y parámetros presentes dentro de la vista permiten ver estadísticas particulares de acuerdo a la selección de las mismas.
Probar funcionalidad del registro de un gerente.
- Se accede al landing-page de creación de un gerente.
- Creación exitosa de un gerente
- Acceso exitoso a la cuenta del gerente.
Probar funcionalidad para la modificación de datos de un gerente.
- Se accede a la página de la cuenta del gerente.
- Se efectúa un cambio de la información del gerente desde la página de la cuenta.
- Se guardan los cambios de la cuenta del gerente.
Flujo del Gerente:
Probar funcionalidad de Login.
- Acceso válido con Credenciales correctas de super-administrador.
- Acceso no autorizado con correo invalido/cuenta inexistente.
- Acceso no autorizado con contraseña incorrecta. Probar funcionalidad de la búsqueda de usuarios.
- Se hace una búsqueda de un usuario dentro del buscador.
- El sistema muestra los resultados de los usuarios encontrados según la búsqueda.
Probar funcionalidad del filtrado de usuarios.
- Dentro de la búsqueda se muestran los filtros disponibles para la búsqueda.
- Se seleccionan los filtros deseados.
- El sistema muestra los resultados de los usuarios según los filtros aplicados.
Probar funcionalidad del registro de un vendedor.
- Se accede al landing-page de creación de un vendedor.
- Creación exitosa de un vendedor.
- Acceso exitoso a la cuenta del vendedor.
Probar funcionalidad para la modificación de datos de un vendedor.
- Se accede a la página de la cuenta del vendedor.
- Se efectúa un cambio de la información del vendedor desde la página de la cuenta.
- Se guardan los cambios de la cuenta del vendedor.
Probar funcionalidad para la actualización/modificación del catálogo de autos.
- Se presenta la opción de agregar un auto.
- Se suben correctamente las imágenes.
- Se suben correctamente los datos ingresados.
- Se presenta la opción de editar un auto.
- Se reemplazan correctamente las imágenes previamente subidas por las nuevas.
- Es posible cambiar cada rubro de la información de un auto.
- Se guarda correctamente la publicación del auto o la modificación según sea el caso.
Probar funcionalidad del dashboard estadístico.
- Acceso al dashboard con una cuenta de nivel valido muestra las estadísticas y métricas de la plataforma
- Las estadísticas son válidas y representativas de los datos dentro del sistema.
- Las opciones y parámetros presentes dentro de la vista permiten ver estadísticas particulares de acuerdo a la selección de las mismas.
Flujo del Vendedor:
1. Probar funcionalidad del Login.
- Acceso válido con Credenciales correctas de vendedor
- Acceso no autorizado con correo invalido/cuenta inexistente
- Acceso no autorizado con contraseña incorrecta
2. Probar la funcionalidad de búsqueda de catálogo.
- Se hace una búsqueda de un auto dentro del catálogo
- El sistema muestra los resultados de los autos segun la búsqueda
- Probar la funcionalidad de filtrado de catálogo.
- Dentro de la búsqueda de un auto del catálogo se muestran los filtros disponibles para la búsqueda
- Se seleccionan los filtros deseados
- El sistema muestra los resultados de los autos según los filtros aplicados
3. Probar la funcionalidad de la búsqueda de solicitudes.
- Se hace una búsqueda de una solicitud dentro del catálogo
- El sistema muestra los resultados de las solicitudes y sus estados
4. Probar la funcionalidad del filtrado de solicitudes.
- Dentro de la búsqueda de solicitudes se muestran los filtros disponibles para la búsqueda
- Se seleccionan los filtros deseados
- El sistema muestra los resultados de las solicitudes según los filtros aplicados (aprobada/pendiente/denegada)
5. Probar funcionalidad del manejo de una solicitud.
- Se elige una solicitud
- Dentro de la vista de solicitud se modifica la etapa de proceso.
6. Probar funcionalidad del sistema de chat.
- Entrada a la vista de chats y contactos con acceso de vendedor
- Selección de una conversación iniciada
- Creación de una conversación desde vista de contacto
- Enviar mensaje al cliente
7. Probar funcionalidad del dashboard estadístico.
- Acceso al dashboard con una cuenta de nivel valido muestra las estadísticas y métricas de la plataforma
- Las estadísticas son válidas y representativas de los datos dentro del sistema* Las opciones y parámetros presentes dentro de la vista permiten ver estadísticas particulares de acuerdo a la selección de las mismas.
A continuación se muestran el nivel de las pruebas que se realizarán durante el desarrollo del proyecto, además de detallar algunas de los métodos que se utilizaran al igual que los responsables de dichas pruebas.
El propósito de este tipo de pruebas es verificar rápidamente el funcionamiento de los componentes del software. Las pruebas de este estilo no tienen ningún tipo de entrega.
- Alcance: Todas las secciones desarrolladas serán probadas mediante pruebas unitarias informales.
- Responsables: Los desarrolladores de software.
- Metodología: Los desarrolladores responsables del componentes se encargaran de realizar pruebas de Input-Output para comprobar su correcto funcionamiento.
- Cada cuando: En cuanto se finalice, o se modifique algún componente.
El propósito de las pruebas unitarias es probar cada uno de los componentes y funcionalidades que comprenden la aplicación que se desarrollará.
- Alcance: Todas las secciones desarrolladas serán probadas mediante pruebas de caja negra.
- Responsables: Los desarrolladores de software y los testers.
- Metodología: Los desarrolladores probarán componentes de la aplicación sin tener conocimiento del código detrás de los mismos componentes, reportando errores en caso de encontrarlos. Específicamente, el tipo de pruebas de caja negra que se realizarán serán pruebas de tipo de casos de uso. Dentro de estas pruebas se realizarán tres baterías negativas y tres baterías positivas que se deberán cumplir cuando se realicen este tipo de pruebas.
- Cada cuándo: Al finalizar cada componente.
| Criterio de Entrada | Equipo de Prueba | Equipo Técnico | Notas |
|---|---|---|---|
| - El equipo de cómputo es completamente funcional, y configuración. | |||
- Los paquetes requeridos están instalados y disponibles en el equipo de computo. |
|||
| - La librería de pruebas está disponible y funcional en el equipo de cómputo. | |||
| - El ambiente de pruebas está configurado y funcional en el equipo de cómputo. |
El propósito de este tipo de pruebas es encontrar la causa de algún tipo de falla que se haya encontrado en otro tipo de pruebas. En específico, las pruebas de caja blanca que se realizan son pruebas de cobertura, es decir, se probarán los tres caminos más utilizados por los usuarios. Más aún, se considerará que los caminos seleccionados son apropiados si estos cubren un mínimo de 80% de los caminos posibles. Este 80% debe regresar resultados de prueba positivos para así justificar que el componente funciona de manera correcta.
- Alcance: Cualquier componente de software que presente alguna falla dentro de algún otro tipo de prueba.
- Responsables: Los desarrolladores de software y los testers.
- Metodología: Los desarrolladores que se encargaron de crear los componentes en donde se encontraron los errores serán los encargados de realizar pruebas de caja blanca con el objetivo de encontrar que pedazo de código es el que está causando dicho error.
- Cada cuándo: Al finalizar cada sprint.
| Criterio de Entrada | Equipo de Prueba | Equipo Técnico | Notas |
|---|---|---|---|
| - El equipo de cómputo es completamente funcional, y configuración. | |||
- Los paquetes requeridos están instalados y disponibles en el equipo de computo. |
|||
| - La librería de pruebas está disponible y funcional en el equipo de cómputo. | |||
| - El ambiente de pruebas está configurado y funcional en el equipo de cómputo. | |||
| - Se tiene acceso completo a todo el código fuente de la aplicación | |||
| - Se tiene acceso a la documentación o código fuente de los paquetes requeridos. | |||
| - Se tiene acceso a los esquemas de bases de datos de la aplicación. |
El propósito de las pruebas de integración es comprobar el correcto funcionamiento de la aplicación cuando todos los componentes son utilizados en conjunto. Para efectos de este proyecto, debido a las restricciones de tiempo, este tipo de pruebas sólo serán realizadas en los componentes críticos de la aplicación.
- Alcance: Componentes críticos para el funcionamiento de la aplicación
- Responsables: Los responsables de cada célula de trabajo.
- Metodología: Los desarrolladores responsables de cada célula, al terminar más de un componente relacionado, empezaran a realizar pruebas e integración. De la misma manera, al terminar el proyecto, se realizarán nuevas pruebas de este estilo.
- Cada cuándo: Al terminarse pedazos de software relacionados y al acabar todos los componentes de la aplicación.
| Criterio de Entrada | Equipo de Prueba | Equipo Técnico | Notas |
|---|---|---|---|
| - Las máquinas virtuales (GCP Compute Engine) están disponibles y corriendo. | |||
| - Los paquetes requeridos están instalados y disponibles en las máquinas virtuales. | |||
| - Las bases de datos están instanciadas, y con el esquema. | |||
| - La librería de pruebas está disponible en el equipo de computo. | |||
| - El ambiente de pruebas está configurado y corriendo. |
El propósito de este tipo de pruebas es validar con el equipo de desarrollo y NDS si el sistema está a la par con sus expectativas y cumple las funcionalidades que fueron discutidas en el documento SRS.
- Alcance: Todos los aspectos del pedazo de software serán probados pruebas de validación. Esto con el objetivo de revisar si aspectos de diseño y funcionalidad de la aplicación están a la par de las expectativas de NDS.
- Responsables: Rubén Raya (NDS), los desarrolladores, los testers y el SCRUM master..
- Metodología: Los desarrolladores se reunirán con Rubén Raya y bajo su supervisión se encargará de validar los aspectos importantes de la aplicación desarrollada.
- Cada cuándo: En cuanto se cumplan las pruebas de integración.
| Criterio de Entrada | Equipo de Prueba | Equipo Técnico | Notas |
|---|---|---|---|
| - Las máquinas virtuales (GCP Compute Engine) están disponibles y corriendo. | |||
| - Los paquetes requeridos están instalados y disponibles en las máquinas virtuales. | |||
| - Las bases de datos están instaladas, y con el esquema. | |||
| - La librería de pruebas está disponible en el equipo de computo. | |||
| - El ambiente de pruebas está configurado y corriendo. |
El propósito de este tipo de pruebas es asegurar que el servicio, en términos de funcionalidad y desempeño, actúe de manera satisfactoria.
- Alcance: Dado que se trata de una prueba de sistema, el software será probado en completud.
- Responsables: Desarrolladores no pertenecientes al proyecto, los testers, el SCRUM master y Rubén Raya (NDS). Un recorrido se considera aceptado una vez que sea aprobado por el equipo de desarrolladores y Rubén Raya. Los responsables del proceso de validación son los desarrolladores no pertenecientes al proyecto, Esteban Castillo y Ruben Raya.
- Metodología: Crear escenarios de acuerdo a las situaciones más usuales de los usuarios.
- Cada cuándo: Al final del proyecto.
El propósito de este tipo de pruebas es asegurar que el servicio, en términos de funcionalidad y desempeño, actúe de manera satisfactoria en terminos de capacidad y velocidad de servicio.
- Alcance: Dado que se trata de una prueba de sistema, el software será probado en completud.
- Responsables: Desarrolladores no pertenecientes al proyecto, testers. Un recorrido se considera aceptado una vez que sea aprobado por el equipo de desarrolladores y Rubén Raya. Los responsables del proceso de validación son los desarrolladores no pertenecientes al proyecto, Esteban Castillo y Ruben Raya.
- Metodología: Crear escenarios de casos de uso que involucren un alto número de usuarios y solicitudes.
- Cada cuándo: Al final del proyecto.
Unitarias, Integración, Aceptación
| Criterio de Salida | Equipo de Prueba | Equipo Técnico | Notas |
|---|---|---|---|
| - Se probaron el 100% de las pruebas establecidas. | |||
| - No existen problemas de nivel severo o crítico. | |||
| - Los problemas de nivel severo o crítico se documentan, así como su solución o delegación. | |||
| - El 100% de los componentes tiene un mínimo de 90% de índice de aprobación. | |||
| - Todas las pruebas arrojan un resultado legible, que después es documentado como su resultado. | |||
| - El equipo de cómputo, así como los componentes involucrados, sigue funcional después de la ejecución de las pruebas. |
Cada desarrollador tiene como responsabilidad realizar una prueba informal a cada componente que finalice. Ya que esta prueba no sigue una metodología específica, el desarrollador sabrá que el componente pasó la prueba si realiza de manera correcta su funcionalidad y trabaja de manera adecuada con otros componentes.
-
Funcionalidad de Login: Esta funcionalidad nunca debe fallar. Todas las pruebas deben proporcionar el usuario y la página de inicio correctos, o bien enviar un mensaje de error indicando que el usuario no existe. Esto para cada tipo de usuario que permite la plataforma.
-
Funcionalidad de Registro: Todas las pruebas deben de crear las credenciales ingresadas de forma correcta en la base de datos o bien enviar un mensaje de error indicando la razón por la cual las credenciales no son permitidas. Igualmente, el registro debe agregar la cuenta con los privilegios y permisos correspondientes a cada tipo de usuario.
-
Funcionalidad CRUD del Catálogo: Todas las pruebas deben permitir la subida, lectura, modificación y eliminación de elementos del catálogo de autos. Esto debe de permitirse acorde a los permisos respectivos a cada tipo de cuenta, respetando los privilegios que conlleva cada una de ellas. Se debe de desplegar el mensaje de error correspondiente, si la información/datos por el usuario no es permitida/correcta.
-
Funcionalidad de Búsqueda del Catálogo: Todas las pruebas deben permitir la búsqueda de los autos dentro del catálogo con uso de lenguaje natural. Para todos los tipos de administradores que tienen acceso al catálogo pueden hacer una búsqueda de los autos que pertenecen a su respectivo grupo automotriz o a su respectiva agencia, para los clientes pueden hacer una búsqueda de todos los autos de todas las agencia. Los resultados mostrados deben ser relacionados a las palabras ingresadas en la barra de búsqueda, si no hay autos relacionados con las palabras ingresadas en la búsqueda, no se mostrarán resultados ya que no hay autos que coincidan.
-
Funcionalidad de Filtrado del Catálogo: Todas las pruebas deben permitir el filtrado de los autos dentro del catálogo con los filtros previamente determinados. Para todos los tipos de administradores que tienen acceso al catálogo pueden hacer un filtrado de la búsqueda de los autos que pertenecen a su respectivo grupo automotriz o a su respectiva agencia, para los clientes pueden hacer un filtrado de la búsqueda de todos los autos de todas las agencia. Los resultados mostrados deben ser según los filtros relacionados, si no hay autos que cumplan con las restricciones de los filtros, no se mostrarán resultados ya que no hay autos que coincidan.
-
Funcionalidad de Búsqueda de Usuarios: Todas las pruebas deben permitir la búsqueda de otros usuarios con uso de lenguaje natural. Para todos los tipos de administradores que tienen acceso a la búsqueda de otros usuarios pueden hacer una búsqueda de los usuarios que pertenecen a su respectivo grupo automotriz o a su respectiva agencia. Los resultados mostrados deben ser relacionados a las palabras ingresadas en la barra de búsqueda, si no hay usuarios relacionados con las palabras ingresadas en la búsqueda, no se mostrarán resultados ya que no hay usuarios que coincidan.
-
Funcionalidad de Filtrado de usuarios: Todas las pruebas deben permitir el filtrado de los usuarios con los filtros previamente determinados. Para todos los tipos de administradores que tienen acceso a la búsqueda de otros usuarios pueden hacer un filtrado de la búsqueda de los autos que pertenecen a su respectivo grupo automotriz o a su respectiva agencia. Los resultados mostrados deben ser según los filtros relacionados, si no hay usuarios que cumplan con las restricciones de los filtros, no se mostrarán resultados ya que no hay usuarios que coincidan.
-
Funcionalidad de Pago: Todas las pruebas deben permitir que el usuario pueda realizar el pago de un auto mediante cada uno de los diferentes métodos de pago que ofrece la plataforma. Se deben de desplegar mensajes ya sea de éxito en la transacción o falla en la misma, indicando al usuario si hay una razón de su lado por la cual no fue posible efectuar el pago.
-
Funcionalidad de Chat: Todas las pruebas deben permitir que el usuario pueda seleccionar a otro usuario y comunicarse con este efectivamente mediante mensajes. Los mensajes enviados deben de ser visibles y mostrarse en la cuenta receptora, con la capacidad de mostrar un mensaje de error indicando al usuario la razón por la cual no se pudo enviar el mismo.
-
Funcionalidad de Favoritos (Wishlist): Todas las pruebas deben permitir que el usuario pueda marcar como “favorito” a todos los autos que desea, así como visualizarlos correctamente en la sección de “wishlist”. Asimismo, el usuario siempre debe de ser capaz de eliminar a cualquier auto de dicha lista, donde los cambios deberán reflejarse correctamente.
-
Funcionalidad Analítica: Todas las pruebas deben permitir que cada tipo de usuario pueda visualizar correctamente las estadísticas e información adecuada para los permisos que le corresponden a dicha cuenta. Esta funcionalidad siempre deberá estar activa, y de haber un error en el lado del servidor, se deberá indicar con un mensaje respectivamente.
-
Manejo de Solicitudes: Todas las pruebas deberán permitir que el usuario en cuestión (Super-Admin y Vendedor) pueda modificar el estado/etapa de cualquier solicitud a su cargo. Asimismo, debe ser posible comentar acerca del estado de una solicitud así informando al aplicante las acciones que debe realizar, o razones que justifican el estado de su solicitud. Finalmente, el usuario que maneja las solicitudes debe de poder negar o aceptar cualquier solicitud. Todo lo descrito anteriormente, debe siempre verse reflejado en la cuenta del usuario aplicante.
-
Compra de un Auto: Todas las pruebas deberán permitir que el cliente tenga la capacidad de comprar un auto exitosamente, y que este pase por las dos posibilidades principales en el proceso de compra, siendo la aceptación o negación de la solicitud. Para ello, el cliente debe ser capaz de seleccionar un auto junto con sus especificaciones, aplicar para la compra del mismo, subir la información y documentos necesarios, darle seguimiento a su solicitud, esperar la aceptación/negación de la misma, efectuar la compra por uno de los métodos de pago disponible, continuar la comunicación con el vendedor el tiempo que sea necesario para finalmente recibir su adquisición.
-
Agendado de la prueba de manejo: Todas las pruebas deberán permitir que el cliente tenga la capacidad de agendar una prueba de manejo exitosamente, y que este pase por las dos posibilidades principales en el proceso de agendado, siendo la aceptación o negación de la solicitud. Para ello, el cliente debe ser capaz de seleccionar un auto, solicitar una prueba de manejo para el mismo, subir la información y documentación necesaria, darle seguimiento a la solicitud, y de ser aceptada seleccionar una fecha, lugar y hora disponible en el horario del vendedor. Asimismo, la comunicación entre el cliente y el vendedor debe de ser posible en todo momento como parte del seguimiento de la prueba de manejo.
- Programa funcional: Los clientes y representantes de los mismos están satisfechos con la funcionalidad revisada así como la experiencia del usuario (UI/UX) de la plataforma.
- Programa adaptado a escenarios de estrés: La plataforma es capaz de manejar un número de usuarios simultáneos que no afecte su rendimiento.
Es posible completar el flujo básico de la plataforma para cada uno de los tipos de usuario, desde el registro, login hasta cada una de sus acciones principales.
La plataforma es capaz de manejar un número de usuarios simultáneos igual o mayor al calculado previamente sin que se vea afectado el funcionamiento y la velocidad
| No. | Nombre del Entregable | Autor | Sprint Esperado | Supervisor |
|---|---|---|---|---|
| 1 | Plan de pruebas | Equipo de prubas | 1 | P.M. y Líder de QA |
| 2 | Casos de pruebas unitarias | Equipo de pruebas | 4 | P.M. y Líder de QA |
| 3 | Caos de pruebas de integración | Equipo de pruebas | 4 | P.M. y Líder de QA |
| 4 | Revisión Técnica | Equipo de pruebas | Cada sprint después del cuarto | Líder de QA/Equipo de pruebas |
| 5 | Reporte de estatus semanal | Equipo de pruebas | Cada sprint después del cuarto | Líder de QA/Equipo de pruebas |
| 6 | Logs de resultados de pruebas | Equipo de pruebas | Cada sprint después del cuarto | Líder de QA/Equipo de pruebas |
| 7 | Reporte de finalización de pruebas | Equipo de pruebas | 9 | P.M. y Líder de QA |
Lista tentativa, sujeta a cambios.
| No. | Tipo de prueba | Ejemplo de prueba | Dependencias |
|---|---|---|---|
| 1 | Prueba unitaria | Conexión de base de datos | Bases de datos finalizadas |
| 2 | Prueba unitaria | Prueba de autenticación de usuario | Módulo de autenticación finalizado |
| 3 | Prueba unitaria | Prueba de registro de usuario | Módulo de registro finalizado |
| 4 | Prueba de integración | Prueba de registro/autenticación de usuario: El usuario es capaz de crear una cuenta y de autenticar esa cuenta | Pruebas unitarias finalizadas: 1, 2, 3 |
| 5 | Prueba unitaria | Prueba de envío de solicitudes | Módulo de solicitudes finalizado |
| 6 | Prueba unitaria | Prueba de validación de solicitudes | Módulo de aceptación de solicitudes finalizado |
| 7 | Prueba de integración | Prueba de manejo de solicitudes: El usuario es capaz de autenticar y enviar una solicitud. El administrador es capaz de autenticar y aceptar/denegar la solicitud | Pruebas unitarias finalizadas: 5, 6 |
| 8 | Prueba unitaria | Prueba de asignación de Gerentes/Vendedores | Módulo de asignación de Gerentes/Vendedores finalizado |
| 9 | Prueba de integración | Prueba de integración de Gerentes/Vendedores: Los privilegios de estas cuentas se ven reflejados en la base de datos | Pruebas unitarias finalizadas: 1, 8 |
| 10 | Prueba unitaria | Prueba de creación de cuentas | Módulo de creación de cuentas finalizado |
| 11 | Prueba de integración | Prueba de integración de creación de cuentas: La cuenta creada se ve reflejada en la base de datos | Pruebas unitarias finalizadas: 1, 10 |
| 12 | Prueba unitaria | Prueba de búsqueda de coches | Finalizado: Página inicial y módulos de búsqueda de página |
| 13 | Prueba de integración | Prueba de integración de búsqueda de coches: Muestar coches filtrados | Pruebas unitarias finalizadas: 1, 12 |
| 14 | Prueba unitaria | Prueba de compra de coches/prueba de manejo | Módulo de tarjeta de coche finalizado |
| 15 | Prueba de integración | Prueba de compra de coche/prueba de manejo: Se puede reservar una prueba de manejo y comprar un coche | Pruebas unitarias finalizadas: 1, 12, 14 |
| 16 | Prueba unitaria | Prueba de subida de modelo | Módulo de subda de modelos finalizado |
| 17 | Prueba de integración | Prueba unitaria de subida de modelo: Se puede subir un coche y se vera reflejado en la base de datos y en la búsqueda de coches | Pruebas unitarias finalizadas: 1, 12, 14, 16 |
| 18 | Prueba unitaria | Prueba unitaria de validación de documentos: Se pueden subir documentos y se recibe un booleano que indique su validez | Módulo de validación de documentos finalizado |
| 19 | Prueba de validación | Hay pocos cambios o nulos. La interfaz está de acuerdo a los estándares del cliente. | Diseño de la interfaz finalizado |
| 20 | Prueba de validación | Hay pocos cambios o nulos. El programa está completo y funciona de acuerdo a los estándares del cliente. | Programa finalizado |
| 21 | Prueba de recorrido | Recorrido de todos los usuarios se puede completar | Bases de datos finalizadas, API finalizada, arquitectura de nube finalizada, conexiones finalizadas, implementación de front-end finalizada, implementación de back-end finalizada |
| 22 | Prueba de estrés | Los cambios en el desempeño de la aplicación son nulos o levemente perceptibles. El programa está completo y funciona con demandas elevadas en la cantidad de usuarios. | Programa adaptado a escenarios de estrés |
Estimación basada en un equipo de 5 personas. Sujeta a cambios.
| Tipo de Prueba | Horas | Días | Porcentaje del Proyecto |
|---|---|---|---|
| SRS | 56 | 7 | 7.72% |
| Plan de Pruebas | 56 | 7 | |
| Recorrido Estático | 24 | 3 |
| Tipo de Prueba | Horas | Días | Porcentaje del Proyecto |
|---|---|---|---|
| Pruebas Informales | N/A | N/A | 10.61% |
| Pruebas de Integración | 28 | 3.5 | |
| Pruebas de Caja Negra | 56 | 7 | |
| Pruebas de Caja Blanca *porcentaje variable dependiendo de qué componentes lo necesiten | 98 | 12.25 |
La estimación de esfuerzos anterior representa un 18.33% del total del proyecto.
| Tipo de Prueba | Horas | Días | Porcentaje del Proyecto |
|---|---|---|---|
| Pruebas de estrés | TBD | TBD | TBD |
En esta sección, se describirá en más detalle el proceso de pruebas, incluidos los riesgos que pueden aparecer, su probabilidad de ocurrir, su impacto en el proyecto y las acciones que podemos tomar para mitigarlos. Además, se describirá con más detalle los roles y expectativas, para que cada miembro del equipo sepa qué hacer en cada fase del proyecto, para minimizar la probabilidad de cometer errores por falta de comunicación.
Además, hay un apartado donde se especifican las herramientas y los plazos considerados para el desarrollo de este proyecto, de forma que los tengamos listos antes de empezar, y todos sepan para qué sirve cada canal de comunicación.
Finalmente, para unir las cosas, también se incluye el diagrama de Gantt, que se compone de las fases de desarrollo y prueba del proyecto.
-
Aprobación del plan de pruebas y funcionamiento del ambiente de pruebas en todos los dispositivos que serán utilizados.
- El ambiente de pruebas se comprueba por medio de una prueba informal que hagan de manera individual los desarrolladores.
-
Siguiendo el cronograma del proyecto y el plan de pruebas, el project manager en conjunto con el líder de pruebas asignará a cada líder sus respectivas pruebas.
-
Conforme se finalicen componentes pero el cronograma no indique una prueba, los desarrolladores estarán a cargo de las pruebas informales, y darles seguimiento.
-
Cuando se indique la ejecución de una prueba, cada líder tiene la responsabilidad de asegurarse de delegar las pruebas a sus equipos y darles seguimiento.
-
Cada desarrollador encargado de una prueba tiene la responsabilidad de documentar su proceso, el resultado de dicha prueba, el seguimiento que se le dará y la corrección de los errores.
-
El desarrollador tiene la responsabilidad de hacer su proceso de QA e informar si se pasa o no la prueba.
-
Primero se ejecutarán las pruebas de caja negra y en caso de que algún componente falle dicha prueba, se aplicará la prueba de caja blanca de cobertura en general y en algún componente crítico camino básico.
-
Una vez que cada componente pase las pruebas unitarias, se ejecutarán las pruebas de integración.
-
-
El desarrollador tiene la responsabilidad de informar a sus respectivos líderes acerca del resultado de las pruebas de sus componentes.
-
Si hay fallas, se le informará a los líderes y al project manager de acuerdo a la gravedad de ellas y se incluirán capturas de pantalla y llenar los formularios propuestos, si es necesario.
-
Este proceso se repite hasta que todos los casos de prueba se ejecuten por completo y tengan un estado en el que ya sea que pasen o fallen.
- Durante el ciclo siguiente, se probarán las pruebas falladas corregidas y los resultados se actualizarán en el documento durante el ciclo hasta que todas las pruebas pasen. El proceso continúa hasta que se llegue a un estándar comercial, promoviendo fiabilidad, fácil acceso y alta estabilidad.
-
Como validacion final, se hará una suerte de métrica por medio de pruebas de estrés, para verificar la estabilidad del sistema y su capacidad de respuesta ante un gran número de usuarios.
| Riesgo | Probabilidad | Impacto | Plan de mitigación |
|---|---|---|---|
| Commits de GitHub poco claros | Media | Bajo | Crear lineamiento de commits, los cuales incluirán instrucciones para presentar cambios, frecuecia y descripciones claras. |
| Falta de información en reportes de pruebas | Media | Medio | Crear plantillas claras y concisas para reportar los resultados de cada tipo de prueba y checar los resultados de manera inmediata tras completar la prueba, para que si alguna información se encuentra faltante, se puede corregir al momento. |
| Not indicar finalización de tareas en la tabla de SCRUM | Media | Bajo | Hacer un recordatorio diario, sea hecho por el PM o con ayuda de un recordatiorio ligado a la tera en la tabla. |
| Inyección de SQL en los campos de campos de entrada | Baja | Alto | Investigar métodos efectivos para la prevención de inyecciones SQL e implementarlos, o usar librerías para prevenirlos. |
| Clientes teniendo privilegios de administrador | Baja | Alto | Separar la infraestructura de clientes y administradores, al igual que encriptar la información de acceso de los administradores. |
| El programa no es capaz de manejar el tráfico | Baja | Alto | Revisar repetidamente el plan de arquitectura y revisar la configuración de la implementación para asegurar que todo se encuentre bien conectado e implementado. |
| Información no es ingresada de manera correcta a la base de datos | Baja | Medio | Durante la etapa de pruebas informales, asegurarse que las queries están estructuradas de manera correcta en la API para que no se envíen queries incorrectas durante el resto de las fases de prueba. |
| Las bases de datos se llenan de manera demasiado rápida | Media | Medio | Limitar número de queries y tamaño de documentos para que no haya documentos demasiado pesados o spam de queries. |
| La infromación no se muestar correctamente en el browser del tester | Media | Medio | Asegurar que el prgrama sea funcional en, como mínimo, 2/3 de los browsers más usados del mercado (por ejemplo, Firefox, Chrome y Opera) |
| Rol | Descripción |
|---|---|
| Project Manager | El miembro que está a cargo de un equipo. Deben organizar y planificar las tareas del equipo para que el proyecto tenga éxito, asegurándose de que se entreguen en tiempo, forma y retroalimentadas. |
| Líder de QA | Miembro del equipo que es responsable de participar y supervisar el desarrollo de las pruebas. Debe de tener en cuenta todos los alcances y criterios de validación de cada prueba para asegurarse de que se cumplan en tiempo y forma. |
| Líder de Back-End | Miembro del equipo que es responsable de participar y supervisar el desarrollo del back-end. Debe coordinar con todos los equipos de desarrollo el avance y los componentes del proyecto, asignar tareas, asegurarse de que se completen en tiempo y forma y coordinarse con el project manager. |
| Líder de Front-End | Miembro del equipo que es responsable de participar y supervisar el desarrollo del front-end. Debe coordinar con todos los equipos de desarrollo, el avance y los componentes del proyecto, asignar tareas, asegurarse de que se completen en tiempo y forma y coordinarse con el project manager. |
| Líder de Base de Datos | Miembro del equipo que es responsable de participar y supervisar el desarrollo de la base de datos. Debe coordinar con todos los equipos de desarrollo, el avance y los componentes del proyecto, asignar tareas, asegurarse de que se completen en tiempo y forma y coordinarse con el project manager. |
| Arquitecto de Software | Miembro del equipo que es responsable de participar y supervisar el desarrollo del back-end y de la nube, asegurandose que se cumplan los lineamientos del stack tecnológico y la arquitectura del software. Debe coordinar con todos los equipos de desarrollo, el avance y los componentes del proyecto, asignar tareas, asegurarse de que se completen en tiempo y forma y coordinarse con el project manager. |
| Equipo de Desarrollo | Célula de trabajo encargada de requerimientos específicos,compuesta de un miembro de back-end, uno de front-end, uno de base de datos, uno de seguridad, de pruebas y un project manager. |
Es importante aclarar que dentro del proyecto presente, todos los involucrados en el desarrollo de la aplicación cumpliran un rol como tester a pesar de las responsabilidades que tengan en otro rol. Por lo antes mencionado, por cada componente que sea finalizado por cualquier persona en el equipo de desarrollo se realizará una prueba informal. De la misma manera, todo el equipo de desarrollo tiene como responsabilidad validar con el cliente los componentes de la aplicación y el entregable final.
La siguiente lista define en términos generales las expectativas relacionadas a los roles que están involucrados con el manejo, planeación o ejecución de la prueba para el proyecto.
Revisa el contenido del plan de pruebas, la estrategia de las pruebas, los estimados, criterios de validación con los equipos de trabajo, líderes y los stakeholders. Recopila la retroalimentación e informa a los demás. Tiene la responsabilidad de darle acompañamiento a las pruebas de caja blanca.
Junto con el project manager, crea y revisa el contenido del plan de pruebas, la estrategia de las pueblas, los estimados y criterios de validación coordinando la ejecución con las actividades programadas en el cronograma del proyecto. Recibe retroalimentación de los equipos de trabajo, líderes y los stakeholders, se asegura que las pruebas se ejecuten en tiempo y forma y documenta el proceso y los resultados.
Junto con el líder de pruebas y el project manager, suma al contenido del plan de pruebas considerando las actividades programadas para el desarrollo del back-end, el avance del mismo y se asegura de la ejecución de las pruebas de sus componentes y que la integración con los otros equipos sea probada y documentada. Se le asignan pruebas, es parte y delega dichas pruebas y se asegura que las funcionalidades críticas de su desarrollo sean consideradas como parte del plan de pruebas. Tiene un seguimiento de las pruebas informales que sus desarrolladores han ejecutado.
Junto con el líder de pruebas y el project manager, suma al contenido del plan de pruebas considerando las actividades programadas para el desarrollo del front-end, el avance del mismo y se asegura de la ejecución de las pruebas de sus componentes y que la integración con los otros equipos sea probada y documentada. Se le asignan pruebas, es parte y delega dichas pruebas y se asegura que las funcionalidades críticas de su desarrollo sean consideradas como parte del plan de pruebas. Tiene un seguimiento de las pruebas informales que sus desarrolladores han ejecutado.
Junto con el líder de pruebas y el project manager, suma al contenido del plan de pruebas considerando las actividades programadas para el desarrollo de la base de datos, el avance de la misma y se asegura de la ejecución de las pruebas de sus componentes y que la integración con los otros equipos sea probada y documentada. Se le asignan pruebas, es parte y delega dichas pruebas y se asegura que las funcionalidades críticas de su desarrollo sean consideradas como parte del plan de pruebas. Tiene un seguimiento de las pruebas informales que sus desarrolladores han ejecutado.
Junto con el líder de pruebas y el project manager, suma al contenido del plan de pruebas considerando las actividades programadas para el desarrollo y la arquitectura de software. Se asegura de la ejecución de las pruebas de sus componentes y que la integración con los otros equipos sea probada y documentada. Se le asignan pruebas, es parte y delega dichas pruebas y se asegura que las funcionalidades críticas de su desarrollo sean consideradas como parte del plan de pruebas. Tiene un seguimiento de las pruebas informales que los desarrolladores han ejecutado.
Junto con sus respectivos líderes ejecutan las diferentes pruebas establecidas en el plan y se aseguran de que estas sean ejecutadas en el mismo ambiente siguiendo la metodología. Proveen y dan seguimiento a la retroalimentación y documentan el proceso y los resultados, así garantizando un proceso de QA transparente. Informan a los líderes si existe algún problema o si algún componente necesita ser corregido, se encargan de hacer las pruebas en tiempo y forma (de acuerdo al cronograma), llevan un seguimiento de sus pruebas informales y corrigen sus funcionalidades. Cada integrante del desarrollo tiene la responsabilidad de realizar sus pruebas asignadas de caja negra y junto con el SCRUM Master y el Project Manager realizar las pruebas de caja blanca.
Aquí, se describirá la forma en que el equipo se comunicará entre sí y con el propietario del proyecto según las diferentes tareas o las que surjan.
| Concept | Target | Objectives | Schedule | Format | Owner |
|---|---|---|---|---|---|
| Daily Touchpoint | Equipo del Proyecto | Revisar las actividades realizadas el día anterior y establecer metas para el día. | Diario | Junta | Project manager y Líderes de área |
| Revisión de Hitos | Stakeholders | Proporcionar entregables, obtener retroalimentación y discutir próximos pasos. | En hito | Junta | Project manager |
| Weekly touchpoint | Project owner/equipo | Proporcionar actualizaciones del progreso realizado en la semana. | Semanal | Junta | Project manager y Líderes de área |
| Preguntas y problemas | Project owner/equipo | Discutir problemas y preguntas que pueden surgir sobre el desarrollo. | Espontánea | Mensaje/Discord | Desarrolladores |
| Tareas terminadas | Equipo de proyecto | Informar y revisar las tareas realizadas por área. | Al terminar una tarea | Trello/ Discord | Project manager |
El hardware utilizado para las pruebas tendrá un mínimo de 4 núcleos, Intel i5-1155G7 a 4,5 GHz y 8 GB de RAM. Este hardware correra tendrá un sistema operativo mínimo de Windows 10.0.19045. Todo el hardware utilizado por los equipos de prueba y desarrollo cumplirá con estos requisitos mínimos.
La aplicación en sí se alojará en una instancia VPC, que contendrá máquinas virtuales escalables para almacenar el front-end y el back-end por separado, así como una base de no relacional para datos secundarios. Para obtener más información, consulte el Diagrama de arquitectura en la Especificación de requisitos de software. Todos los miembros de los equipos de prueba y desarrollo tendrán acceso a la misma versión de esta instancia VPC.
Esto se llenará en la fase de pruebas de la unidad de formación “TC30005B”. A continuación, la propuesta de templates que se utilizarán para las diferentes pruebas mencionadas.
Template Recorrido
Nombre del Tester:
Fecha:
Nombre del Moderador:
| ID | Paso | Descripción | Resultado Esperado | Resultado Actual | Observaciones | Pasa o No Pasa |
|---|---|---|---|---|---|---|
| x | Ejemplo | Ejemplo | Ejemplo | Ejemplo | Ejemplo | Sí/No |
Template Caja Negra
Nombre del Tester:
Fecha:
Nombre de la Función/Componente:
| ID | Descripción | Resultado Esperado | Parámtero n | Parámtero n+1 | Resultado Actual | Observaciones | Pasa o No Pasa |
|---|---|---|---|---|---|---|---|
| x | Ejemplo | Ejemplo | Ejemplo | Ejemplo | Ejemplo | Ejemplo | Sí/No |
Template Caja Blanca
Nombre del Tester:
Fecha:
Nombre del Moderador:
| ID | Descripción | Línea de Código | Resultado Esperado | Resultado Actual | Observaciones | Pasa o No Pasa |
|---|---|---|---|---|---|---|
| x | Ejemplo | Ejemplo | Ejemplo | Ejemplo | Ejemplo | Sí/No |
Template Prueba de Integración
Nombre del Tester:
Fecha:
Nombre de la Función/Componente:
| ID | Descripción de la Relación | Resultado Esperado | Parámtero n | Parámtero n+1 | Resultado Actual | Observaciones | Pasa o No Pasa |
|---|---|---|---|---|---|---|---|
| x | Ejemplo | Ejemplo | Ejemplo | Ejemplo | Ejemplo | Ejemplo | Sí/No |
El presente documento demuestra la planeación de pruebas para el aplicativo propuesto. Este documento detalla la implementación de todas las pruebas a ejecutar sobre el aplicativo: desde su concepción, ejecución, y documentación.
Las pruebas detalladas tienen pensado ejecutarse durante el desarrollo del aplicativo propuesto: para poder identificar, documentar, exhibir y corregir errores que surjan en el ambiente de desarrollo - así como para identificar riesgos en el diseño o implementación y poder emplear una solución.
Estas pruebas serán ejecutadas por un equipo definido de pruebas - que trabaja de la mano con el equipo de desarrollo - esta comunicación entre equipos asegura un flujo de pruebas correcto y eficiente.
Asimismo, el plan de pruebas puede ayudar al equipo a evaluar y mejorar el rendimiento general del proyecto. Mediante el seguimiento del progreso y la identificación de áreas de mejora, el equipo puede perfeccionar el plan del proyecto, optimizar los recursos y mejorar la eficiencia general del proyecto. En términos generales, la aplicación de un plan de pruebas exhaustivo es esencial para el éxito de cualquier proyecto. Con pruebas continuas, directrices claras y el compromiso de los miembros del equipo, el proyecto puede entregarse a tiempo, dentro del presupuesto y con la calidad esperada. La implementación exitosa de este documento será de gran beneficio para el equipo de desarrollo, el cliente y últimamente para el usuario: asegurando así la sustentabilidad y operatividad del aplicativo - que se espera, sea un gran producto.