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):
Analizar el producto
Diseñar el “Test Strategy”
Diseñar el “Test Scopes”
Diseñar el “Test Criteria”
Realizar el “Resource Planning”
Señalar los “Test Environments”
Plasmar el Calendario de Pruebas
Definir la Estimación de Pruebas
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 |
|
|
|
|
PRUEBAS FUNCIONALES CAJA BLANCA |
|
|
|
|
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”:
DIFICULTAD: MEDIA:
→ DERIVACIÓN DE CASOS CON “TABLA DE TRANSICIÓN DE ESTADOS”:
RISK
(RIESGOS AL REALIZAR LAS TAREAS) (Qué afecta al Negocio y al Equipo)
RISK | MITIGATION |
|---|---|
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 |
|---|---|---|---|---|
[ SENIOR QA ] | [ QA LEAD ] |
|
| |
Fulanito de Tal | [ SSR QA ] | [ QA MANUAL ] |
|
|
Pepito de Tal | [ JUNIOR TAE ] | [ AUTOMATION ] |
|
|
Maria de Tal | [ JUNIOR QA ] | [ QA MANUAL ] |
|
|
📌System Resource:
HERRAMIENTAS DEL PROYECTO | DESCRIPCIÓN DEL USO |
|---|---|
SLACK | Para comunicación fluida, corrida, actualización de temas, noticias, y más. |
Jira con X-RAY | Herramienta principal, gestor de incidencias para trabajar y seguir las tareas. |
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. |
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) |
|
| |
ACADEMYBUGS.COM (uTest) |
|
|
|
ACADEMYBUGS.COM (uTest) |
|
| |
ACADEMYBUGS.COM (uTest) |
|
| |
ACADEMYBUGS.COM (uTest) |
|
| |
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
0 Comentarios