Copyright © 2024. UPEX Quality LLC. TODOS LOS DERECHOS RESERVADOS.
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 »

ANÁLISIS FUNCIONAL:

SOFTWARE REQUIREMENT SPEC

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”

FOCUS:

Se describen e identifican los tipos y niveles de Pruebas que se realizarán.

TESTING FUNCIONAL:

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

RISKS

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 (guiño) )

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.

  • Sin etiquetas
Copyright © 2024. UPEX Quality LLC. TODOS LOS DERECHOS RESERVADOS.