Testing de software: guía para empezar en QA

¿Qué es el testing de software?

El testing de software compara el comportamiento real de un sistema con lo que se espera de él, y produce información que alguien va a usar para decidir. Esa última parte es la que suele perderse: una prueba que nadie mira, o cuyo resultado no cambia ninguna decisión, es trabajo desperdiciado por más rigurosa que sea.

Conviene desarmar tres palabras que se usan como sinónimos y no lo son. Una persona comete un error; ese error introduce un defecto en el código, la configuración o la documentación; y el defecto produce un fallo cuando alguien ejecuta la parte afectada. Un defecto puede vivir años sin producir ningún fallo porque nadie recorrió ese camino. Cuando reportás, describís el fallo que observaste y aportás lo necesario para que el equipo encuentre el defecto.

También conviene aceptar temprano una limitación estructural: probar exhaustivamente es imposible. Un formulario con diez campos de texto libre tiene más combinaciones posibles que tiempo disponible en el proyecto. Por eso el estándar ISO/IEC/IEEE 29119-1:2022 propone el enfoque basado en riesgo como base para planificar: se invierte más esfuerzo donde el impacto de un fallo y su probabilidad son mayores, y esa decisión se deja registrada.

QA y testing no son lo mismo

La confusión entre ambos términos es la más común al empezar, y explica por qué muchos avisos de trabajo piden cosas contradictorias.

La consecuencia práctica es simple: revisar un requisito ambiguo antes de que se programe es una actividad de calidad tan legítima como ejecutar una prueba, y suele ser mucho más barata. La revisión estática —leer requisitos, diseños o código sin ejecutarlos— está contemplada como parte del testing en la propia norma, no como algo aparte.

Los tipos de prueba que vas a encontrar

Las pruebas se clasifican de varias maneras a la vez, y por eso los nombres se superponen. Una misma prueba puede ser funcional, automatizada y de integración al mismo tiempo. Estas son las tres clasificaciones que más se usan.

Por lo que evalúan

• Funcionales: verifican qué hace el sistema. Reglas de negocio, cálculos, permisos, flujos.
• No funcionales: verifican cómo lo hace. Rendimiento, seguridad, accesibilidad, compatibilidad, usabilidad.

Por el nivel al que se aplican

• Unitarias: una función o clase aislada, sin dependencias reales.
• De integración: varios componentes trabajando juntos, incluidas bases de datos y servicios externos.
• De sistema: el producto completo en un entorno parecido al de producción.
• De aceptación: ¿resuelve esto la necesidad de quien lo pidió? Suele participar el área usuaria.

Por cómo se ejecutan

• Manuales guionadas: alguien sigue pasos definidos de antemano.
• Exploratorias: se diseña, ejecuta y aprende al mismo tiempo. Encuentran lo que nadie pensó en escribir.
• Automatizadas: código que ejecuta verificaciones repetibles.

La pirámide se lee de abajo hacia arriba. Las pruebas unitarias se ejecutan en milisegundos, fallan señalando exactamente qué se rompió y casi no necesitan mantenimiento, así que conviene tener muchas. Las de extremo a extremo recorren el sistema completo y dan la confianza más parecida a la experiencia real, pero son lentas, dependen de datos y entornos, y suelen fallar por motivos que no tienen que ver con el producto. Por eso se reservan para los caminos críticos.

Cómo diseñar casos de prueba útiles

Un caso de prueba tiene que ser reproducible por otra persona y estar orientado a una decisión. Como no se puede probar todo, existen técnicas para elegir pocos casos con alta probabilidad de encontrar problemas. Estas dos son las que más rinden al empezar.

Particiones de equivalencia

Se agrupan las entradas en clases donde el sistema debería comportarse igual, y se prueba un valor de cada clase en lugar de todos. Si un campo acepta edades de 18 a 65, las clases son: menores de 18, entre 18 y 65, y mayores de 65. Tres casos en lugar de cien.

Valores límite

Los defectos se concentran en los bordes de esas clases, porque ahí es donde se escriben las comparaciones y donde es fácil confundir «mayor que» con «mayor o igual que». Para el rango de 18 a 65 se prueban 17, 18, 65 y 66.

// Los cuatro valores límite del rango 18-65, no cien edades al azar
describe('validarEdad', () => {
  test('rechaza el valor justo por debajo del mínimo', () => {
    expect(validarEdad(17)).toBe(false);
  });
  test('acepta el mínimo exacto', () => {
    expect(validarEdad(18)).toBe(true);
  });
  test('acepta el máximo exacto', () => {
    expect(validarEdad(65)).toBe(true);
  });
  test('rechaza el valor justo por encima del máximo', () => {
    expect(validarEdad(66)).toBe(false);
  });
});

El ejemplo usa la sintaxis de Jest, pero la idea no depende de la herramienta: cuatro casos elegidos con criterio cubren más riesgo que cien valores tomados al azar.

No te olvides de los casos negativos: qué pasa con un campo vacío, un archivo enorme, una sesión vencida, dos pestañas abiertas o la conexión cortada a mitad de una operación. Ahí aparece buena parte de los defectos que llegan a producción.

Cómo reportar un defecto

Un reporte mal escrito hace perder más tiempo que el defecto que describe. El criterio es que quien lo lea pueda reproducirlo sin preguntarte nada.

