Qué es QA de software y por qué exigirlo en tu proyecto

Qué es QA de software (aseguramiento de calidad): diferencia con testing, fases, tipos de pruebas, manual vs automatizado y qué pedir a tu agencia o proveedor.

Qué es QA de software y por qué exigirlo en tu proyecto

Definición

Inesdi (artículo consultado el 08/09/2026) define el QA testing como un proceso de pruebas que se lleva a cabo para asegurar la calidad final en un software antes de su lanzamiento. Y distingue los dos términos que suelen confundirse: el QA es un enfoque que se centra en asegurar la calidad del software durante todo el proceso de desarrollo, mientras que el testing es una parte concreta dentro del QA. Son complementarios, pero no comparten funciones.

En términos prácticos: el testing es ejecutar pruebas y encontrar defectos; el QA es todo lo que hace que esos defectos sean menos, se encuentren antes y no vuelvan. Incluye revisar los requisitos para que sean verificables, definir criterios de aceptación, revisar el código, automatizar pruebas y medir la calidad de cada entrega.

Las fases del proceso

Inesdi describe cinco etapas:

  1. Planificación: se definen objetivos, recursos y cronograma de las pruebas.
  2. Diseño: se crean los casos de prueba y se preparan los datos.
  3. Ejecución: los testers ponen a prueba el software.
  4. Registro y reporte: los errores se documentan en detalle, con pasos para reproducirlos.
  5. Validación y cierre: se verifica que los defectos fueron corregidos.

Lo importante para quien contrata es la primera fase: si los casos de prueba se escriben a partir de los requisitos, cada requisito ambiguo sale a la luz antes de programar. Un requisito como el sistema debe ser rápido no se puede probar; la página de resultados debe cargar en menos de dos segundos con mil productos, sí. Ese trabajo temprano es parte de lo que separa un producto mínimo bien planteado de uno que hay que rehacer; lo tratamos en MVP de software: valida tu idea rápido.

Tipos de pruebas

Inesdi separa dos familias. Las pruebas funcionales verifican que cada función, botón, formulario o proceso hace su trabajo según los requisitos. Las no funcionales evalúan cómo actúa el sistema: rendimiento, seguridad y usabilidad.

Dentro de esas familias, las pruebas más habituales en un proyecto web o de app son:

  • Unitarias: cada pieza pequeña de código, escritas por los propios desarrolladores.
  • De integración: que las piezas conversen bien entre sí y con servicios externos (pasarela de pagos, facturación electrónica, correo).
  • Funcionales o de aceptación: el flujo completo tal como lo usará una persona, contra los criterios acordados.
  • De regresión: repetir las pruebas anteriores después de cada cambio para confirmar que nada que funcionaba se rompió.
  • De rendimiento y carga: cómo responde el sistema con muchos usuarios a la vez; su impacto en el negocio está en velocidad web y UX.
  • De seguridad: validación de entradas, permisos, protección de datos.
  • De compatibilidad: navegadores, dispositivos y tamaños de pantalla.

Manual o automatizado

Según Inesdi, las pruebas manuales las realiza el tester y las automatizadas usan herramientas que ejecutan scripts de forma repetitiva. Ninguna reemplaza a la otra. Las manuales exploran, juzgan la usabilidad y encuentran lo inesperado; las automatizadas repiten cientos de comprobaciones en minutos cada vez que se sube un cambio, y son la única forma realista de hacer regresión en un sistema que evoluciona.

Una regla útil para quien contrata: los flujos que generan dinero o riesgo (registro, pago, emisión de comprobante, inicio de sesión) deberían tener pruebas automatizadas que se ejecuten antes de cada despliegue. Si la agencia hace todo a mano, cada actualización es una apuesta. Esa disciplina de despliegue con pruebas es también lo que permite modernizar un sistema sin detener la operación, como explicamos en software obsoleto: modernízalo.

Por qué importa para tu negocio

Un error encontrado en requisitos cuesta una conversación; encontrado en desarrollo, unas horas; encontrado en producción, cuesta ventas, reputación y a veces datos. En un ecommerce, un fallo en el checkout se traduce en carritos abandonados; en un sistema interno, en horas de retrabajo. El QA no elimina los errores, pero mueve su detección hacia el momento en que corregirlos es barato.

También define el costo real de un proyecto. Una propuesta sin QA parece más barata y termina más cara: el tiempo de corregir en producción y el desgaste del equipo no aparecen en la cotización inicial, pero se pagan. Los componentes de una cotización completa están en cuánto cuesta desarrollar una app en Perú.

Qué pedir a tu agencia o proveedor

  • Criterios de aceptación escritos por funcionalidad antes de programar.
  • Un plan de pruebas: qué se prueba, cómo, en qué ambiente y con qué datos.
  • Pruebas automatizadas de los flujos críticos y ejecución antes de cada despliegue.
  • Un ambiente de pruebas separado de producción, con datos que no sean los reales de tus clientes.
  • Reporte de defectos con severidad y estado, visible para ti.
  • Pruebas de regresión en cada entrega y un periodo de garantía después del lanzamiento.
  • Que el QA lo haga alguien distinto de quien programó, al menos en la aceptación.

Estos puntos deberían formar parte de la evaluación de cualquier proveedor, junto con el portafolio y la metodología; los demás criterios están en qué evaluar al elegir tu agencia web. Si contratas un equipo externo, define en el contrato quién hace el QA, con qué cobertura y cómo se reportan los defectos; lo detallamos en outsourcing de desarrollo de software: cuándo conviene.

QA y tu rol como cliente

El QA no es solo del proveedor. Tú aportas los criterios de aceptación (qué debe pasar para que apruebes una función), los datos de prueba realistas y las pruebas de aceptación con personas de tu operación. Un cliente que prueba con casos reales (el pedido con tres direcciones, la factura con nota de crédito, el usuario que olvidó su clave) encuentra lo que ningún tester externo conoce de tu negocio.

Qué hacer ahora

Si tienes un proyecto en marcha, pide el plan de pruebas y la lista de flujos críticos automatizados; si no existen, ahí está el primer riesgo. Si estás por contratar, incluye en la solicitud de propuesta los siete puntos de la lista anterior y compara cómo responde cada proveedor. Si quieres una propuesta de desarrollo con QA integrado, ambientes de prueba y pruebas automatizadas de tus flujos de negocio, escríbenos por WhatsApp.

Preguntas frecuentes

Qué diferencia hay entre QA y testing
Según Inesdi, el QA es el enfoque que asegura la calidad durante todo el proceso de desarrollo, desde los requisitos hasta la entrega, y el testing es una parte concreta dentro del QA: ejecutar pruebas para encontrar defectos. Se necesitan ambos, pero no son lo mismo.
Las pruebas automatizadas reemplazan a un tester
No. Las automatizadas repiten comprobaciones conocidas en cada cambio, sobre todo en flujos críticos, y son la base de la regresión. El tester explora, evalúa la usabilidad y encuentra lo que nadie previó. Un proyecto serio combina ambas.
Cuánto del presupuesto de un proyecto debería ir a QA
No hay un porcentaje fijo: depende del riesgo del sistema. Un ecommerce con pagos o un sistema con datos personales necesita más cobertura que una web informativa. Lo importante es que la propuesta detalle qué se prueba, cómo y cuándo, en lugar de omitirlo para parecer más barata.

Es hora de despegar
con Impulsa Studio

Usamos lo último en tecnología para desarrollar soluciones que impulsen tu proyecto. Pero antes de empezar, dinos: ¿qué quieres hacer?