- Las pruebas de software son un conjunto de actividades para descubrir defectos y evaluar la calidad de un software antes (y después) de que llegue a los usuarios.
- ISTQB separa dos ideas que suelen confundirse: los niveles de prueba (en qué etapa y sobre qué pieza se prueba) y los tipos de prueba (qué característica de calidad se evalúa).
- 5 niveles según CTFL 4.0: componente (unitaria), integración de componentes, sistema, integración de sistemas y aceptación.
- 4 tipos según CTFL 4.0: funcional, no funcional, caja negra y caja blanca. A ellos se suman la prueba de confirmación y la de regresión, que se hacen después de un cambio.
- La prueba también puede ser estática (sin ejecutar el software: revisiones y análisis estático) o dinámica (ejecutándolo).
- Cualquier tipo de prueba puede aplicarse en cualquier nivel; lo que cambia es el enfoque. Elige la combinación según el riesgo de tu producto.
Si buscas "tipos de pruebas de software" encontrarás listas con 20, 50 o 100 tipos distintos mezclados sin orden: unitarias, de humo, de caja negra, de estrés, alfa, de regresión... Todas existen, pero no están en la misma categoría, y por eso confunden.
En esta guía ordenamos todo con el marco que usa la industria: el programa de estudio ISTQB Certified Tester Foundation Level (CTFL) 4.0. Al final tendrás una tabla comparativa y sabrás exactamente dónde encaja cada término que escuches en tu equipo o en una entrevista. Si apenas estás empezando en esta carrera, te conviene leer también qué es un QA tester y cómo convertirte en uno.
¿Qué son las pruebas de software?
Según el syllabus CTFL 4.0, la prueba de software es un conjunto de actividades para descubrir defectos y evaluar la calidad de los artefactos de software. Cuando probamos algo, a ese algo se le llama objeto de prueba: puede ser código, pero también un requisito, una historia de usuario o un diseño.
Dos ideas erróneas muy comunes que el propio syllabus aclara:
- "Probar es solo ejecutar el software". Falso: también incluye planificar, analizar, diseñar, revisar documentos e informar.
- "Probar es solo verificar requisitos". Falso: también es validar, es decir, comprobar que el sistema satisface las necesidades reales de los usuarios.
Objetivos de las pruebas de software
Los objetivos típicos que enumera ISTQB son: evaluar productos de trabajo (requisitos, historias, diseños, código), provocar fallos y encontrar defectos, asegurar la cobertura necesaria, reducir el riesgo de una calidad inadecuada, verificar requisitos especificados y contractuales o legales, dar información a los implicados para tomar decisiones, generar confianza y validar que el sistema funciona como esperan los usuarios.
Los 7 principios de la prueba
| Principio | Qué significa en la práctica |
|---|---|
| 1. La prueba muestra la presencia de defectos, no su ausencia | Que no encuentres bugs no prueba que no existan. |
| 2. La prueba exhaustiva es imposible | Usa técnicas, priorización y riesgo para enfocar el esfuerzo. |
| 3. La prueba temprana ahorra tiempo y dinero | Un defecto en un requisito cuesta menos si se detecta antes de programar. |
| 4. Los defectos se agrupan | Pocos módulos concentran la mayoría de los defectos (principio de Pareto). |
| 5. Las pruebas se desgastan | Repetir siempre las mismas pruebas deja de encontrar defectos nuevos. |
| 6. La prueba depende del contexto | No se prueba igual una app de videojuegos que un sistema médico. |
| 7. Falacia de la ausencia de defectos | Un sistema sin bugs puede fracasar si no resuelve lo que el usuario necesita. |
Niveles de prueba vs tipos de prueba: la diferencia clave
Esta es la distinción que más ordena el tema:
- Nivel de prueba: grupo de actividades de prueba que se organizan y gestionan juntas, en una etapa concreta del desarrollo, desde componentes individuales hasta sistemas completos. Responde a ¿qué pieza estoy probando y en qué momento?
- Tipo de prueba: grupo de actividades de prueba relacionadas con características de calidad específicas. Responde a ¿qué aspecto de la calidad estoy evaluando?
Por eso no tiene sentido preguntar "¿es mejor la prueba de sistema o la no funcional?". Puedes hacer una prueba no funcional (por ejemplo, de rendimiento) en el nivel de sistema, o una prueba funcional en el nivel de componente. Los cuatro tipos pueden aplicarse en todos los niveles; lo que cambia es el enfoque.
Los 5 niveles de prueba según ISTQB
Para que los ejemplos sean concretos, imagina que tu equipo construye una app de banca móvil con un módulo de transferencias.
| Nivel | En qué se enfoca | Quién lo hace normalmente | Ejemplo en la app bancaria |
|---|---|---|---|
| Prueba de componente (unitaria) | Componentes aislados. Requiere arneses o frameworks de prueba unitaria. | Desarrolladores, en su entorno | La función que calcula la comisión devuelve $0 para montos menores a $500. |
| Integración de componentes | Interfaces e interacciones entre componentes (estrategias ascendente, descendente o big-bang). | Desarrolladores | El servicio de transferencias llama correctamente al servicio de saldos. |
| Prueba de sistema | Comportamiento y capacidades del sistema completo: flujos de extremo a extremo y características no funcionales. | Equipo de prueba (a menudo independiente) | Un cliente inicia sesión, da de alta un beneficiario y transfiere $1,500 de punta a punta. |
| Integración de sistemas | Interfaces con otros sistemas y servicios externos. Requiere entornos parecidos a producción. | Equipo de prueba | La app se comunica bien con el sistema de pagos interbancario y con el proveedor de SMS. |
| Prueba de aceptación | Validación y preparación para el despliegue: ¿satisface las necesidades del negocio? | Idealmente, usuarios o representantes del negocio | Usuarios reales confirman que pueden transferir sin ayuda y que los comprobantes cumplen la normativa. |
Las formas principales de prueba de aceptación que menciona ISTQB son: prueba de aceptación de usuario (UAT), aceptación operativa, aceptación contractual y de regulación, prueba alfa y prueba beta. Si te interesa especializarte en esta etapa, existe la certificación ISTQB Acceptance Testing.
Para que dos niveles no se pisen, ISTQB recomienda distinguirlos por cinco atributos: objeto de prueba, objetivos de prueba, base de prueba, defectos y fallos típicos, y enfoque y responsabilidades.
Los 4 tipos de prueba según ISTQB
1. Prueba funcional
Evalúa las funciones que debe realizar el sistema: "qué" hace. Su objetivo es comprobar la completitud, la corrección y la pertinencia funcional.
Ejemplo: al transferir $1,500, el saldo de origen disminuye exactamente $1,500 más la comisión y el destinatario recibe $1,500.
2. Prueba no funcional
Evalúa "lo bien que se comporta" el sistema. ISTQB toma la clasificación de características de calidad de la norma ISO/IEC 25010:
| Característica | Qué evalúa | Ejemplo |
|---|---|---|
| Eficiencia de desempeño | Tiempos de respuesta, uso de recursos, capacidad | La transferencia responde en menos de 3 segundos con 500 usuarios simultáneos. |
| Compatibilidad | Convivencia e interoperabilidad con otros sistemas | Funciona junto a otras apps sin conflictos e intercambia datos con el core bancario. |
| Usabilidad | Facilidad de uso, aprendizaje, accesibilidad | Un usuario nuevo completa su primera transferencia sin ayuda. |
| Fiabilidad | Disponibilidad, tolerancia a fallos, recuperación | Si se cae la red a mitad de la operación, no se duplica el cargo. |
| Seguridad | Confidencialidad, integridad, autenticación | No es posible ver los movimientos de otro cliente cambiando un ID en la URL. |
| Mantenibilidad | Facilidad para modificar y probar | El código cumple los estándares y el análisis estático no reporta complejidad excesiva. |
| Portabilidad | Adaptabilidad e instalación en otros entornos | La app funciona igual en Android 13 y 14 y en iOS 17. |
Un dato importante del syllabus: el descubrimiento tardío de defectos no funcionales puede ser una amenaza grave para el proyecto, por eso conviene empezar estas pruebas pronto. Para rendimiento, por ejemplo, puedes revisar la certificación ISTQB Performance Testing o el curso de pruebas de rendimiento con JMeter; para seguridad, ISTQB Security Tester; para usabilidad, ISTQB Usability Testing.
3. Prueba de caja negra
Se basa en la especificación: deriva las pruebas de documentación externa al objeto de prueba, sin mirar el código. Su objetivo es comprobar el comportamiento del sistema frente a lo especificado. Técnicas típicas: partición de equivalencia, análisis de valores frontera, tablas de decisión y transición de estados.
Ejemplo: la especificación dice que el monto mínimo es $10 y el máximo $50,000; pruebas con $9, $10, $50,000 y $50,001 sin saber cómo está programado.
4. Prueba de caja blanca
Se basa en la estructura: deriva las pruebas de la implementación interna (código, arquitectura, flujos de trabajo, flujos de datos). Su objetivo es que las pruebas cubran esa estructura hasta un nivel aceptable. En CTFL 4.0 se estudian la cobertura de sentencias y la de ramas.
Ejemplo: el código tiene un if que aplica comisión solo a transferencias interbancarias; diseñas pruebas para que se ejecuten la rama verdadera y la falsa.
Ojo: si el software no implementa un requisito, la caja blanca no lo detectará (no puedes cubrir código que no existe). Por eso caja negra y caja blanca se complementan.
Todas estas técnicas, con ejercicios resueltos, las explicamos en la guía de casos de prueba: cómo escribirlos, ejemplos y plantilla.
Prueba de confirmación y prueba de regresión
Cada vez que el software cambia (se corrige un defecto o se agrega una función) entran en juego dos pruebas más:
- Prueba de confirmación: confirma que el defecto original se corrigió. Normalmente vuelves a ejecutar las pruebas que fallaron.
- Prueba de regresión: confirma que el cambio no provocó consecuencias adversas en el mismo componente, en otros componentes o incluso en otros sistemas conectados. Se recomienda hacer antes un análisis de impacto para decidir su alcance.
Ejemplo: se corrige el cálculo de comisiones. La prueba de confirmación verifica que la comisión ahora es correcta. La regresión verifica que el estado de cuenta, los comprobantes y los límites diarios siguen funcionando.
Como los juegos de regresión se ejecutan muchas veces y crecen en cada entrega, ISTQB los señala como firmes candidatos a la automatización, idealmente desde las primeras fases del proyecto. Si quieres empezar, lee automatización de pruebas desde cero y compara herramientas en Playwright vs Selenium vs Cypress.
Prueba de mantenimiento
Es la que se hace sobre sistemas que ya están en producción cuando se modifican (mejoras, correcciones, correcciones en caliente), cuando se migran a otra plataforma o cuando se retiran (por ejemplo, probar el archivado de datos). Su alcance depende del riesgo del cambio, del tamaño del sistema y de la magnitud del cambio.
Pruebas estáticas vs pruebas dinámicas
Otra forma de clasificar la prueba es si se ejecuta o no el software:
| Aspecto | Prueba estática | Prueba dinámica |
|---|---|---|
| ¿Ejecuta el software? | No | Sí |
| Cómo se hace | Revisiones manuales (informal, guiada, técnica, inspección) y análisis estático con herramientas | Ejecutando casos de prueba, manuales o automatizados |
| Qué encuentra | Defectos directamente | Fallos, cuyos defectos se identifican después mediante análisis |
| Sobre qué se aplica | También a productos no ejecutables: requisitos, historias, diseños, planes y casos de prueba | Solo a productos ejecutables |
| Defectos típicos | Requisitos ambiguos o contradictorios, código inalcanzable, variables no declaradas, desviaciones de estándares, ciertas vulnerabilidades | Cálculos erróneos, flujos que fallan, problemas de rendimiento |
| Cuándo | Desde el inicio del ciclo de vida | Cuando ya existe algo que ejecutar |
Son complementarias. La prueba estática es la forma más directa de aplicar el principio de prueba temprana (lo que también se llama shift left o desplazamiento a la izquierda).
Tabla comparativa: tipos de pruebas de software
Esta tabla resume todo lo anterior en una sola vista. Guárdala para tu próxima entrevista:
| Prueba | Categoría ISTQB | Pregunta que responde | Ejemplo rápido |
|---|---|---|---|
| Componente / unitaria | Nivel | ¿Esta pieza aislada funciona? | Función de cálculo de comisión |
| Integración de componentes | Nivel | ¿Las piezas se comunican bien? | Servicio de transferencias + saldos |
| Sistema | Nivel | ¿El sistema completo cumple? | Transferencia de punta a punta |
| Integración de sistemas | Nivel | ¿Se integra con sistemas externos? | App + sistema interbancario |
| Aceptación (UAT, alfa, beta) | Nivel | ¿Sirve al negocio y está listo para desplegar? | Usuarios reales validan |
| Funcional | Tipo | ¿Qué hace? ¿Lo hace correctamente? | El saldo se descuenta bien |
| No funcional | Tipo | ¿Qué tan bien lo hace? | Responde en menos de 3 s |
| Caja negra | Tipo | ¿Cumple la especificación? | Montos mínimo y máximo |
| Caja blanca | Tipo | ¿Cubrimos la estructura interna? | Ambas ramas de un if
|
| Confirmación | Relacionada con cambios | ¿Se corrigió el defecto? | Repetir el caso fallido |
| Regresión | Relacionada con cambios | ¿El cambio rompió otra cosa? | Suite automatizada en CI |
| Mantenimiento | Sistemas en producción | ¿El cambio en producción es seguro? | Migración a la nube |
| Estática | Forma de probar | ¿Hay defectos sin ejecutar? | Revisión de una historia de usuario |
| Dinámica | Forma de probar | ¿Falla al ejecutarse? | Ejecutar casos de prueba |
Otros nombres que vas a escuchar (y dónde encajan)
- Pruebas de humo (smoke test): un conjunto mínimo de pruebas para saber si una versión es lo bastante estable para seguir probando. ISTQB las menciona como criterio de entrada típico ("todas las pruebas de humo han pasado").
- Pruebas end-to-end (E2E): flujos completos del usuario; normalmente se ubican en el nivel de sistema o de integración de sistemas.
- Pruebas de API: pueden ser de integración de componentes o de sistema; son funcionales o no funcionales según lo que evalúen. Practícalas en el curso de pruebas de API con Postman.
- Pruebas de carga, estrés, rendimiento: variantes de prueba no funcional de eficiencia de desempeño.
- Prueba exploratoria: no es un tipo ni un nivel, es una técnica basada en la experiencia en la que diseñas, ejecutas y evalúas al mismo tiempo.
- TDD, ATDD y BDD: enfoques en los que las pruebas guían el desarrollo; se escriben antes del código.
Pirámide y cuadrantes de prueba
Dos modelos que ISTQB incluye para decidir cuánto de cada prueba hacer:
- Pirámide de prueba: muchas pruebas pequeñas, aisladas y rápidas en la base (unitarias), menos pruebas de integración o servicio en medio, y pocas pruebas de extremo a extremo en la cima, que son más lentas y costosas.
- Cuadrantes de prueba (Brian Marick): clasifican las pruebas según estén orientadas al negocio o a la tecnología, y según apoyen al equipo o critiquen al producto. Q1: componente e integración (automatizadas). Q2: funcionales, ejemplos, historias de usuario, API. Q3: exploratoria, usabilidad, aceptación de usuario (manuales). Q4: humo y no funcionales (automatizadas).
¿Cómo elegir qué tipos de prueba aplicar?
Recuerda el principio 6: la prueba depende del contexto. Para decidir, pregúntate:
- ¿Cuál es el riesgo? Si un error en el cálculo de intereses cuesta dinero, ese módulo merece técnicas más rigurosas y más cobertura.
- ¿Qué características de calidad importan más? En una app bancaria, seguridad y fiabilidad; en un videojuego, rendimiento y usabilidad.
- ¿Qué ciclo de vida sigue el equipo? En ágil y DevOps, regresión automatizada y retroalimentación rápida; en secuencial, más documentación y revisiones tempranas.
- ¿Qué exige el negocio o la regulación? Algunos sectores piden pruebas de aceptación contractuales o de cumplimiento.
Todo esto se documenta en el plan de pruebas, que puedes descargar como plantilla en nuestra guía.
Preguntas frecuentes
¿Qué son las pruebas de software?
Son un conjunto de actividades para descubrir defectos y evaluar la calidad de un software y de sus artefactos (requisitos, diseños, código). Incluyen planificar, analizar, diseñar, ejecutar pruebas y reportar resultados, no solo ejecutar el programa.
¿Cuáles son los tipos de pruebas de software según ISTQB?
El programa CTFL 4.0 define cuatro tipos de prueba: funcional, no funcional, caja negra y caja blanca. Además describe la prueba de confirmación y la de regresión, que se realizan después de un cambio.
¿Cuál es la diferencia entre niveles y tipos de prueba?
Los niveles indican en qué etapa y sobre qué parte del software se prueba (componente, integración de componentes, sistema, integración de sistemas y aceptación). Los tipos indican qué característica de calidad se evalúa (funcional, no funcional, caja negra, caja blanca). Cualquier tipo puede aplicarse en cualquier nivel.
¿Qué diferencia hay entre prueba funcional y no funcional?
La funcional evalúa qué hace el sistema y si lo hace correctamente. La no funcional evalúa qué tan bien lo hace: rendimiento, usabilidad, seguridad, fiabilidad, compatibilidad, mantenibilidad y portabilidad, según la norma ISO/IEC 25010.
¿Qué es una prueba de regresión?
Es la prueba que confirma que un cambio, incluida la corrección de un defecto, no causó efectos adversos en otras partes del sistema. Como se repite en cada entrega, es una de las mejores candidatas a automatizar.
¿Qué diferencia hay entre prueba estática y dinámica?
La estática evalúa productos de trabajo sin ejecutar el software, mediante revisiones o análisis estático, y encuentra defectos directamente. La dinámica ejecuta el software y provoca fallos, cuyos defectos se identifican después. Son complementarias.
¿La prueba unitaria es lo mismo que la prueba de componente?
Sí. ISTQB llama prueba de componente a lo que comúnmente se conoce como prueba unitaria: probar componentes de forma aislada, normalmente a cargo de los desarrolladores.