MASTER TEST PLAN (MTP) (TEMPLATE)

PLANTILLA del "PLAN DE PRUEBAS" (versión simple) 

Cuál es la importancia de un PLAN DE PRUEBAS (Test Plan)?

Realizar la Documentación de un Test Plan tiene muchos beneficios:

  • Además del Equipo interno de QA, ayuda a los miembros de todo el equipo de desarrollo tales como Dev, BA, PO y Clientes, a entender los detalles del Testing.

  • El Test Plan guía nuestro conocimiento. Es como un libro de reglas, el cual necesita ser cumplido.

  • Aspectos importantes, como la Estimación de Pruebas (para Regression o Automatización), el Alcance de las Pruebas, Estrategia de Pruebas son documentadas en el Test Plan, para que así puedan ser revisadas por los Equipos Manager and re-usarse para otros proyectos.

Cómo redactar un Test Plan?

Es un hecho que realizar un Test Plan es la tarea más importante del Proceso de Gestión de Pruebas.
Siguiendo los 7 pasos a continuación, se podrá crear y redactar un Test Plan como el artículo IEEE 829 (modelo):

  1. Analizar el producto

  2. Diseñar el “Test Strategy”

  3. Diseñar el “Test Scopes”

  4. Diseñar el “Test Criteria”

  5. Realizar el “Resource Planning”

  6. Señalar los “Test Environments”

  7. Plasmar el Calendario de Pruebas

  8. Definir la Estimación de Pruebas

  9. Determinar los Entregables (Test Delivery)

https://www.guru99.com/what-everybody-ought-to-know-about-test-planing.html

Modelo IEEE829 ejemplo: https://jmpovedar.files.wordpress.com/2014/03/ieee-829.pdf



SCOPE

(ALCANCE DE LA PRUEBA) (Qué se probará y qué no)* 

✅IN SCOPE (EN ALCANCE):

  • Capacidad de alcanzar TODAS LAS FUNCIONALIDADES de la Web AcademyBugs de su actual versión.

  • Seguir el alcance de las Historias de Usuarios descritas en el Sprint.

  • Seguir las Reglas del Negocio y los Criterios de Aceptación, pero abierto a posibles caminos.

  • La aplicación contiene ciertas funcionalidades que frenan algunas ejecuciones de pruebas, por lo tanto:

    • Reportar todo aquel Bug que se haya visualizado o topado en la ejecuciones de pruebas.

    • Para las Historias de Usuario con relación o bloqueo, por favor realizarlas a la par.

  • Como el SRS (Software Requirement Specifications), el proyecto UPEX BOOTCAMP, solo se enfoca en probar solo algunas funciones interesantes de UI de diferentes SUT, por razones educativas.

❌OUT OF SCOPE (FUERA DE ALCANCE):

  • No reportar Bugs que no estén más allá del alcance de las funcionalidades.

  • Las pruebas no funcionales, como el estrés, el rendimiento o la base de datos lógica, actualmente no se probarán. (fuera del ámbito)

FOCUS

(ENFOQUES DE PRUEBA) (Qué tipos de Testing se realizarán)* 

DESCRIPCIÓN DE LOS NIVELES DE PRUEBAS Y TIPOS QUE SE REALIZARÁN:

En este caso, por ahora, solo se realizará el Nivel de Testing más común, es decir: UI Testing o también llamado System Testing.

MACRO-TIPO DE TESTING

NIVELES DE TESTING

TIPOS DE TESTING

BBTT (Black Box Testing Techniques)

Tipos de TC

MACRO-TIPO DE TESTING

NIVELES DE TESTING

TIPOS DE TESTING

BBTT (Black Box Testing Techniques)

Tipos de TC

PRUEBAS FUNCIONALES
CAJA NEGRA

  • UI Testing

  • System Testing

  • Exploratory Testing (para BBTT)

  • Re-Testing (para bugs)

  • Regression Testing (para reportes)

  • Equivalence Partitioning

  • Boundary Value Analysis

  • Decision Table

  • State Transition

  • Manual

  • Automation

PRUEBAS FUNCIONALES CAJA BLANCA

  • Integration Testing

  • API Testing

  • DB Testing

  • Re-Testing (para bugs)

  • Regression Testing (para reportes)

  • Equivalence Partitioning

  • Boundary Value Analysis

  • Decision Table

  • State Transition

  • Automation

RISK
— (Lo que se necesita solventar)

MITIGATION
— (Con lo que puede ayudar)

