CALIDAD DE SOFTWARE · 6 MIN DE LECTURA
Qué es el QA de software y cómo saber si tu sistema lo necesita
El QA (aseguramiento de la calidad) de software es el conjunto de prácticas que previenen y detectan errores antes de que lleguen a los usuarios: definir qué debe hacer el sistema, probarlo de forma manual y automatizada, y revisar el código. Tu sistema lo necesita si cada actualización rompe algo, si los errores los descubren tus clientes o si nadie se atreve a modificar cierto módulo.
¿Qué es el QA de software?
QA son las siglas de quality assurance, aseguramiento de la calidad. En software significa trabajar de forma sistemática para que el sistema haga lo que debe, no falle en situaciones previsibles y siga funcionando cuando se le hacen cambios. Incluye definir criterios de aceptación, diseñar y ejecutar pruebas, revisar el código y medir qué tan estable es cada versión antes de publicarla.
Para un negocio, el QA se traduce en algo concreto: que los errores aparezcan en un entorno de pruebas y no frente a un cliente, en una factura mal calculada o en un pago duplicado.
¿Cuál es la diferencia entre QA y testing?
Se usan como sinónimos, pero no lo son. El testing es la actividad de ejecutar pruebas para encontrar fallas en algo que ya está construido. El QA es más amplio: incluye el testing, pero también las prácticas que evitan que los errores se introduzcan, como definir bien los requisitos, revisar el código antes de integrarlo, automatizar pruebas que corren en cada cambio y aprender de cada falla para que no se repita.
Dicho de otro modo: el testing responde «¿esto funciona?» y el QA responde «¿cómo nos aseguramos de que siga funcionando?».
Tipos de pruebas de software que conviene conocer
No necesitas todos los tipos de prueba en todos los proyectos. Esta tabla resume los más comunes y para qué sirve cada uno, para que puedas decidir dónde empezar.
| Tipo de prueba | Qué verifica | Ejemplo |
|---|---|---|
| Unitarias | Una función o componente aislado | El cálculo de comisión devuelve el monto correcto |
| De integración | Que dos partes del sistema funcionen juntas | El backend guarda bien lo que envía el formulario |
| De API | Respuestas, errores y contratos de los servicios | Un pedido sin dirección devuelve un error claro, no un 500 |
| De regresión | Que lo que ya funcionaba no se rompió | Tras cambiar descuentos, el cierre de caja sigue cuadrando |
| De extremo a extremo (E2E) | Un flujo completo como lo haría un usuario | Registrarse, comprar y recibir confirmación |
| Análisis estático (SAST) | Errores y vulnerabilidades leyendo el código | Detectar una consulta SQL armada con texto del usuario |
| De aceptación | Que el sistema sirve para el negocio | El equipo de ventas valida el nuevo flujo antes del lanzamiento |
¿Pruebas manuales o automatizadas?
Las dos. Las pruebas manuales son insustituibles para explorar una funcionalidad nueva, detectar problemas de uso y validar que algo tiene sentido para una persona real. Las automatizadas son las que permiten cambiar el sistema con confianza: se ejecutan en segundos cada vez que alguien modifica el código y avisan si se rompió algo que antes funcionaba.
Un punto de partida razonable para un sistema que no tiene pruebas es automatizar primero los flujos que más dinero o más confianza comprometen —cobros, inventario, facturación, accesos— con pruebas de API y de regresión. Herramientas como pytest para Python o Playwright para flujos en el navegador permiten hacerlo sin grandes inversiones de infraestructura.
Señales de que tu sistema necesita QA
No hace falta esperar una falla grave. Estas señales indican que el sistema ya está pagando el costo de no tener control de calidad:
- Cada actualización rompe algo que antes funcionaba.
- Los errores los descubren tus clientes o tu equipo de operación, no los desarrolladores.
- Hay módulos que nadie quiere tocar «porque si se mueve, se cae».
- Publicar una nueva versión implica una noche de estrés y alguien probando a mano todo el sistema.
- No existe un entorno de pruebas: los cambios se prueban directamente en producción.
- Quien construyó el sistema ya no está y no hay documentación ni pruebas que expliquen cómo debe comportarse.
- Manejas dinero, datos personales o información regulada y no hay revisión de seguridad del código.
¿Cuánto cuesta no hacer QA?
El costo de un error crece cuanto más tarde se encuentra. Un fallo detectado mientras se escribe el código se corrige en minutos; el mismo fallo en producción implica atender a los afectados, corregir datos, investigar la causa y, a veces, perder la confianza de un cliente. Un estudio clásico del NIST de Estados Unidos (2002) estimó que la infraestructura inadecuada de pruebas de software le costaba a ese país hasta 59.5 mil millones de dólares al año, y que más de la mitad de ese costo lo absorbían los usuarios del software, no quienes lo desarrollaban.
La cifra es antigua y de otra economía, pero la lógica sigue vigente para cualquier negocio: cuando no se prueba, el costo no desaparece, se traslada a tus usuarios y a tu operación.
Lo que aprendí haciendo QA en una fintech
Trabajé en QA y herramientas internas en ZazPay, una fintech de Culiacán, y después en desarrollo con NestJS y React. En un producto que mueve dinero, la calidad no es una etapa al final: es parte de cada cambio. Mi trabajo incluyó construir herramientas de automatización y validación, y pipelines para analizar varios repositorios a la vez. De esa experiencia nació ScriptC, un orquestador local que ejecuta varios motores de análisis estático y reúne sus resultados en una sola herramienta.
También evalué código generado por modelos de IA en Outlier, revisando corrección técnica y errores de lógica en Python y JavaScript. Esa experiencia confirma algo útil para cualquier negocio que hoy genera código con IA: el código que parece correcto no siempre lo es, y las pruebas son la forma más barata de comprobarlo.
La lección más práctica que me llevo es empezar por lo que más duele. No hace falta una cobertura total para notar la diferencia: proteger con pruebas los tres o cuatro flujos críticos ya cambia la forma en que el equipo publica.
¿Qué debe incluir un servicio de QA?
Si vas a contratar QA para un sistema existente, pide que el trabajo deje algo que siga funcionando cuando el proveedor se vaya. Un reporte de errores en PDF ayuda una vez; una batería de pruebas automatizadas conectada a tu proceso de despliegue ayuda cada vez que alguien cambia el código.
Como mínimo, un servicio de QA serio debería entregarte un diagnóstico priorizado de riesgos, pruebas automatizadas de los flujos críticos que puedas ejecutar tú mismo, la integración de esas pruebas con tu repositorio y una explicación clara de qué quedó cubierto y qué no. Desconfía de quien promete encontrar todos los errores: ninguna estrategia de pruebas lo logra, y decirlo con honestidad es parte del trabajo.
Cómo empezar con QA si hoy no tienes nada
Si tu sistema no tiene pruebas, este es un orden que funciona sin detener el desarrollo:
- Haz una lista de los flujos que, si fallan, cuestan dinero o clientes.
- Crea un entorno de pruebas separado de producción, con datos ficticios.
- Automatiza pruebas de API y regresión para esos flujos críticos.
- Conecta las pruebas al proceso de despliegue para que corran en cada cambio.
- Agrega análisis estático para detectar errores comunes y vulnerabilidades.
- Cada vez que aparezca un error en producción, escribe la prueba que lo habría detectado.