PLAN DE PRUEBAS

Objetivo del plan de pruebas

Definido como “Modelo de Procesos para la Industria de Software (MoProSoft) en México que fomente la estandarización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permitirá elevar la capacidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles internacionales de competitividad”

Para cumplir con su objetivo, MoProSoft está organizado en tres categorías. Éstas cubren todas las áreas críticas de una organización dedicada al desarrollo de software: Alta Dirección, Gerencia y Operación.

Definiendo el plan de pruebas

La Guía de Pruebas de Software (GPS) está estructurada de acuerdo a las categorías de MoProSoft y cubre las actividades cuyos resultados pueden mejorarse por medio de las pruebas. Es decir, se eligieron aquellas en las cuales las pruebas pueden intervenir para asegurar la calidad del producto generado, siguiendo el modelo.

Ilustración 73 Categoría de procesos de MoProSoft

Categoría Alta Dirección

Las pruebas son clave para garantizar la calidad de cualquier proyecto de software, por lo que la Alta Dirección debe conocer y estar comprometida con la aplicación de las mismas desde la perspectiva del negocio.

Tabla 61 Proceso gestión de Negocio - Actividades de MoProSoft cubiertas por GPS

Categoría Gerencia

En esta categoría la guía define las actividades de pruebas que deben considerarse dentro de los procesos Gestión de Procesos y Gestión de Recursos.

Tabla 62Proceso Gestión de Procesos - Actividades de MoProSoft cubiertas por GPS

Actividad MoProSoft: Planificación (A1)

Tabla 63 Proceso Gestión de Recursos - Actividades de MoProSoft cubiertas por GPS

Categoría Operación

En la categoría se encuentran los procesos Administración de Proyectos Específicos y Desarrollo y Mantenimiento de Software, por lo que ofrece un amplio espectro de aplicación de las pruebas. El proceso de Administración de Proyectos Específicos incluye cuatro actividades y GPS aporta en dos de ellas.

_ Tabla 64 Proceso Administración de Proyectos Específicos - Actividades de MoProSoft cubiertas por GPS

Tabla 65 Proceso Desarrollo y Mantenimiento de Software - Actividades de MoProSoft cubiertas por GPS y

Actividad MoProSoft: Planificación

GPS complementa esta actividad con otras cuatro que permiten incluir las pruebas durante la ejecución de la misma. A continuación, se describen brevemente cada una de ellas.

Tabla 66 Cantidad de ciclos de pruebas según el tipo de prueba

El número de ciclos se define de acuerdo a los objetivos de la organización y a las actividades de pruebas que se harán en el proyecto. Por medio de la actividad “identificar ciclos y actividades” GPS propone, a partir de la experiencia, una escala de ciclos de prueba según los tipos de pruebas que se aplicarán

Creación de los casos de prueba

Tabla 67 Caso de Prueba 1

Tabla 68 Caso de prueba 2

Tabla 69 Caso de prueba 3

Tabla 70 Caso de Prueba 4

Tabla 71 Caso de Prueba 5

Tabla 72 Caso de prueba 6

Tabla 73 Caso de prueba 7

Tabla 74 Caso de prueba 8

Tabla 75 Caso de prueba 9

Tabla 76 Caso de prueba 10

Tabla 77 Caso de prueba 11

_Tabla 78 Caso de prueba 12

Actividad MoProSoft: Realización de la fase de Integración y Pruebas

Tabla 79 bloques de ejecución de pruebas

PRUEBAS EN TESTRAIL

TestRail es una solución de gestión de casos de prueba para aseguramiento de la calidad (QA) y equipos de desarrollo, que está diseñada para ayudar a los usuarios a organizar, gestionar y rastrear el proceso de prueba del software de la empresa.

A continuación, se muestran los resultados del Test rial del Sprint 1, debido a que este Sprint es de planeación Aquí es donde se iniciaron test rial que fueron aplicados a los requisitos funcionales para asegurarnos que el desarrollo del software sea de calidad.

Primero agregamos nuestro proyecto se SuperM el cual está en Git Hub y lo enlazamos a nuestro Plan de Pruebas.

