# Testing de software: guía para empezar en QA

**Categoría:** Testing y QA · **Nivel:** Inicial · **Lectura:** 12 min
**Publicada:** 2026-07-26 · **Actualizada:** 2026-07-27 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/testing/introduccion-al-testing/

Qué es el testing, qué tipos de pruebas existen, cómo diseñar casos que encuentren problemas reales, cuándo conviene automatizar y por dónde empezar si querés dedicarte a la calidad de software.

## Respuesta rápida

El testing de software es el proceso de evaluar un producto para obtener información sobre su calidad y sus riesgos. No consiste solo en «buscar errores»: sirve para que el equipo tome decisiones con evidencia. Probar todo es imposible, así que el trabajo real consiste en decidir **qué probar primero** según el impacto y la probabilidad de cada fallo, diseñar casos que cubran esos riesgos y comunicar los hallazgos de forma reproducible.

## ¿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.

> **Idea clave:** quien prueba no «rompe» el software. Hace visible un problema que ya estaba ahí y lo convierte en información accionable.

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.

| Aspecto | QA (aseguramiento de la calidad) | Testing |
|---|---|---|
| Objetivo | Prevenir defectos mejorando el proceso | Detectar defectos evaluando el producto |
| Alcance | Todo el ciclo de desarrollo | Una actividad dentro de ese ciclo |
| Momento | Antes, durante y después de construir | Cuando hay algo evaluable, incluido un requisito escrito |
| Ejemplo típico | Definir criterios de aceptación claros con el equipo | Verificar que el sistema cumple esos criterios |

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.

### 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.

![Pirámide de tres niveles: en la base, muchas pruebas unitarias rápidas y baratas; en el medio, pruebas de integración; en la cima, pocas pruebas de extremo a extremo, lentas y costosas de mantener.](../../assets/img/guias/introduccion-al-testing-piramide.svg)

*La pirámide de pruebas resume una heurística de equilibrio: cuanto más arriba, más caro cuesta cada prueba y más frágil se vuelve.*

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.

### 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.

```javascript
// 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.

Todo caso de prueba necesita tres partes:

1. **Preparar el contexto.** Usuario, ambiente, permisos, datos y estado inicial. Si esto no está escrito, nadie va a poder reproducirlo.
2. **Ejecutar pasos observables.** Acciones breves y sin ambigüedad. «Verificar que funcione» no es un paso.
3. **Verificar un resultado concreto.** Qué debe ocurrir exactamente y qué evidencia se guarda si no ocurre.

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.

![Diagrama de flujo con cinco estados: nuevo, triado, en corrección, a verificar y cerrado. Desde «a verificar» una flecha de reapertura vuelve a «en corrección» si la verificación falla. Desde «triado» un defecto puede descartarse por duplicado, fuera de alcance o no reproducible.](../../assets/img/guias/introduccion-al-testing-ciclo-defecto.svg)

*Los nombres de los estados cambian según la herramienta, pero el principio se mantiene: nadie cierra su propio defecto sin verificación independiente.*

- **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.

> **Regla práctica:** automatizá lo que sea **repetitivo, estable, crítico y frecuente**. Si falla alguna de esas cuatro condiciones, revisá si conviene.

| Conviene automatizar | Conviene dejar manual |
|---|---|
| Pruebas de regresión que se repiten en cada entrega | Funcionalidad que todavía está cambiando de forma |
| Cálculos, validaciones y reglas de negocio | Usabilidad, redacción y percepción visual |
| Verificaciones de API y de datos | Exploración para descubrir lo inesperado |
| Escenarios difíciles de reproducir a mano | Pruebas que se van a ejecutar una o dos veces |

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 vocabulario.** Ciclo 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ño.** Particiones de equivalencia, valores límite, tablas de decisión y escenarios negativos. Practicalas sobre cualquier aplicación que ya uses.
3. **Reporte y comunicación.** Escribí diez defectos reales de aplicaciones que usás a diario y pedí que alguien intente reproducirlos con lo que escribiste.
4. **Bases técnicas.** HTTP 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. **APIs.** Aprendé 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ón.** Elegí 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

**¿Necesito saber programar para empezar en testing?**
No para empezar. El testing manual, el diseño de casos, el análisis de requisitos y el reporte de defectos no requieren programar. La programación se vuelve necesaria cuando querés automatizar, revisar código o trabajar con pruebas de integración y de API.

**¿QA y testing son lo mismo?**
No. El aseguramiento de la calidad (QA) es un enfoque amplio sobre procesos y prevención de defectos en todo el ciclo de desarrollo. El testing es una actividad concreta dentro de ese enfoque: evaluar un producto para obtener información sobre su calidad. Todo testing forma parte de QA, pero QA incluye mucho más que testing.

**¿Cuántas pruebas son suficientes?**
No existe un número correcto: probar todas las combinaciones posibles es inviable en cualquier sistema real. Por eso ISO/IEC/IEEE 29119-1:2022 propone el enfoque basado en riesgo: se prueba más donde el impacto de un fallo y la probabilidad de que ocurra son mayores. La cobertura se decide, se documenta y se revisa.

**¿Conviene automatizar todas las pruebas?**
No. Una prueba automatizada tiene costo de creación y, sobre todo, de mantenimiento. Conviene automatizar lo repetitivo, estable y crítico que se ejecuta con frecuencia. Las pruebas exploratorias, las de usabilidad y las verificaciones que cambian en cada iteración suelen rendir más ejecutadas por una persona.

**¿Qué diferencia hay entre error, defecto y fallo?**
Una persona comete un error, ese error introduce un defecto en el código o en la documentación, y el defecto produce un fallo cuando alguien ejecuta la parte afectada. La distinción importa al reportar: describís el fallo observado y aportás la evidencia para que el equipo localice el defecto.

**¿Qué certificación conviene al empezar?**
La más difundida para iniciarse es ISTQB Certified Tester Foundation Level, porque unifica vocabulario y conceptos básicos. No es obligatoria ni reemplaza la práctica: sirve más para ordenar lo que ya venís aprendiendo que como primer contacto con el testing.

## Fuentes

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

1. **ISTQB.** [ISTQB Glossary](https://glossary.istqb.org/). 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](https://www.iso.org/standard/81291.html). Conceptos generales y enfoque de testing basado en riesgo.
3. **ISO.** [ISO/IEC 25010:2023 — Product quality model](https://www.iso.org/standard/78176.html). Las nueve características del modelo de calidad de producto.
4. **Ham Vocke, en martinfowler.com.** [The Practical Test Pyramid](https://martinfowler.com/articles/practical-test-pyramid.html). Origen y matices de la pirámide de pruebas.
5. **W3C.** [Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/). Criterios verificables para las pruebas de accesibilidad.
6. **ISTQB.** [Certified Tester Foundation Level](https://www.istqb.org/certifications/certified-tester-foundation-level). Contenidos del programa de certificación inicial.

## Guías relacionadas

- [Hacking ético: fundamentos, metodología y laboratorio seguro](../../hacking/fundamentos-hacking-etico/index.md) — las pruebas de seguridad son pruebas no funcionales.
- [Cómo aprender programación desde cero: ruta práctica](../../programacion/aprender-programacion-desde-cero/index.md) — el camino previo a la automatización.
- [Índice de guías de Underc0de](../../index.md)

---

Esta guía forma parte de un proyecto de la comunidad Underc0de para organizar conocimiento técnico en español. Fuente canónica: https://underc0de.org/guias/testing/introduccion-al-testing/