≡En resumen
- El QA es un enfoque preventivo: define cómo se trabaja para que los errores no lleguen a producción.
- El control de calidad (QC) y el testing son partes del QA: detectan fallos en el producto ya construido.
- Un plan de pruebas fija qué se prueba, cómo, con qué datos, en qué entornos y cuándo se da algo por aprobado.
- La automatización cubre las pruebas repetitivas (unitarias, de integración, regresión); las exploratorias siguen siendo manuales.
- En una web, el QA incluye accesibilidad, rendimiento, seguridad y compatibilidad, no solo que «funcione».
01 ¿Qué es el quality assurance (QA)?
El concepto nace en la industria: la norma ISO 9000 describe el aseguramiento de la calidad como la parte de la gestión de la calidad orientada a proporcionar confianza en que se cumplirán los requisitos. En software, la palabra «QA» se usa también para nombrar al equipo o al perfil profesional (el QA engineer o QA tester) que diseña y ejecuta las pruebas.
En un proyecto de desarrollo de aplicaciones web a medida, el QA empieza el primer día: cuando se escriben los requisitos ya se decide cómo se va a comprobar cada uno.
02 QA vs QC vs testing: diferencias
| Quality assurance (QA) | Quality control (QC) | Testing | |
|---|---|---|---|
| Enfoque | Preventivo | Detectivo | Detectivo |
| Sobre qué actúa | El proceso | El producto | Una parte concreta del producto |
| Pregunta | ¿Trabajamos de forma que salga bien? | ¿El resultado cumple los requisitos? | ¿Esta función hace lo que debe? |
| Ejemplos | Estándares de código, definición de «hecho», revisiones, CI | Revisión final, auditoría antes de publicar | Pruebas unitarias, de integración, de usabilidad |
| Cuándo | Durante todo el ciclo | Al final de cada entrega | En cada cambio o fase |
03 Tipos de pruebas en el QA de software y webs
| Tipo | Qué comprueba | Manual o automática |
|---|---|---|
| Unitarias | Que cada función o clase devuelve lo esperado de forma aislada | Automática |
| De integración | Que los módulos funcionan juntos (API, base de datos, pasarela de pago) | Automática |
| End-to-end (E2E) | Recorridos completos del usuario en un navegador real: alta, compra, contacto | Automática, con Playwright, Cypress o Selenium |
| De regresión | Que un cambio nuevo no rompe lo que ya funcionaba | Automática (se reejecuta en cada despliegue) |
| Exploratorias | Fallos que nadie previó, usando la aplicación con criterio | Manual |
| De usabilidad | Que usuarios reales entienden y completan las tareas | Manual |
| De rendimiento y carga | Tiempos de respuesta y comportamiento con muchos usuarios a la vez | Automática |
| De seguridad | Vulnerabilidades conocidas: inyección, control de acceso, dependencias | Mixta |
| De accesibilidad | Que personas con discapacidad pueden usar la web (WCAG) | Mixta |
| De compatibilidad | Navegadores, sistemas operativos y tamaños de pantalla | Mixta |
La proporción recomendada suele representarse como una pirámide de pruebas: muchas pruebas unitarias (rápidas y baratas), menos de integración y pocas end-to-end (lentas y frágiles). Invertir la pirámide, con casi todo probado a mano desde la interfaz, es la receta para lanzamientos lentos y errores que vuelven.
04 Cómo hacer un plan de pruebas (test plan)
-
1
Alcance
Qué funciones entran en la prueba y cuáles no. Por ejemplo: checkout, área privada y formularios; el blog queda fuera.
-
2
Criterios de aceptación
Cada requisito con una condición comprobable: «el pedido se confirma por email en menos de un minuto».
-
3
Casos de prueba
Pasos, datos de entrada y resultado esperado para cada escenario, incluidos los caminos de error (tarjeta rechazada, campo vacío).
-
4
Entornos y datos
Dónde se prueba (staging idéntico a producción), con qué navegadores y dispositivos, y con datos de prueba, nunca datos reales de clientes.
-
5
Automatización e integración continua
Qué pruebas se ejecutan solas en cada cambio y cuáles se hacen a mano antes de cada versión.
-
6
Gestión de incidencias
Cómo se registran los fallos, con qué prioridad y quién los valida una vez corregidos.
-
7
Criterios de salida
Cuándo se puede publicar: por ejemplo, cero fallos críticos abiertos y todas las pruebas de regresión en verde.
ID: CP-014. Objetivo: comprobar que el formulario rechaza un email mal escrito.
- Abrir /contacto/ en Chrome y en Safari móvil.
- Rellenar nombre y mensaje, y escribir «ana@correo» en el email.
- Pulsar «Enviar».
Resultado esperado: no se envía nada, aparece junto al campo el texto «Escribe un email válido», el foco vuelve al campo y el lector de pantalla anuncia el error. Resultado obtenido: se rellena al ejecutar la prueba. Si no coincide con el esperado, se abre una incidencia con captura y entorno.
05 Testing automatizado: qué automatizar y qué no
Automatiza
Lo que se repite en cada versión: pruebas unitarias, de integración, regresión de los recorridos críticos, validación de formularios y comprobaciones de accesibilidad básicas.
No automatices (todavía)
Funciones que cambian cada semana, pruebas exploratorias y juicios de usabilidad o de diseño, que necesitan criterio humano.
Integra en el pipeline
Las pruebas deben ejecutarse solas en cada cambio de código (integración continua) y bloquear el despliegue si fallan.
Mide la cobertura con cabeza
Un porcentaje alto de cobertura no garantiza calidad. Prioriza que estén cubiertos los flujos que generan ingresos.
El QA también afecta a cómo trabaja el equipo en local: un entorno de desarrollo reproducible evita el clásico «en mi máquina funciona». Y en apps móviles se suma probar en dispositivos reales, algo que cualquier empresa de desarrollo de apps a medida debe incluir en su presupuesto.
06 QA de accesibilidad web
La accesibilidad ya no es opcional para muchas empresas: la Ley Europea de Accesibilidad (EAA) se aplica desde el 28 de junio de 2025 a productos y servicios como el comercio electrónico. La referencia técnica son las pautas WCAG del W3C, cuya versión 2.2 es recomendación desde octubre de 2023. Te lo explicamos en la guía sobre qué exige la ley europea de accesibilidad.
- ✓Pasar un analizador automático (Lighthouse, axe) en cada plantilla: detecta contrastes, textos alternativos y etiquetas que faltan.
- ✓Recorrer la web solo con teclado: foco visible, orden lógico y sin trampas de foco.
- ✓Probar con un lector de pantalla (NVDA, VoiceOver) los formularios y el checkout.
- ✓Comprobar el zoom al 200 % y la visualización en móvil sin perder contenido.
- ✓Revisar que los errores de formulario se anuncian con texto, no solo con color.
Valida también el marcado con un validador de HTML: etiquetas mal cerradas, IDs duplicados o atributos ARIA incorrectos confunden a los lectores de pantalla aunque la página se vea bien. Según el informe anual WebAIM Million, que analiza un millón de portadas, entre los fallos más repetidos están el contraste insuficiente, las imágenes sin texto alternativo y los campos de formulario sin etiqueta asociada, y los tres se detectan en minutos si forman parte del plan de pruebas desde el principio.
07 QA después del lanzamiento
El aseguramiento de la calidad no termina al publicar. Las actualizaciones de plugins, del CMS o de dependencias pueden romper funciones que llevaban meses bien. Por eso un buen plan de mantenimiento web incluye pruebas de regresión tras cada actualización, copias de seguridad verificadas y monitorización.
- ✓Monitorización de disponibilidad y de errores de servidor.
- ✓Alertas de errores de JavaScript en el navegador de los usuarios.
- ✓Pruebas automáticas periódicas del formulario de contacto y del checkout.
- ✓Revisión de rendimiento (Core Web Vitals) tras cada cambio importante.
- ✓Actualizaciones de seguridad aplicadas primero en un entorno de pruebas.
Preguntas frecuentes sobre Quality assurance (QA)
QA significa quality assurance, aseguramiento de la calidad: los procesos que garantizan que un producto cumple sus requisitos. En tecnología también se llama QA al equipo o perfil que diseña y ejecuta las pruebas.
El QA es preventivo y actúa sobre el proceso de trabajo; el QC (quality control) es detectivo y revisa el producto terminado para encontrar defectos. El QC forma parte del QA.
Diseña casos de prueba, ejecuta pruebas manuales y automáticas, registra los fallos de forma reproducible y valida las correcciones antes de cada versión.
Es el documento que fija el alcance de las pruebas, los criterios de aceptación, los casos de prueba, los entornos y datos, qué se automatiza y cuándo se considera lista una versión.
Las repetitivas y estables: unitarias, de integración y de regresión de los recorridos críticos. Las pruebas exploratorias y de usabilidad necesitan personas.
Para pruebas end-to-end en navegador se usan Playwright, Cypress o Selenium; para accesibilidad, Lighthouse y axe; y para pruebas unitarias, el framework de cada lenguaje, como PHPUnit o Jest.
Añade horas al desarrollo, pero reduce el coste total: un fallo detectado en el diseño o en una prueba automática se corrige mucho más barato que uno que llega a producción y afecta a clientes.
Fuentes consultadas
Sobre el autor
Germán Gutiérrez
Development Manager en appyweb
Dirige el equipo de desarrollo de appyweb: aplicaciones web y móviles, SaaS, integraciones y arquitectura de software.
Ver perfil en LinkedIn ↗