MASTER TEST PLAN (Release Q2)

Owned by Ely
Last updated: sept 09, 2022
4 min read

ANÁLISIS FUNCIONAL:

https://upexdocu.atlassian.net/wiki/spaces/UPEX/pages/362147

TEST STRATEGY

A continuación, se aclararán las Estrategias de QA para entregar las tareas del proyecto.

SCOPE:

Es el alcance válido de las pruebas; hasta dónde se prueba, qué NO se prueba

  • Las pruebas se realizarán en el componente PIM List (Product Information Management)

    • Se abordarán las pruebas en las secciones de:

      • “Employee List”: Buscar, Ordenar y Borrar empleados

      • “Add Employee”: Agregar y Editar empleados

  • Las pruebas se realizarán en el componente PIM Profile (Información de Empleados)

    • Se abordarán las pruebas en las secciones de:

      • “Personal Details”

      • “Contact Details”

      • “Emergency Contacts“

      • “Job”

      • “Qualifications“

  • Las pruebas se realizarán en el componente Account (Cuenta)

    • Se abordarán las pruebas en las secciones de:

      • “Login”

      • “Logout”

      • “Password-Change”

      • “Password-Recovery”

TESTING FUNCIONAL:

Macro-Nivel de Testing

Nivel de Testing

Tipos de Testing

Macro-Nivel de Testing

Nivel de Testing

Tipos de Testing

Blackbox (Frontend)

  • UI Testing (QA)

  • In-Sprint Testing

  • Exploratory

  • Smoke Testing

  • Sanity Testing

  • Regression Testing

  • Re-Testing (Bugs)

Blackbox (Frontend)

  • (UI) UAT Testing

  • Exploratory

  • Smoke Testing

  • Sanity Testing

  • Re-Testing (Bugs)

Whitebox (Backend)

  • Unit Testing (dev)

  • In-Sprint Testing

  • Re-Unit-Testing

Whitebox (Backend)

  • Integration Testing

  • E2E (end-to-end):

    • Database Testing

    • API Testing

    • UI

  • Smoke Testing

  • Sanity Testing

TESTING FUNCIONAL:

N/A

RIESGO (PROBLEMAS E INCIDENTES)

MITIGACIÓN (CÓMO EVITARSE)

RIESGO (PROBLEMAS E INCIDENTES)

MITIGACIÓN (CÓMO EVITARSE)

No saber Testear (No sabe hacer testing)

Hacer un Curso (el de Blackhole is the best )

No entender los Requerimientos (User Story)

  • Si el QA no entiende una buena US:

    • Hacer un Curso de Testing Al Grano

  • Si el BA no está haciendo una US correcta:

    • Reunirse con el BA y aclarar las dudas:

      • Establecer una Meet siempre después del Sprint Planning para identificar las dudas que no se hablaron.

El Dev y QA no están teniendo buena comunicación.

Establecer una Meet para resolver las dudas justo al comenzar el Sprint.

Problemas en el Servidor que nos bloquean las Pruebas.

  • Notificar a los Managers y Lider QA, para generar un Reporte de Bug y escalar el incidente, para fixearlo lo más pronto posible.

  • Tener otros Clusters de respaldo para evitar la pérdida de tiempo.

Hacer MUCHAS pruebas en un Ambiente que pueda desestabilizar los request y responses del mismo.

  • Mejorar las pruebas de Rendimiento

  • tener diferentes ambientes de QA para distribuir el impacto (QA1, QA2, QA3)

No tener la conexión a un ambiente de la Base de Datos cuando se necesite

Realizar una Documentación con todos los ConnectionString de cada ambiente de Base de Datos, de manera que los QA puedan tener organizado y a la mano.

Tener un QA enfermo

Tener un Plan de Reemplazo de manera que jamás se quede 1 persona sola en el equipo de QA (mínimo debe haber 2).

No tener un buen Gestor de Incidencias (si se cae Jira)

Usar Trello, ya que es de la misma empresa Atlassian.

No saber suficientemente Inglés como para comunicarse con los clientes u equipos de dicho idioma.

Asistir a la capacitaciones internas de la empresa en inglés (obligado).

Introducirte al mundo del inglés, colocando todo en inglés (PCs, Laptops, Phones, Apps, etc)

Desconocimiento del Framework (Cypress)

Solicitar un curso pagado por la empresa