Ilustración 74 Agregamos nuestro repositorio de Git Hub

Agregamos nuestros Requisitos Funcionales en la sección de planes de pruebas

Ilustración 75 Test rail del SPRINT 1

En la siguiente ilustración se muestra una tabla en la que se indican los test rial realizados en este sprint.

Ilustración 76 Test rail agregamos los REQUISITOS FUNCIONALES

Podemos apreciar el número de casos escritos

Ilustración 77 Número de casos escritos

Nos visualizan las nuevas ejecuciones de prueba

_Ilustración 78 Ejecución de Pruebas

INFORMES DE PRUEBAS

Generamos las pruebas de nuestros Requisitos Funcionales

Ilustración 79 Requisitos Funcionales

PRUEBA RF-01

Ilustración 80 Prueba RF-01

Podemos observar que efectivamente se cumple el Requisito Funcional 01

Ilustración 81 Registrar Datos de Usuario

Ilustración 82 Registrar Datos de Usuario

PRUEBA RF-02

Ilustración 83 Prueba RF-02

Podemos observar que efectivamente se cumple el Requisito Funcional 02

Ilustración 84 Login de la App

PRUEBA RF-03

Ilustración 85 Ilustración 8 Prueba RF-03

Podemos observar que efectivamente se cumple el Requisito Funcional 03

Ilustración 86 Verificación de los datos del usuario para ser MODIFICADOS

PRUEBA RF-04

En este Requisito Funcional se creó la parte de la vista del Administrador quien es el único que puede eliminar un usuario

Ilustración 87 Prueba RF-04

Ilustración 88 Eliminar Usuario

PRUEBA RF-05

En este Requisito Funcional se creó la parte de la vista del Administrador quien es el único que tiene puede añadir nuevos productos a la app.

Ilustración 89 Prueba RF-05

Ilustración 90 Registrar nuevo producto

PRUEBA RF-06

Ilustración 91 Prueba RF-06

Tenemos la sección en la pantalla principal de poder consultar los productos que se encuentran en existencia

Ilustración 92 Inicio de App visualizamos la sección de Productos

PRUEBA RF-07

En este Requisito Funcional se creó la parte de la vista del Administrador quien es el único que tiene puede actualizar nuevos productos a la app

Ilustración 93 Prueba RF-07

Ilustración 94 Actualizar Productos

PRUEBA RF-08

En este Requisito Funcional se creó la parte de la vista del Administrador quien es el único que tiene puede eliminar algún producto de la app

Ilustración 95 Prueba RF-08

Ilustración 96 Eliminar Productos

PRUEBA RF-09

Ilustración 97 Prueba RF-09

Ilustración 98 Lista de Productos

PRUEBA RF-10

Ilustración 27 Prueba RF-10

Podemos observar que efectivamente se cumple el Requisito Funcional 10 con la opción de poder realizar la compra

Ilustración 100 Añadir las compras del Usuario al carrito

PRUEBA RF-11

En este Requisito Funcional se creó la parte de la vista del Administrador quien es el único que tiene puede añadir una nueva categoría a la app

Ilustración 101 Prueba RF-11

Ilustración 102 Añadir nueva categoría

PRUEBA RF-12

En este Requisito Funcional se creó la parte de la vista del Administrador quien es el único que tiene puede listar la categoría en la app

Ilustración 103 Prueba RF-12

Ilustración 104 Listar Categoría

PRUEBA RF-13

En este Requisito Funcional se creó la parte de la vista del Administrador quien es el único que tiene puede modificar la categoría en la app

Ilustración 105 Prueba RF-12

Ilustración 106 Modificar categoría

PRUEBA RF-14

Ilustración 107 Prueba RF-14

Ilustración 108 Eliminar Categoría

PRUEBA RF-15

Ilustración 109 Prueba RF-15

Ilustración 110 Mostrar Pedidos

Al finalizar el TestCase

Podemos visualizar que se ha realizado el plan de pruebas en nuestro proyecto

Ilustración 111 Plan de Pruebas