Ir al final de los metadatos
Ir al inicio de los metadatos

Estás viendo una versión antigua de esta página. Ve a la versión actual.

Comparar con el actual Ver el historial de la página

« Anterior Versión 3 Siguiente »

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

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

BBTT (Black Box Testing Techniques)

(En este apartado adicional es para explicar y tener a la mano una guía sobre las técnicas de testing para aplicar en el Proyecto)

CÓMO APLICAR LAS BBTT para mejorar la Derivación de Casos de Prueba?

DIFICULTAD: MEDIA:

→ DERIVACIÓN DE CASOS CON Particiones Equivalentes y Valores Límites:

https://www.guru99.com/equivalence-partitioning-boundary-value-analysis.html

DIFICULTAD: DIFICIL:

→ DERIVACIÓN DE CASOS CON “TABLA DE DECISIONES”:

BBTT: DECISION TABLE

DIFICULTAD: MEDIA:

→ DERIVACIÓN DE CASOS CON “TABLA DE TRANSICIÓN DE ESTADOS”:

https://www.guru99.com/state-transition-testing.html

RISK

(RIESGOS AL REALIZAR LAS TAREAS) (Qué afecta al Negocio y al Equipo)

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

RESOURCE PLANNING

(Recursos o Logística del Equipo de Trabajo y Herramientas de Trabajo)

(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)

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

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.
https://upex-sprint.atlassian.net/wiki/spaces/UPEX/overview?homepageId=196640

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.


TEST ENVIRONMENTS

(Ambientes del Proyecto y Ambientes Prueba del SUT, a modo de ejemplo)

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

MILESTONES

(ejemplo de Proyecto lineal y Proyecto Ágil)

CALENDARIO DEL PROYECTO (EJEMPLOS)

CALENDARIO DE PRUEBAS

<REMAINING IMAGE>

TEST DELIVERY - LOS ENTREGABLES DE QA

(Tareas por realizar en cada etapa del Testing)

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

  • Sin etiquetas