Solicitar una US al proyecto para trabajar en la adquisición de conocimientos de un Framework.

Falta de Documentación del Proyecto

Aplicar y Diseñar un SRS (Software Requirement Spec) más profundo y con arquitectura del Software. UI Spec, DB Spec y API Spec.

No estimar bien las Horas de Esfuerzo (Task)

Establecer un Plan Standard para Identificar las Horas estimadas, de acuerdo a los Story Points.

🔴🟢TEST SUSPENSION CRITERIA — (Cuándo PAUSAR las Pruebas de Regresión?)

(Especificar los criterios críticos de suspensión para una prueba. Si se cumplen los criterios de suspensión durante la prueba, el ciclo de prueba activo se suspenderá hasta que se resuelvan los criterios.)

  • 📌*SUSPENSION CRITERIA* (ejemplo):

    • Cuando (IF):

      • → Test Report: más del 40% de TC = FAIL.

        • PAUSAR TODO EL TESTING (suspensión temporal)

      • De lo contrario (ELSE):

        • CONTINUAR CON EL TESTING

 

🛑TEST EXIT CRITERIA — (Cuándo FINALIZAR las Pruebas de Regresión?)

(Especifica los criterios que denotan una finalización exitosa de una fase de prueba. Los criterios de salida son los resultados previstos de la prueba y son necesarios antes de pasar a la siguiente fase de desarrollo. Ejemplo: el 95% de todos los casos de prueba críticos deben pasar.)

  • 📌*EXIT CRITERIA* (ejemplo):

    • Cuando (IF):

      • → RUN RATE: 100% de TC status EXECUTED

      • Y también (AND):

        • → PASS RATE = +95% de TC

        • Entonces (THEN):

          • FINALIZAR TODO EL TESTING (cierre definitivo)

      • De lo contrario (ELSE):

        • CONTINUAR CON EL TESTING

 

RECURSOS HUMANOS:

Persona

Rol

Responsabilidad

Persona

Rol

Responsabilidad

Elyer

QA Manager

Asegurarse los Delivery QA de todo el equipo, métricas para la toma de decisiones y negociar con los clientes. Asegurarse de que el Líder QA no tenga bloqueantes.

Juan

QA Tester

Realizar pruebas para ejecutar y reportar.

Lenu

QA Lead

Realizar Planes de Pruebas y organizar el equipo. Asegurarse de que el equipo no tenga bloqueantes.

RECURSOS DE FRAMEWORKS

Framework/Tool

Acceso

Actividad

Framework/Tool

Acceso

Actividad

Jira

<URLdeAcceso>

Gestor General de Incidencias

GitHub

<URLdeAcceso>

Gestor General de Versiones del Código

RECURSOS DE DOCUMENTACIÓN

AREAS

GUÍAS / DOCUMENTACIONES

AREAS

GUÍAS / DOCUMENTACIONES

QA

TEST DESIGN <URL>

DEV

API DOCU <URL>

BA

CASOS DE USO <URL>

PROJECT

Workflow del Equipo de Trabajo <URL>

Dev Environments (proceso de Release)

Access (al SUT)

Dev Environments (proceso de Release)

Access (al SUT)

Dev

https://software.upex-dev.net/

QA

https://software.upex-qa.net/

QA2

https://software.upex-qa2.net/

QA3

https://software.upex-qa3.net/

UAT

https://software.upex-uat.net/

STAGE

https://software.upex-stage.net/

PROD

https://software.upex.net/

Test Environments (Entornos de Trabajo)

Access (para ingresar)

Test Environments (Entornos de Trabajo)

Access (para ingresar)

Sistema Operativo: Android

Login X

Sistema Operativo: iOS

Login X

Navegador: Chrome

Login X

Navegador: Firefox

Login X

Grafico de Gant para describir un Proyecto CASCADA

Entregables que deben ser realizado ANTES DE la fase de TEST EXECUTION:

  • Test plans document.

  • Test cases documents

  • Test Design specifications.

Entregables que deben ser realizado DURANTE la fase de TEST EXECUTION:

  • Test Scripts

  • Simulators.

  • Test Data

  • Test Traceability Matrix

  • Error logs and execution logs.

Entregables que deben ser realizado DESPUÉS DE la fase de TEST EXECUTION:

  • Test Results/reports

  • Defect Report

  • Release notes