---
title: 'Guía para diseño y ejecución de pruebas de QA (Quality Assurance)'
---
<style>
.two-column-layout {
column-count: 2; /* Set column number */
column-gap: 20px;
max-width: 100%;
overflow: hidden;
}
/* Media query for mobile devices */
@media (max-width: 768px) {
.two-column-layout {
column-count: 1; /* Switch to single column on small screens */
column-gap: 0; /* Optional: Set gap to 0 for single column */
}
}
.markdown-body, .ui-infobar {
max-width: unset !important;
}
.two-column-layout ul,
.two-column-layout ol {
margin: 0;
padding-left: 20px;
}
.two-column-layout strong {
font-weight: bold;
}
.two-column-layout em {
font-style: italic;
}
.two-column-layout h1,
.two-column-layout h2,
.two-column-layout h3,
.two-column-layout h4,
.two-column-layout h5,
.two-column-layout h6 {
margin-top: 0;
}
</style>
# Guía para diseño y ejecución de pruebas de QA (Quality Assurance)
El presente documento es un recurso de apoyo que describe los pasos a seguir para diseñar y ejecutar pruebas de QA. Se menciona el flujo general del QA dentro de un proyecto de desarrollo convencional, así como algunas definiciones clave de los conceptos requeridos, y tips para desempeñar el rol de QA adecuadamente.
Consulta los procedimientos oficiales en el repositorio oficial de [Procesos, Procedimientos y Formatos](https://mediaaereanet.sharepoint.com/sites/Procesosprocedimientosyformatos/Documentos%20compartidos/Forms/AllItems.aspx), para mayores detalles:
[Procedimiento de Análisis y Diseño](https://mediaaereanet.sharepoint.com/:w:/r/sites/Procesosprocedimientosyformatos/Documentos%20compartidos/4.%20Proceso%20de%20operaciones/Operaciones%20DS/2.-Analisis%20y%20dise%C3%B1o/MA-OP-DS-PR-47-An%C3%A1lisis%20y%20dise%C3%B1o.docx?d=w4d6506bbbbfb41288ea1a07a2884f36b&csf=1&web=1&e=j1hHbp)
[Procedimiento de Desarrollo de Software](https://mediaaereanet.sharepoint.com/:w:/r/sites/Procesosprocedimientosyformatos/Documentos%20compartidos/4.%20Proceso%20de%20operaciones/Operaciones%20DS/3.-Desarrollo%20de%20software/MA-OP-DS-PR-48-Desarrollo%20de%20software.docx?d=w4f3d138c29e54dcea0a77b885866f5d0&csf=1&web=1&e=eovedL)
[Procedimiento de Liberación y Entrega](https://mediaaereanet.sharepoint.com/:w:/r/sites/Procesosprocedimientosyformatos/Documentos%20compartidos/4.%20Proceso%20de%20operaciones/Operaciones%20DS/4.-Liberaci%C3%B3n%20y%20entrega/MA-OP-DS-PR-49-Liberaci%C3%B3n%20y%20entrega.docx?d=wb918c3eafa944d0b89b1254e5ee9e0bf&csf=1&web=1&e=pM99aH)
<div>
## Flujo de QA
Las actividades del proceso de QA puede resumirse a muy grandes rasgos en las siguientes actividades:
```mermaid
flowchart LR
A("📋<br/>Diseño de casos<br/>de prueba")
B("👥<br/>Revisión por par<br/>de análisis")
C("▶️<br/>Ejecución de casos<br/>de prueba")
D("🔍<br/>Ejecución de pruebas<br/>exploratorias")
E("🤖<br/>Automatización<br/>de pruebas")
F("🐛<br/>Registro de BUGs")
G("🔁<br/>Seguimiento de BUGs<br/>y re-test")
H("🚀<br/>Liberar a<br/>UAT / Prod")
A --> B --> C --> D --> E
E -->|BUGs encontrados| F
F --> G
E -->|Sin BUGs| H
G -->|BUGs<br/>resueltos| H
style F fill:#fef2f2,stroke:#c0392b,color:#1a1a1a
style G fill:#fffbeb,stroke:#b7770d,color:#1a1a1a
style H fill:#f0fdf4,stroke:#16a34a,color:#1a1a1a
```
Cumplir con estas actividades ayuda a garantizar un mayor nivel de calidad en el software ofrecido al cliente. A continuación revisaremos paso a paso cada actividad, y lo que esta implica.
</div>
<div>
## Diseño de casos de prueba
La primera actividad con la cual inicia un QA es el diseño del artefacto de: Matriz de pruebas, el cual puede consultarse desde el siguiente link en el repositorio oficial de Procesos, Procedimientos y Formatos de la organización:
[Matriz de pruebas](https://mediaaereanet.sharepoint.com/:x:/r/sites/Procesosprocedimientosyformatos/Documentos%20compartidos/4.%20Proceso%20de%20operaciones/Operaciones%20DS/2.-Analisis%20y%20dise%C3%B1o/MA-OP-DS-FO-105-Matriz%20de%20Pruebas.xlsx?d=w60eb013f78004244a7457d947aed7a33&csf=1&web=1&e=NaZoO9)
Si no puedes acceder al link, comunicante con tu PM o el lider del área para que te ayuden a obtener acceso.
La matriz de pruebas, es un artefacto donde se definen todos los casos de prueba y pruebas exploratorias que se estarán ejecutando para cada funcionalidad que el sistema contemple.
Para poder comenzar a diseñar la matriz de pruebas de cualquier sistema, el QA necesitará la documentación de análisis del sistema, la cual suele estar compuesta de:
* Requerimientos de servicio (RES)
* Backlog de desarrollo
* Prototipo de pantallas (Proyecto en Figma)
* Catálogo de reglas de negocio (CRN)
* Modelo de casos de uso (MCU)
* Especificaciones de interfaz de usuario
* Especificaciones de casos de uso
Estos documentos variarán dependiendo del tipo de proyecto y el contexto particular del mismo, sin embargo, de manera mínima todos los proyectos contarán con: Requerimientos de servicio, backlog de desarrollo y prototipo de pantallas, estos insumos son suficientes para diseñar la matriz de pruebas.
El PM deberá compartir al QA la documentación del proyecto para que se pueda comenzar con el diseño de la matriz de pruebas.
### Matriz de pruebas
Una matriz de pruebas adecuada deberá contener casos de prueba y pruebas exploratorias claras y conscisas, que ayuden a probar las funcionalidades clave de cada historia de usuario, o caso de uso, definido en el backlog del sistema.
Para esto, es importante comprender los criterios de aceptación de cada funcionalidad, ponerse en el lugar del usuario, y diseñar pruebas de manera humana, incluyendo de igual manera el conocimiento técnico que tenemos sobre software. Asegurándonos de cumplir tanto con la expectivativa del usuario que utilizará el sistema, y las características internas con las cuales debe contar cualquier software que siga las buenas prácticas en su contexto de desarrollo.
Recordemos entonces que la matriz de pruebas debe incluir:
1. Casos de prueba
1. Pruebas exploratorias
#### Casos de pruebas
Los casos de prueba son las pruebas de QA convencionales de todo proyecto, se deberán generar casos de prueba para todas las funcionalidades declaradas en el backlog del proyecto, cumpliendo con los siguientes elementos para cada una:
* Pruebas de funcionalidad
* Pruebas de regresión
* Pruebas de integración
* Pruebas de seguridad
* Pruebas de diseño
Dependiendo del contexto de la funcionalidad es posible que no se pueden realizar todos los tipos de pruebas disponibles, pero de manera mínima todas las funcionalidades deberán contar siempre con:
* Pruebas de funcionalidad (Caso positivo y caso negativo)
* Pruebas de regresión
* Pruebas de integración
A continuación la definición y ejemplo de cada tipo de prueba
| Tipo de Prueba | Definición | Ejemplo |
|---|---|---|
| **Pruebas de Funcionalidad** | Verifican que cada función del sistema se comporte según los requerimientos especificados. Se prueba QUÉ hace el sistema. | En un e-commerce: verificar que al hacer clic en "Agregar al carrito" el producto aparece correctamente con precio y cantidad correctos. |
| **Pruebas de Regresión** | Verifican que cambios recientes (nuevas funcionalidades, correcciones de bugs) no hayan roto funcionalidades que ya funcionaban correctamente. | Tras corregir un bug en el módulo de pagos, se re-ejecutan todas las pruebas de login, carrito y checkout para asegurar que siguen funcionando. |
| **Pruebas de Integración** | Verifican que distintos módulos o servicios del sistema funcionen correctamente al interactuar entre sí. | Probar que cuando un usuario completa una compra, el módulo de pagos se comunica correctamente con el de inventario y el de notificaciones por correo. |
| **Pruebas de Seguridad** | Evalúan la capacidad del sistema para proteger datos y resistir accesos no autorizados, ataques o vulnerabilidades. | Intentar un ataque de SQL Injection en el campo de login (`' OR '1'='1`) para verificar que el sistema lo bloquea y no expone la base de datos. |
| **Pruebas de Diseño** | Verifican que la interfaz gráfica sea consistente con los mockups/prototipos aprobados y cumpla con estándares de usabilidad y accesibilidad. | Comparar que los colores, tipografías, espaciados y disposición de elementos de la pantalla de checkout coincidan con el prototipo en Figma. |
</div>
Los casos de pruebas que se diseñen se listarán en la pestaña de: Casos de prueba.
El documento de Matriz de pruebas, cuenta con descripciones explicativas en cada celda para facilitar la captura de información.
En una primera instancia los elementos que se llenarán en la matriz durante su diseño son:
Información general del proyecto (solicita la información que no conozcas a tu PM)
Casos de prueba, columnas:
* ID Caso de prueba
* ID Requerimiento
* ID Funcionalidad
* Descripción del caso de prueba
* Pre-condición
* Pasos de prueba
* Datos de prueba
* Resultado esperado
* Tipo de prueba
* Prioridad
* Estado del caso de prueba
Durante la fase de diseño de pruebas, concluirás actividades con un registro de todos los casos de prueba de las funcionalidades objetivo del backlog (este será un dato compartido por el PM).
Una vez se finalice el diseño de los casos de prueba, será necesario definir las pruebas exploratorias del sistema.
#### Pruebas exploratorias
Las pruebas explotaratorias son ejercicios que permiten validar flujos críticos del sistema, a diferencia de los casos de pruebas, que pueden llegar a testear características de manera aislada, una prueba exploratoria es como la revisión del comportamiento general de un flujo.
Dentro de la matriz de pruebas estas se capturan en la pestaña de: Pruebas exploratorias.
Para obtener una mejor referencia sobre cómo diseñar pruebas exploratorias, favor de revisar el siguiente enlace a a guía correspondiente: [Guía para pruebas exploratorias](https://hackmd.io/JrmX3wPWQ6ix-A6oclcC0Q)
### Revisión por par de análisis
Cuando se finaliza el diseño de la matriz de pruebas, es necesario solicitar la revisión por par de análisis de la misma.
Una revisión por par, es una actividad en la cual un compañero revisa el trabajo realizado, y existen 3 tipos de revisión por par:
* **Remota:** Revisión completemante asíncrona, el QA que diseñó la matriz comparte el archivo con el revisor, y el revisor realiza la revisión por par por su cuenta, haciendo llegar después el archivo de revisión por par con las observaciones encontradas.
* **Caminata:** El QA que diseñó la matriz y el revisor se reunen de manera presencial o virtual para revisar el artefacto, el QA que diseñó los casos de prueba comparte el documento con el revisor y se van punto por punto, se pueden aclarar dudas durante la sesión.
* **Inspección:** Revisión donde participan dos revisores (mínimo), y realizan una revisión más detallada del artefacto.
El tipo de revisión por par será definido por el PM del proyecto, el QA deberá notificar al PM en cuanto la matriz esté lista para ser revisada.
Se busca que el artefacto obtenga un 80% de aprobación en la revisión para que se puedan comenzar a ejecutar los casos de prueba definidos en ella.
Si se obtiene un resultado menor, la matriz no podrá comenzar a utilizarse, deberán realizarse las correcciones necesarias, aplicar otra revisión por par y esperar a que el resultado de la misma sea igual o mayor al 80%.
Si la matriz pasa con 80% (o más), en la primera revisión, podrá comenzar a utilizarse, pero las observaciones igual deberán ser atendidas.
El seguimiento de dichas observaciones se realiza en el sistema MA-ERP.
<div>
### Ejecución de casos de prueba
Cuando inicia el desarrolo de un proyecto y se comienzan a trabajar la funcionalidades del backlog, el QA podrá comenzar con la ejecución de los casos de prueba a medida que las tarjetas avanzan hacia la columna de QA Pending en el tablero Kanban del proyecto, dentro del sistema MA-ERP.
Para esto, el QA deberá tener acceso a:
* El tablero kanban del proyecto dentro del sistema MA-ERP
* El ambiente de QA del sistema
Dichos recursos serán compartidos al QA por el PM.
Si una tarjeta se encuentra en la columna de QA Pending, el QA puede asumir que esta se encuentra lista para ser probada en el ambiente de QA correspondiente, y puede moverla a la columna de QA process para comenzar con la ejecución de los casos de prueba diseñados para la funcionalidad en cuestión.
Dentro de la matriz de pruebas del proyecto se deberán llenar las columnas de:
* Resultado real
* Estado del resultado
* Iteración
* Evidencia
* Tarjeta MA-ERP
* Comentarios
A medida que se van ejecutando las pruebas se deberán ir llenando las columnas mencionadas con los resultados obtenidos, siguiendo la instrucción indicada dentro del mismo formato.
### Automatización de pruebas
Se deberán automatizar dentro de la medida de lo posible todas las pruebas del proyecto, para agilizar la ejecución de las mismas.
La automatización de pruebas consiste en generar scripts de código que puedan realizar los pasos que hemos descrito en nuestros casos de prueba por nosotros, ahorrándonos así el tiempo de probar manualmente. Esto implica un esfuerzo y dedicación mayores al inicio del proyecto, pero ayudará bastante a medida que el proyecto madura y se vuelve cada vez más complejo.
Para esto, se deberá hacer uso de la herramienta de Playwright, puedes consultar la guía de uso específica de esa herramienta en el siguiete enlace: [Guía de pruebas automatizadas con Playwright](https://hackmd.io/@MediaAerea-TI/H1llMANubg).
De manera mínima, **todas las pruebas de regresión deberán automatizarse.** Para esto, se necesitará contar con el proyecto corriendo en la computadora del QA, por lo cual será necesario solicitar acceso al repositorio del proyecto, y seguir los pasos indicados en el README del proyecto para poder levantarlo y ejecutarlo correctamente.
Se deberá confirmar con los desarrolladores la instalación de la librería de Playwright en el proyecto, así como la ubicación ideal para guardar los archivos de pruebas generados.
**El diseño de estas pruebas deberá trabajarse en la rama de desarrollo del proyecto.**
### Registro de BUGs
Si alguno de los casos de prueba no cumple con lo esperado, y se define como No pasado, se deberá generar la tarjeta de Bug correspondiente dentro del tablero del proyecto.
Los bugs registrados deben ser descriptivos, e incluir todas las evidencias necesarias para que cualquier desarrollador pueda facilmente replicar y observar el error (incluso si no fueron ellos quienes desarrollaron la función que está fallando), es por esto que es muy importante no omitir, o asumir, que determinado dato o situación "se entiende" por si solo.
Incluye en el registro del bug con los pasos exactos para replicar el error, especificando siempre el ambiente donde se encontró, el usuario que lo experimentó, y complementa con fotos o videos que muestren claramente el problema, y como este difiere del resultado esperado en relación a los requerimientos de la funcionlidad, o como es que compromete la experiencia del usuario en el sistema.
Las fotos y videos que se incluyan deben señalar con claridad el problema, recomendamos para esto el uso de la herramienta de Recortes en Windows para agregar señalamientos a las fotos. Y el uso de la herramienta web [JAM](https://jam.dev/), para la captura de videos cortos.
**Incluir una foto o video donde no se pueda entender rápidamente lo que está mal es igual *(o peor)* que no incluir nada.**
De igual manera, es importante que agregar al colaborador asignado para atender el error, por lo regular es la misma persona que estaba asignada a la funcionalidad que presenta el error, pero si no estás seguro confirma con el PM quién puede tomar la asignación. Y no olvides de igual manera asignarte a ti mismo a la tarjeta, pues posteriormente estarás realizando la validación de las correcciones.
Cuando se finalice la creación de la tarjeta, se deberá notificar al desarrollador a cargo a través de un mensaje por Discord, en el canal oficial del proyecto.
Para mayor referencia en cuanto a la creación de tarjetas de tipo Bug y el llenado de todos los campos, consulta las actividades del QA en el [Procedimiento de Desarrollo](https://mediaaereanet.sharepoint.com/:w:/r/sites/Procesosprocedimientosyformatos/Documentos%20compartidos/4.%20Proceso%20de%20operaciones/Operaciones%20DS/3.-Desarrollo%20de%20software/MA-OP-DS-PR-48-Desarrollo%20de%20software.docx?d=w4f3d138c29e54dcea0a77b885866f5d0&csf=1&web=1&e=V5HjXC) en SharePoint (si no tienes acceso al link consulta con tu PM)
### Seguimiento de BUGs y re-test
Tras haber dado de alta una tarjeta bug en el tablero, es importante dar seguimiento a la misma, comprobando con regularidad su estado en el tablero. En cuanto se encuentre de nuevo en la columna de QA Pending, significa que se puede proceder con el re-test.
El re-test consiste en ejecutar de nuevo el caso de prueba que originó el error, y verificar que esta vez si se logre el resultado esperado.
Si el bug no surgió de un caso de prueba planificado en la matriz, entonces solo es necesario validar que se haya implementando la corrección indicada en la tarjeta.
Si todo está bien, la tarjeta se pasa a Integration Queue, si el error persiste se deberá regresar a To Do, de nuevo notificando al desarrollador via Discord que el bug no fue resuelto. **No se debe crear una tarjeta de Bug nueva para el mismo error.**
Como equipo de QA, el asegurarse que los bugs se resuelvan es parte del trabajo. **La responsabilidad del QA no termina al dar de alta el bug,** sino hasta que las funcionalidades son liberadas exitosamente en el ambiente de UAT o productivo del proyecto (según sea el caso), por lo tanto, si observas que los bugs no están siendo resueltos, realiza el seguimiento preguntando al desarrollador asignado o al PM del proyecto.
</div>
Sign in via Facebook
Sign in via X(Twitter)
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Connect another wallet