Copyright © 2024. UPEX Quality LLC. TODOS LOS DERECHOS RESERVADOS.

MASTER TEST PLAN (Release Q2)

Owned by Ely
Last updated: sept 09, 2022
5 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

 

Copyright © 2024. UPEX Quality LLC. TODOS LOS DERECHOS RESERVADOS.