Conceptos técnicos
QA.
Tu guía de referencia para entender todos los conceptos del mundo QA, organizados por nivel. Desde los fundamentos hasta lo más avanzado.
Antes de empezar
Sé lo que estás pensando. Teoría. Definiciones. No es lo más emocionante del mundo.
Pero déjame explicarte por qué esta guía existe y por qué merece la pena que le dediques un rato.
Cuando empiezas en el mundo QA, es fácil querer ir directo a lo práctico: abrir Jira, ejecutar pruebas, reportar bugs. Y eso está bien. Pero si no tienes claros ciertos conceptos básicos, llegará un momento en que algo no cuadrará y no sabrás por qué.
¿Qué diferencia hay entre un smoke test y un sanity test? ¿Por qué el QA testea en staging y no en producción? ¿Qué significa exactamente que una API devuelve un 403?
Esta guía no está aquí para que te aprendas las definiciones de memoria. Está para que entiendas las cosas. Para que cuando alguien en tu equipo mencione un término, sepas de qué está hablando. Para que tengas una base sólida sobre la que construir todo lo demás.
Úsala como referencia. Vuelve a ella cuando algo no te quede claro. No hace falta leerla de principio a fin de una sentada.
Nivel Básico
Los fundamentos que todo QA necesita conocer desde el primer día
QA vs QC vs Testing
Estos tres términos se usan a menudo como sinónimos, pero tienen significados distintos. Entender la diferencia te ayuda a comprender mejor tu rol.
| Término | Qué significa | Cuándo actúa | Enfoque |
|---|---|---|---|
| QA — Quality Assurance | Aseguramiento de la calidad | Durante todo el proceso | Prevenir defectos |
| QC — Quality Control | Control de calidad | Al final del proceso | Detectar defectos |
| Testing | Pruebas | En fases concretas | Ejecutar y verificar |
El QA es preventivo, el QC es correctivo y el Testing es la herramienta que usa tanto uno como el otro.
Tipos de testing
Existen dos grandes categorías que agrupan todos los tipos de pruebas:
| Tipo | Qué verifica | Ejemplos |
|---|---|---|
| Testing funcional | Que el sistema hace lo que debe hacer | Unit, integration, E2E, regresión |
| Testing no funcional | Cómo lo hace (rendimiento, seguridad...) | Performance, security, usability |
| Testing manual | Ejecutado por una persona | Exploratorio, ad-hoc |
| Testing automatizado | Ejecutado por código | Unit tests, E2E con Cypress/Playwright |
| Testing de caja negra | Sin conocer el código interno | La mayoría del testing QA |
| Testing de caja blanca | Conociendo el código interno | Unit tests de desarrolladores |
Ciclo de vida de un bug
Cuando un QA encuentra un bug, ese bug pasa por una serie de estados hasta que se cierra. Entender este ciclo es fundamental para gestionar bien los defectos.
Estados por los que pasa un bug desde que se detecta hasta que se cierra
| Estado | Significado |
|---|---|
| Nuevo | El bug acaba de ser reportado |
| Asignado | Se ha asignado a un desarrollador |
| En proceso | El dev está trabajando en la corrección |
| Resuelto | El dev dice que está corregido, pendiente de verificación |
| Rechazado | No se considera un bug (comportamiento esperado, duplicado...) |
| Cerrado | El QA ha verificado que está corregido |
| Reabierto | El QA verifica y el bug sigue presente |
Entornos de desarrollo
En cualquier empresa tech el código no va directamente del desarrollador al usuario. Pasa por una serie de entornos antes de llegar a producción.
Flujo típico de despliegue desde desarrollo hasta producción
Como QA, tu trabajo principal ocurre en el entorno de Staging. Nunca deberías testear directamente en producción salvo casos muy excepcionales.
Happy path, casos negativos y corner cases
Cuando diseñas casos de prueba, tienes que cubrir diferentes tipos de situaciones:
- Happy path — El flujo ideal donde todo funciona como se espera. Es lo primero que pruebas, pero nunca lo único.
- Casos negativos — Pruebas que el sistema gestiona bien los errores. Contraseña incorrecta, tarjeta caducada, formulario vacío.
- Casos límite (edge cases) — Los extremos: el campo que acepta exactamente 255 caracteres, la fecha del 29 de febrero, el precio de 0€.
- Corner cases — Combinaciones poco probables pero posibles que pueden revelar comportamientos inesperados.
Un buen QA no solo prueba que las cosas funcionan. También prueba que fallan correctamente cuando deben fallar.
La pirámide de testing
La pirámide de testing es un modelo visual que explica la proporción ideal entre los diferentes tipos de pruebas en un proyecto.
La pirámide de testing: cuántas pruebas de cada tipo deberías tener
- Base (Unit Tests) — Muchos, rápidos y baratos. Los escriben los desarrolladores para probar funciones individuales.
- Medio (Integration Tests) — Prueban que varios componentes funcionan bien juntos.
- Cima (E2E Tests) — Pocos, lentos y caros. Simulan el comportamiento real del usuario de principio a fin.
- Cúspide (Manual/Exploratorio) — Criterio humano donde la máquina no llega.
Invertir la pirámide (muchos E2E y pocos unit tests) es un error común que hace los proyectos lentos y frágiles.
Nivel Intermedio
Conceptos para quien ya tiene base y quiere profundizar
Regresión, smoke y sanity testing
Estos tres tipos de pruebas se confunden frecuentemente. Cada uno tiene un propósito específico y un momento concreto de aplicación.
| Tipo | Propósito | Cuándo | Alcance |
|---|---|---|---|
| Smoke Testing | Verificar que lo básico funciona antes de testear en profundidad | Al recibir una nueva build | Muy superficial y rápido |
| Sanity Testing | Verificar que una funcionalidad concreta funciona tras un cambio | Tras una corrección puntual | Focalizado en un área |
| Regresión | Asegurar que nada existente se ha roto tras un cambio | Antes de cada release | Amplio, cubre todo |
Si el smoke falla, no pierdas tiempo haciendo más pruebas. Para, reporta y devuelve la build al equipo de desarrollo.
Gestión de casos de prueba
Un caso de prueba bien escrito es la diferencia entre un QA que aporta valor y uno que solo ejecuta pasos. Estos son los elementos que no pueden faltar:
- ID — Identificador único del caso
- Título — Descripción clara de qué se está probando
- Precondiciones — Estado del sistema antes de ejecutar el test
- Pasos — Acciones a realizar, en orden y sin ambigüedad
- Resultado esperado — Qué debe ocurrir exactamente
- Resultado obtenido — Qué ocurrió realmente
- Estado — Passed, Failed, Blocked, Not executed
Un caso de prueba tiene que poder ejecutarlo alguien que no conoce el producto. Si necesita contexto adicional, es que le falta información.
BDD y Gherkin
BDD (Behavior Driven Development) es una metodología que busca que toda la definición de una funcionalidad se escriba en un lenguaje que cualquier persona del equipo pueda entender, técnica o no.
Para eso usa Gherkin, un formato con una estructura muy concreta:
Scenario: Login con credenciales correctas
Given que soy un usuario registrado
And estoy en la página de login
When introduzco mi email y contraseña correctos
And pulso en "Acceder"
Then el sistema me redirige a la página principal
And veo mi nombre en la cabecera
Lo que hace poderoso al BDD no es el formato, es el proceso: escribir los escenarios antes de desarrollar obliga a todo el equipo a alinearse sobre qué debe hacer exactamente el sistema.
Testing de APIs
Una API (Application Programming Interface) es la capa de comunicación entre sistemas. Cuando un usuario pulsa un botón en una app, entre bastidores se están produciendo llamadas a APIs.
Flujo básico de una llamada API entre cliente y servidor
Los códigos de respuesta HTTP más importantes que un QA debe conocer:
| Código | Significado | Cuándo aparece |
|---|---|---|
| 200 OK | Todo correcto | Petición exitosa |
| 201 Created | Recurso creado | Al crear un usuario, un pedido... |
| 400 Bad Request | Petición incorrecta | Datos mal formados o incompletos |
| 401 Unauthorized | No autenticado | Token inválido o expirado |
| 403 Forbidden | Sin permisos | El usuario no tiene acceso |
| 404 Not Found | No encontrado | El recurso no existe |
| 500 Internal Server Error | Error del servidor | Algo ha fallado en el backend |
Testing automatizado: conceptos clave
El testing automatizado es escribir código que ejecuta pruebas de forma automática. No sustituye al testing manual, lo complementa.
| Concepto | Descripción |
|---|---|
| Framework | Estructura base sobre la que se construyen los tests (Cypress, Playwright, Selenium, Jest...) |
| Locator | La forma de identificar un elemento en la página (ID, clase CSS, XPath, texto...) |
| Assertion | La verificación que hace el test: "esto debería ser igual a esto" |
| Test Suite | Conjunto de tests agrupados por funcionalidad o módulo |
| Flaky test | Test que a veces pasa y a veces falla sin que el código haya cambiado. Son peligrosos porque generan ruido |
| Mock | Simulación de un componente externo (API, base de datos) para aislar lo que se está probando |
Automatizar por automatizar es un error. Solo vale la pena automatizar lo que se ejecuta frecuentemente, es estable y no requiere criterio humano.
Cobertura de pruebas
La cobertura de pruebas mide qué porcentaje del código o de la funcionalidad está cubierto por tests. Es una métrica útil pero que hay que interpretar con criterio.
- Cobertura de código — Qué porcentaje de líneas de código se ejecutan durante los tests
- Cobertura funcional — Qué porcentaje de los requisitos o casos de uso están cubiertos por pruebas
- Cobertura de ramas — Si el código tiene condiciones (if/else), cuántas ramas se han probado
Un 100% de cobertura de código no significa que el software no tenga bugs. Significa que todo el código se ejecuta durante los tests, pero los tests pueden estar mal diseñados.
Nivel Avanzado
Para QAs que quieren ir más allá y entender el testing a nivel estratégico
CI/CD y el rol del QA
CI (Continuous Integration) es la práctica de integrar cambios de código frecuentemente, ejecutando tests automáticamente en cada integración.
CD (Continuous Delivery/Deployment) es la práctica de automatizar el despliegue del código a producción de forma segura y frecuente.
Pipeline típico de CI/CD y los puntos donde el QA aporta valor
En un pipeline bien configurado, si cualquier test falla, el despliegue se detiene automáticamente. El QA diseña qué tests forman parte del pipeline y cuáles son bloqueantes.
Shift-left testing
El shift-left testing es la práctica de mover las actividades de testing lo más a la izquierda posible en el ciclo de desarrollo, es decir, empezar a testear cuanto antes.
Tradicionalmente el testing ocurría al final del proceso. Con shift-left, el QA se involucra desde la fase de definición de requisitos, revisa las historias de usuario, participa en los refinements y detecta problemas antes de que se escriba una sola línea de código.
- Detectar un bug en requisitos cuesta muy poco
- Detectarlo en desarrollo cuesta más
- Detectarlo en testing cuesta bastante
- Detectarlo en producción cuesta mucho más y tiene impacto real en usuarios
Cuanto antes se detecta un problema, más barato es corregirlo. El shift-left no es una metodología, es una mentalidad.
Testing basado en riesgo
Cuando el tiempo es limitado (y siempre lo es), hay que decidir qué testear primero. El testing basado en riesgo prioriza las pruebas según la probabilidad de fallo y el impacto que tendría ese fallo.
| Probabilidad de fallo | Impacto alto | Impacto bajo |
|---|---|---|
| Alta | Prioridad máxima — testear primero y en profundidad | Prioridad media — testear con cobertura básica |
| Baja | Prioridad alta — asegurarse de que funciona | Prioridad baja — testear si hay tiempo |
El flujo de pago de un ecommerce tiene impacto alto. Si falla, el negocio no factura. Siempre va primero.
Métricas de calidad
Las métricas permiten medir objetivamente la calidad del proceso y del producto. Estas son las más usadas:
| Métrica | Qué mide | Fórmula / Cómo se calcula |
|---|---|---|
| Defect Density | Concentración de bugs por módulo | Nº bugs / tamaño del módulo |
| Defect Escape Rate | Bugs que llegan a producción | Bugs en prod / total bugs encontrados |
| Test Pass Rate | Porcentaje de tests que pasan | Tests OK / total tests ejecutados |
| Mean Time to Detect | Tiempo medio en detectar un bug | Tiempo desde introducción hasta detección |
| Flaky Test Rate | Tests no fiables | Tests inestables / total tests automatizados |
Las métricas son útiles para tomar decisiones, no para juzgar personas. Un equipo con muchos bugs reportados puede ser simplemente un equipo con un buen QA.
Testing de seguridad básico
El testing de seguridad verifica que el sistema protege los datos y resiste ataques. Para un QA no especializado, lo importante es conocer los conceptos más comunes:
- SQL Injection — Introducir código SQL en campos de formulario para manipular la base de datos
- XSS (Cross-Site Scripting) — Inyectar scripts maliciosos en páginas web
- Autenticación y autorización — Verificar que los usuarios solo acceden a lo que les corresponde
- HTTPS y cifrado — Que los datos sensibles viajan cifrados
- Exposición de datos sensibles — Que contraseñas, tokens o datos personales no aparezcan en logs o respuestas de API
No hace falta ser un experto en seguridad para hacer testing de seguridad básico. Muchas vulnerabilidades se detectan con sentido común y curiosidad.
¿Listo para poner en práctica todo esto?
Conocer los conceptos es el primer paso. El siguiente es aprender a aplicarlos en situaciones reales. Para eso están los cursos de fundamentos.