• Título específico: «El total del carrito no incluye el descuento al quitar un ítem», no «error en carrito».
• Pasos numerados desde un estado conocido, con los datos exactos que usaste.
• Resultado esperado y resultado real, escritos por separado.
• Evidencia: captura, video corto, registro de la consola o del servidor.
• Entorno: versión, navegador o dispositivo, usuario y fecha.
• Frecuencia: si pasa siempre o de manera intermitente. Un defecto intermitente sin esta aclaración se cierra como «no reproducible».

Sobre la severidad y la prioridad: no son lo mismo y conviene no mezclarlas. La severidad describe cuánto daña el fallo al sistema; la prioridad, con qué urgencia conviene arreglarlo. Un error de ortografía en la portada tiene severidad baja y puede tener prioridad alta.

Cuándo automatizar y cuándo no

Automatizar no es gratis. Cada prueba automatizada hay que escribirla, mantenerla cuando la interfaz cambia y diagnosticarla cuando falla sin motivo real. Una suite grande y frágil que el equipo aprende a ignorar es peor que no tener ninguna.

Un detalle que ahorra mucho dolor: una prueba automatizada que falla de manera intermitente sin que el producto haya cambiado —lo que se suele llamar prueba flaky— destruye la confianza en toda la suite. Es preferible desactivarla y arreglarla que convivir con fallos que el equipo empieza a ignorar por costumbre.

Qué significa «calidad» en concreto

Decir que un sistema «es de calidad» no significa nada hasta que se especifica en qué dimensión. La norma ISO/IEC 25010:2023 descompone la calidad de producto en nueve características, y sirve como lista de verificación para no probar siempre lo mismo:

• Adecuación funcional: hace lo que tiene que hacer, de forma completa y correcta.
• Eficiencia de desempeño: tiempos de respuesta y uso de recursos.
• Compatibilidad: convive con otros sistemas e intercambia información.
• Capacidad de interacción: se puede usar; incluye accesibilidad. En la edición anterior se llamaba usabilidad.
• Fiabilidad: se comporta de forma estable y se recupera de los fallos.
• Seguridad: protege la información y controla los accesos.
• Mantenibilidad: se puede modificar sin romper otras cosas.
• Flexibilidad: se adapta a otros contextos y escala. Antes se llamaba portabilidad.
• Seguridad física (safety): evita daños a personas, bienes o entorno. Se incorporó en la edición 2023.

La revisión de 2023 renombró usabilidad y portabilidad, y agregó safety como característica de primer nivel. Si venís de material más antiguo vas a ver ocho características en lugar de nueve: esa es la edición de 2011.

Ruta para empezar en QA

1. Fundamentos y vocabularioCiclo de desarrollo, criterios de aceptación, riesgo, severidad y prioridad. Tener las palabras precisas es lo que te permite discutir con el equipo.
2. Técnicas de diseñoParticiones de equivalencia, valores límite, tablas de decisión y escenarios negativos. Practicalas sobre cualquier aplicación que ya uses.
3. Reporte y comunicaciónEscribí diez defectos reales de aplicaciones que usás a diario y pedí que alguien intente reproducirlos con lo que escribiste.
4. Bases técnicasHTTP y códigos de estado, JSON, consultas SQL simples y las herramientas de desarrollo del navegador. Con esto pasás de probar pantallas a probar comportamiento.
5. APIsAprendé a enviar peticiones a mano y a leer respuestas. Muchos defectos se ven mejor en la API que en la interfaz.
6. Recién ahí, automatizaciónElegí una herramienta cuando ya entiendas bien qué estás verificando y por qué. La herramienta es lo fácil de cambiar.

Para practicar sin depender de un trabajo formal: buscá proyectos de código abierto que acepten reportes, participá en programas de prueba abiertos, o tomá una aplicación que uses todos los días y armá un plan de pruebas real para ella.

Errores frecuentes al empezar

• Probar solo el camino feliz. Es donde menos defectos hay, porque es lo que más se usó durante el desarrollo.
• Reportar sin evidencia. Genera ida y vuelta y hace que el defecto se cierre sin resolverse.
• Confundir «no entiendo cómo funciona» con «está mal». Confirmá el comportamiento esperado antes de reportar.
• Automatizar primero. Automatizar una verificación que no entendés multiplica el problema en vez de resolverlo.
• Tratar la cobertura como una meta. Un porcentaje alto de líneas ejecutadas no dice nada sobre si las verificaciones son buenas.
• Reportar varios problemas en un mismo ticket. Se corrige uno, se cierra el ticket y los otros desaparecen.

Preguntas frecuentes

Fuentes

Documentación oficial y estándares consultados para esta guía. Fecha de consulta: 27 de julio de 2026.

1. ISTQB. ISTQB Glossary. Definiciones normalizadas de error, defecto, fallo, caso de prueba y técnicas de diseño.
2. ISO. ISO/IEC/IEEE 29119-1:2022 — Software testing, Part 1: General concepts. Conceptos generales y enfoque de testing basado en riesgo.
3. ISO. ISO/IEC 25010:2023 — Product quality model. Las nueve características del modelo de calidad de producto.
4. Ham Vocke, en martinfowler.com. The Practical Test Pyramid. Origen y matices de la pirámide de pruebas.
5. W3C. Web Content Accessibility Guidelines (WCAG) 2.2. Criterios verificables para las pruebas de accesibilidad.
6. ISTQB. Certified Tester Foundation Level. Contenidos del programa de certificación inicial.