Existen decenas de formas de comprobar que una aplicación funciona, y entender los tipos de pruebas de software es lo que separa un proceso de calidad ordenado de una revisión improvisada antes del lanzamiento. Cada tipo responde a una pregunta distinta, desde si una función calcula bien hasta si la gente entiende cómo usarla.
En esta guía verás cómo se clasifican las pruebas, en qué consiste cada una, qué diferencia hay entre tipo y técnica, y cómo decidir cuáles aplicar cuando el tiempo y el presupuesto no alcanzan para todas.
¿Qué son las pruebas de software y para qué sirven?
Las pruebas de software son el conjunto de actividades que evalúan una aplicación para comprobar que cumple sus requisitos, detectar defectos y reducir el riesgo de que algo falle ante el usuario. No buscan demostrar que el producto es perfecto, sino descubrir dónde y cómo puede fallar mientras corregirlo todavía es barato.
Se realizan durante todo el ciclo de desarrollo, no solo al final. Un fallo detectado al escribir el código cuesta una fracción de lo que cuesta uno que llega a producción, y por eso la mayoría de los equipos las integran en cada etapa, como describe el ciclo de vida del testing de software.
US$ 2,41 billones
Costo estimado de la mala calidad del software en Estados Unidos durante 2022, según el Consortium for Information & Software Quality (CISQ).
Fuente: CISQ, The Cost of Poor Software Quality in the US: A 2022 Report
La cifra es una estimación patrocinada por proveedores del sector, así que conviene leerla como orden de magnitud y no como dato exacto. Aun así, deja claro que probar bien no es un lujo del equipo técnico: es una decisión con consecuencias económicas directas.
Pensar en pruebas también obliga a distinguir tres ejes que suelen mezclarse: el nivel (qué parte del sistema se prueba), el tipo (qué característica se evalúa) y la técnica (cómo se ejecuta la prueba). Casi todas las confusiones sobre este tema vienen de tratar los tres como una sola lista.
Principios de las pruebas de software que guían la elección
Antes de elegir tipos de prueba conviene tener claros los principios que usan la mayoría de los programas de certificación, como el de ISTQB. Son siete y funcionan como reglas de sentido común para decidir dónde poner el esfuerzo.
- Las pruebas muestran que hay defectos, pero no pueden demostrar que no hay ninguno.
- Probar todas las combinaciones posibles es inviable, así que se prioriza según el riesgo.
- Probar pronto abarata la corrección.
- Los defectos se agrupan: unos pocos módulos concentran la mayoría de los errores, y vale la pena vigilarlos de cerca porque suelen repetirse versión tras versión.
- Las pruebas se desgastan: repetir siempre los mismos casos deja de encontrar errores nuevos (el antiguo “efecto pesticida”, que el temario ISTQB 2023 llama “las pruebas se desgastan”).
- La estrategia depende del contexto: no se prueba igual una app bancaria que un videojuego.
- Un software sin errores no sirve si no resuelve lo que el usuario necesita.
De estos principios sale una consecuencia práctica: no existe un plan de pruebas universal. Cada equipo combina tipos distintos según qué pierde si algo falla y en qué momento del desarrollo se encuentra.
El último principio es el más olvidado. Un producto puede pasar todas las pruebas técnicas y aun así fracasar porque nadie entiende cómo usarlo, y por eso la validación con personas reales forma parte de cualquier estrategia seria.
Tipos de pruebas de software según su objetivo
La clasificación más útil agrupa las pruebas por la pregunta que responden. A continuación se describen los grupos principales y los tipos que contiene cada uno.
Pruebas funcionales: ¿hace lo que debe?
Las pruebas funcionales verifican que cada función se comporte según los requisitos: interfaz, APIs, bases de datos y reglas de negocio. Se organizan en niveles que van de lo pequeño a lo grande.
- Pruebas unitarias: revisan componentes o funciones aisladas. Las escriben los desarrolladores mientras programan.
- Pruebas de integración: comprueban que los módulos funcionen bien juntos, ya sea de abajo hacia arriba, de arriba hacia abajo o de forma incremental. Aquí aparecen los errores de comunicación entre componentes que cada uno, por separado, pasaba sin problema.
- Pruebas de sistema: evalúan el producto completo frente a los requisitos.
- Pruebas de aceptación (UAT): los usuarios previstos validan el software en escenarios reales antes de darlo por bueno. Es la última barrera antes del lanzamiento y la que más se parece al uso verdadero.
Pruebas no funcionales: ¿qué tan bien lo hace?
Aquí se mide la calidad percibida más que la corrección: un sistema puede calcular bien y aun así ser lento, inseguro o incomprensible. Este grupo reúne varios tipos.
- Rendimiento: velocidad y estabilidad bajo carga, con variantes como pruebas de carga, de estrés y de resistencia.
- Seguridad: busca vulnerabilidades antes que lo haga un atacante.
- Compatibilidad: navegadores, sistemas operativos y dispositivos.
- Localización: idiomas, formatos de fecha y moneda, un punto crítico para productos que se lanzan en varios países.
- Accesibilidad: que personas con discapacidad puedan usar el producto, conforme a pautas reconocidas como las WCAG.
- Usabilidad: qué tan fácil resulta completar tareas reales.
La usabilidad es el tipo que ningún script puede evaluar. Requiere observar a personas reales, y por eso se resuelve con pruebas de usabilidad y no con herramientas de automatización. Muchos equipos la dejan para el final, justo cuando cambiar el diseño es más caro.
Pruebas de regresión, smoke y sanity
Este grupo responde a un momento del desarrollo más que a una característica del producto. Las pruebas de regresión se ejecutan tras cada cambio de código para confirmar que lo que antes funcionaba sigue funcionando. Son las que más se benefician de la automatización, porque se repiten una y otra vez.
Las pruebas smoke, también llamadas de verificación de la versión, son un filtro rápido y amplio: ¿arranca la aplicación, se puede iniciar sesión, cargan las pantallas principales? Si fallan, no tiene sentido seguir. Las pruebas sanity son más estrechas y se aplican tras una corrección menor para confirmar que el arreglo funciona.
Confundir smoke con sanity es habitual. La regla sencilla: smoke mira todo de forma superficial, sanity mira una parte de forma un poco más profunda.
Pruebas alfa y beta
Las pruebas alfa las realiza el equipo interno antes de mostrar el producto a nadie. Las beta llegan después, con usuarios externos reales en un entorno cercano a producción, y sirven para detectar problemas que el laboratorio no reproduce: configuraciones raras, hábitos de uso inesperados, redes lentas.
Una beta bien planteada incluye una forma sencilla de recoger opiniones, porque sin comentarios estructurados solo se aprende lo que los usuarios se molestan en reportar por su cuenta.
Comparativa de los tipos principales
| Tipo | Pregunta que responde | Quién suele hacerla | Mejor momento |
|---|---|---|---|
| Unitaria | ¿Funciona cada componente? | Desarrollo | Durante la programación |
| Integración | ¿Los módulos funcionan juntos? | Desarrollo y QA | Al unir componentes |
| Sistema | ¿El producto cumple los requisitos? | QA | Antes de la versión candidata |
| Aceptación | ¿Resuelve lo que el usuario necesita? | Usuarios o negocio | Antes del lanzamiento |
| Rendimiento | ¿Aguanta la carga esperada? | QA o ingeniería | Antes de picos de uso |
| Regresión | ¿Se rompió algo que funcionaba? | QA, automatizada | Tras cada cambio |
| Smoke | ¿Vale la pena seguir probando? | QA | Con cada versión nueva |
| Usabilidad | ¿Se entiende y se usa con facilidad? | Investigación UX y usuarios | Desde el prototipo |
Tipos de pruebas de software según el conocimiento del código
Otra clasificación frecuente depende de cuánto sabe el tester sobre el interior del producto. No cambia lo que se prueba, sino desde dónde se mira.
En las pruebas de caja blanca, también llamadas estructurales, quien prueba conoce el código y diseña casos para recorrer ramas, condiciones y rutas internas. Suelen hacerlas los desarrolladores y encajan especialmente con las pruebas unitarias.
En las pruebas de caja negra, el tester solo ve entradas y salidas, como lo haría un usuario: introduce datos y comprueba que el resultado coincida con lo esperado. Sirven para validar requisitos sin sesgo de implementación y son la base de la mayoría de las pruebas de sistema y aceptación.
Las pruebas de caja gris combinan ambas: el tester conoce parte de la arquitectura, por ejemplo el esquema de la base de datos, y la aprovecha para diseñar casos más certeros sin leer todo el código.
Técnicas y tipos de pruebas de software: ¿en qué se diferencian?
El tipo describe qué característica se evalúa; la técnica describe cómo se ejecuta la prueba. Una misma prueba de regresión, por ejemplo, puede hacerse de forma manual o con un script automatizado, y sigue siendo regresión en ambos casos.
Las tres técnicas más comunes son la manual, la automatizada y la exploratoria. En la manual, una persona sigue casos escritos y registra resultados. Es flexible y barata de arrancar, pero lenta y propensa a omisiones cuando se repite muchas veces.
La automatizada usa herramientas como Selenium, JUnit o TestNG para ejecutar casos sin intervención. Requiere inversión inicial y mantenimiento, pero se paga sola en pruebas repetitivas y es clave en entornos ágiles y de integración continua. Si quieres comparar opciones, revisa nuestra guía de herramientas de pruebas de software.
La exploratoria no sigue guiones: el tester investiga la aplicación con creatividad e intuición, aprendiendo a medida que prueba. Es la que descubre los fallos que nadie pensó en escribir como caso. Su variante más informal, la prueba ad hoc, se hace sin planificación ni documentación, y conviene reservarla como complemento, nunca como estrategia única.
¿Cómo elegir los tipos de pruebas de software para tu proyecto?
Como no se puede probar todo, la elección se reduce a priorizar. Un criterio útil es empezar por el riesgo: qué fallo sería más caro, más visible o más difícil de revertir. Esos flujos reciben las pruebas más profundas y frecuentes.
Después se ajusta por etapa. Una versión recién compilada pide smoke; una corrección puntual, sanity; una versión candidata, regresión completa y aceptación. Los tres criterios de abajo ayudan a tomar la decisión sin parálisis.
Tres preguntas para elegir qué probar
¿Qué puede fallar?
Lista los riesgos de negocio: pagos, datos personales, flujos de alta frecuencia.
¿En qué etapa estamos?
Una versión nueva pide smoke; un cambio menor, sanity; una versión candidata, regresión y aceptación.
¿Quién puede probarlo mejor?
Desarrolladores para el código, QA para el sistema y usuarios reales para la experiencia.
El primer criterio, los riesgos, evita gastar esfuerzo en lo irrelevante. Un equipo de comercio electrónico, por ejemplo, invertirá más en pruebas de pago y de carga en temporada alta que en la página de preguntas frecuentes.
El segundo, la etapa, evita desajustes típicos como lanzar pruebas de rendimiento sobre una versión que ni siquiera arranca. El tercero, quién prueba, reconoce los límites de cada perfil: los desarrolladores conocen el código pero rara vez ven el producto como un usuario nuevo.
Un buen plan documenta estas decisiones en un plan de pruebas y las revisa en cada ciclo. Si un tipo de prueba deja de encontrar defectos, es señal de que se desgastó y toca renovar los casos, como advierte el principio de las pruebas que se desgastan.
Ejemplos de tipos de pruebas de software por tipo de producto
El contexto cambia la mezcla. Estos ejemplos muestran cómo se combinan los tipos según el producto.
- En una aplicación bancaria móvil pesan la seguridad, la compatibilidad con dispositivos, la regresión constante y la usabilidad de flujos como transferir dinero o recuperar una contraseña.
- En una tienda en línea destacan las pruebas de rendimiento ante campañas, las de integración con pasarelas de pago y las de localización si vende en varios países.
- Un videojuego depende de pruebas exploratorias, de compatibilidad con hardware y de betas con jugadores reales.
- En un sistema interno de nómina, la prueba de aceptación con el área de recursos humanos es lo que más reduce el riesgo, junto con la regresión tras cada cambio de reglas fiscales, que además suelen cambiar cada año.
Observa que en ninguno aparecen todos los tipos con la misma intensidad. Esa asimetría es deliberada: refleja dónde está el riesgo de cada producto, y ahí es donde debe concentrarse el esfuerzo del equipo.
Para profundizar en una disciplina cercana, consulta qué es el QA testing y cómo se organiza dentro de un equipo, o cómo se plantean las pruebas de interfaz de usuario.
Conclusión
Conocer los tipos de pruebas de software permite hablar el mismo idioma con desarrollo, QA y negocio, y sobre todo decidir con criterio qué probar primero. Ningún tipo sustituye a los demás: las funcionales confirman que todo trabaja, las no funcionales que lo hace bien y la regresión que no se pierde lo ganado.
Falta una pieza que muchos equipos descuidan: ver cómo usan el producto las personas de verdad. Con QuestionPro UX puedes reclutar participantes, realizar entrevistas y pruebas moderadas o no moderadas, y analizar sus comentarios para detectar problemas de uso que ninguna prueba automatizada va a señalar.
Preguntas frecuentes sobre los tipos de pruebas de software
Los más importantes son las pruebas funcionales (unitarias, de integración, de sistema y de aceptación), las no funcionales (rendimiento, seguridad, usabilidad, compatibilidad) y las de regresión. Cuáles priorizar depende del riesgo del producto, no de una lista universal.
Las pruebas funcionales comprueban que cada función haga lo que dicen los requisitos, por ejemplo que un formulario guarde datos. Las no funcionales miden cómo se comporta el sistema: velocidad, seguridad, facilidad de uso o compatibilidad con distintos dispositivos.
Las pruebas smoke verifican de forma amplia y superficial que una versión nueva es lo bastante estable para seguir probándola. Las sanity son más estrechas: confirman que un cambio o corrección concreta funciona sin romper su entorno inmediato.
Ninguna es mejor en todo. La automatización rinde en pruebas repetitivas como la regresión; la manual y la exploratoria encuentran problemas de experiencia y casos imprevistos. Lo habitual es combinarlas según el costo y la frecuencia de cada prueba.
Los desarrolladores suelen encargarse de las pruebas unitarias y de integración. El equipo de QA cubre sistema, regresión y rendimiento. Las pruebas de aceptación y usabilidad se apoyan en usuarios reales o representantes del negocio.