RISK
— (Lo que se necesita solventar)

MITIGATION
— (Con lo que puede ayudar)

Los miembros del equipo carecen de las habilidades requeridas para las pruebas de sitios web.

Planificar un curso de capacitación para mejorar las habilidades de sus miembros

El cronograma del proyecto es demasiado apretado; es difícil completar este proyecto a tiempo.

Establecer Prioridad de prueba para cada una de las actividades de prueba.

Test Manager tiene poca habilidad de gestión.

Planificar formación de liderazgo para gerentes

La falta de cooperación afecta negativamente la productividad de sus empleados.

Animar a cada miembro del equipo en su tarea e Inspirar a mayores esfuerzos.

Estimación presupuestaria incorrecta y sobrecostos.

Establecer el alcance antes de comenzar a trabajar, prestar mucha atención a la planificación del proyecto y realizar un seguimiento y medir constantemente el progreso.

🔴🟢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

 

(Estos gráficos son a modo de ejemplo, para fines educativos; cómo se vería una Planificación de Recursos para las Actividades de Testing de forma estratégica con todo el Equipo QA; esto es solo un diseño, no es un standard —porque no la hay)

📌Human Resource:

NOMBRE DEL TESTER / ANALISTA QA

SENIORITY

ROL INTERNO

ESPECIALIDADES RELACIONADAS AL SUT

RESPONSABILIDAD EN PRUEBAS
(por Niveles de Testing)

NOMBRE DEL TESTER / ANALISTA QA

SENIORITY

ROL INTERNO

ESPECIALIDADES RELACIONADAS AL SUT

RESPONSABILIDAD EN PRUEBAS
(por Niveles de Testing)

@Ely

[ SENIOR QA ]

[ QA LEAD ]

  • —ALL—

  • —TEST PLANNING—

Fulanito de Tal

[ SSR QA ]

[ QA MANUAL ]

  • Infografía

  • Tienda Online

  • Formularios

  • UI Testing Manual

  • DB Testing Manual

  • API Testing Manual

Pepito de Tal

[ JUNIOR TAE ]

[ AUTOMATION ]

  • Tienda Online

  • Formularios

  • E2E Testing

    • UI Testing Automate

    • API Testing Automate

Maria de Tal

[ JUNIOR QA ]

[ QA MANUAL ]

  • Infografía

  • Formularios

  • UI Testing Manual

📌System Resource:

HERRAMIENTAS DEL PROYECTO

DESCRIPCIÓN DEL USO

HERRAMIENTAS DEL PROYECTO

DESCRIPCIÓN DEL USO

SLACK

Para comunicación fluida, corrida, actualización de temas, noticias, y más.
upexqa.slack.com

Jira con X-RAY

Herramienta principal, gestor de incidencias para trabajar y seguir las tareas.
https://upex-sprint.atlassian.net/jira

CONFLUENCE

Herramienta de Documentación definitiva, Docs de Jira, Proyecto, Plans, etc.

KATALON STUDIO

Para realizar Pruebas Automatizadas; UI Tests, API Tests, Regresión, etc.
<link aquí del ambiente>

GOOGLE MEET

Para realizar las Planning, resolver problemas rápido, etc. (y dictar Cursos)

EXCEL / GOOGLE SHEET

Para preparar Data para las Pruebas y/o Preparar Múltiples TC para Importación.


PROYECTOS DE UPEX

TEST ENVIRONMENT SETUP

LINK DE ACCESO

TEST ENVIRONMENT BROWSER

PROYECTOS DE UPEX

TEST ENVIRONMENT SETUP

LINK DE ACCESO

TEST ENVIRONMENT BROWSER

ACADEMYBUGS.COM (uTest)

  • DEV

  • <link de acceso>

 

ACADEMYBUGS.COM (uTest)

  • QA1-AB (manual)

  • QA2-AB (automation)

  • <link de acceso>

  • <link de acceso>

  • GOOGLE CHROME

  • MICROSOFT EDGE

ACADEMYBUGS.COM (uTest)

  • UAT

  • <link de acceso>

 

ACADEMYBUGS.COM (uTest)

  • STAGE

  • <link de acceso>

 

ACADEMYBUGS.COM (uTest)

  • PROD

  • <link de acceso>

 

NEW PROJECT

 

 

 

 

CALENDARIO DEL PROYECTO (EJEMPLOS)

CALENDARIO DE PRUEBAS

<REMAINING IMAGE>

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

  • Installation/ Test procedures guidelines

  • Release notes