Los cinco niveles de prueba: qué busca cada uno y cuándo usarlo
Conocer los cinco niveles de prueba y el objetivo de cada uno te permite elegir la etapa adecuada para evaluar desde la lógica interna hasta los procesos de negocio.
En la práctica del desarrollo de software, es común observar que los equipos prueban en el nivel equivocado. Algunos concentran todo su esfuerzo en pruebas unitarias que no aislan el código y terminan dependiendo de bases de datos o servicios externos. Otros ignoran los pasos intermedios y sólo prueban la aplicación terminada de extremo a extremo.
Ambos caminos traen problemas. Cuando un defecto se detecta hasta el final, rastrear su causa resulta mucho más complejo y costoso. Como Glenford Myers explicó en The Art of Software Testing, dividir la evaluación en etapas permite atacar clases específicas de fallas y evita repeticiones innecesarias.
Un nivel de prueba es una etapa específica del proceso de pruebas que se organiza y gestiona de forma independiente. Cada nivel evalúa el software en una fase distinta de su construcción: desde partes aisladas de código hasta el producto completo interactuando con sus usuarios.
Estos niveles no representan una secuencia rígida en el tiempo. En ciclos de desarrollo modernos pueden traslaparse o ejecutarse de forma iterativa. Representan, más bien, un alcance de inspección que se amplía de manera gradual.
Para decidir qué nivel corresponde a cada necesidad, podemos revisar sus objetivos a partir de un ejemplo continuo: una aplicación móvil bancaria donde una persona solicita un préstamo personal. Este escenario toma como base el ejemplo de aplicación bancaria presentado en el programa de estudio de ISTQB.
1. Prueba de componente: aislar para verificar la lógica interna
La prueba de componente, también conocida como prueba unitaria, se concentra en evaluar partes individuales del software de forma completamente aislada. El objeto de prueba comprende módulos, clases, estructuras de datos o rutinas de cálculo.
Su propósito central es verificar que la lógica interna del código responda con exactitud al diseño detallado. Esta tarea suele estar en manos del mismo equipo de desarrollo que escribió el código, dentro de su propio entorno de trabajo.
Para que una prueba de componente funcione de verdad, el componente bajo prueba debe desconectarse de cualquier dependencia externa, como bases de datos o redes. Este aislamiento requiere herramientas de soporte:
Controlador (driver): una pieza auxiliar de software que invoca o manda llamar al componente que deseamos evaluar.
Stub: un objeto simulado que entrega respuestas predeterminadas en sustitución de los servicios o datos que el componente necesita para funcionar.
En el ejemplo del préstamo bancario, la prueba de componente evalúa la rutina financiera encargada de calcular el pago mensual. La prueba envía montos, tasas de interés y plazos para verificar que la operación matemática arroje la cifra exacta.
Para qué sirve este nivel: detecta errores de cálculo, fallas de flujo de datos y lógica incorrecta de forma inmediata.
Qué no puede ver: no puede comprobar si el módulo de cálculo sabe comunicarse con las pantallas de la aplicación o si tolera desconexiones de red.
2. Prueba de integración de componentes: revisar la comunicación entre piezas
Una vez que cada componente funciona por separado, la prueba de integración de componentes se concentra en verificar las interfaces y el traspaso de información entre dos o más módulos internos.
El foco aquí no es reevaluar la lógica interna de cada pieza, sino validar que los mensajes, formatos y parámetros que viajan entre ellas coincidan. Un error común ocurre cuando una rutina asume que recibe un dato en pesos y el módulo emisor lo entrega en centavos.
Existen dos estrategias principales para integrar componentes:
1. Integración incremental: une las piezas poco a poco, agregando un número reducido de componentes a la vez (siguiendo la jerarquía de arriba hacia abajo o de abajo hacia arriba).
2. Integración masiva (big bang): junta todos los módulos terminados en un solo paso e intenta probarlos en conjunto.
El programa del ISTQB y la experiencia técnica desaconsejan el enfoque de integración masiva: entre mayor es el alcance de lo que se conecta de golpe, más difícil resulta rastrear qué componente desató el fallo.
En la app del préstamo, este nivel revisa el momento en que la pantalla de captura le envía los datos que ingresó el solicitante a la lógica de negocio. Se valida que el plazo y el monto capturados lleguen íntegros y en el orden correcto a las rutinas de procesamiento.
Para qué sirve este nivel: expone inconsistencias en protocolos de comunicación, desajustes en el formato de datos y llamadas fuera de secuencia entre piezas internas.
Qué no puede ver: no evalúa la experiencia completa del usuario ni valida los procesos de negocio de punta a punta.
3. Prueba de sistema: evaluar el producto completo
La prueba de sistema examina el comportamiento global y las capacidades de la aplicación terminada frente a sus especificaciones originales. En este nivel, el objeto de prueba es el sistema integral.
A diferencia de los niveles anteriores, la prueba de sistema suele ser ejecutada por un equipo de pruebas independiente. La base de prueba incluye las especificaciones de requisitos, historias de usuario, diagramas de estado y manuales de operación.
El entorno donde se prueba debe parecerse lo más posible al entorno real de producción. Los defectos de especificación encontrados aquí son comunes; incorporar a especialistas de pruebas desde el refinamiento de requisitos mitiga esas discrepancias.
En la aplicación del banco, la prueba de sistema ejecuta el flujo completo de la solicitud de un préstamo personal. El evaluador abre la aplicación, llena el formulario, confirma los términos y concluye el trámite, verificando que la app ejecute todas las reglas del flujo de inicio a fin.
Para qué sirve este nivel: comprueba que las tareas funcionales de extremo a extremo operen de acuerdo con lo especificado en la documentación del sistema.
Qué no puede ver: este nivel suele utilizar simulaciones para los servicios externos; por ende, no garantiza la convivencia real con plataformas que pertenecen a terceros.
4. Prueba de integración de sistemas: validar las conexiones externas
La prueba de integración de sistemas se enfoca en las interfaces que comunican a nuestra aplicación con servicios externos, plataformas de terceros o sistemas legados dentro de la misma empresa.
En este nivel surgen retos particulares de gestión: la organización no controla el código ni los calendarios de actualización de esos servicios ajenos. Coordinar ambientes compartidos y resolver bloqueos causados por fallas externas exige acuerdos claros entre las organizaciones involucradas.
En el caso del préstamo, la app bancaria debe consultar el historial crediticio del solicitante a través de un servicio externo provisto por el buró de crédito. La prueba de integración de sistemas evalúa el envío de esa consulta, la recepción del reporte y el comportamiento de la app cuando la conexión con el buró de crédito es lenta o no responde.
En arquitecturas de microservicios, depender exclusivamente de pruebas de extremo a extremo para evaluar estas conexiones desata fricción. La guía técnica Code With Engineering Playbook de Microsoft señala que las pruebas de extremo a extremo son lentas y se rompen con facilidad.
Para qué sirve este nivel: detecta discrepancias en estructuras de mensajes entre organizaciones, fallas de comunicación en redes y violaciones a reglamentos de seguridad obligatorios.
Qué no puede ver: no sustituye la validación de la lógica interna de cada sistema ni reemplaza el criterio de negocio de los usuarios finales.
5. Prueba de aceptación: confirmar el valor de negocio
La prueba de aceptación busca determinar si el sistema está listo para desplegarse y si satisface las necesidades reales de negocio. Su objetivo primordial es la validación: comprobar que se construyó el producto correcto para los usuarios.
Este nivel está a cargo de usuarios finales, dueños de producto, personal operativo o clientes. Aunque pueden encontrarse defectos, encontrar un volumen significativo de fallas en esta fase representa un riesgo grave para el proyecto.
La prueba de aceptación adopta distintas formas según el contexto:
Prueba de aceptación de usuario (UAT): evalúa qué tan apto es el sistema para el trabajo diario de los usuarios en un entorno operativo representativo.
Prueba de aceptación operativa: ejecutada por administradores de sistemas; revisa copias de respaldo, restauración de datos, tareas de mantenimiento y migración.
Aceptación contractual y regulatoria: valida el cumplimiento de contratos legales específicos o regulaciones gubernamentales.
Pruebas alfa y beta: utilizadas en software comercial para recabar retroalimentación antes de salir al mercado masivo.
En el flujo del préstamo bancario, la prueba de aceptación evalúa la operación de la analista de crédito. Cuando una solicitud rebasa ciertos límites de riesgo, el sistema la canaliza a revisión manual. La analista revisa los expedientes turnados, comprueba la documentación y aprueba o rechaza el crédito desde su estación de trabajo.
Para qué sirve este nivel: genera confianza operativa y confirma si el software cumple con los procesos de negocio y las exigencias legales.
Qué no puede ver: no aisla fallas técnicas internas ni identifica qué línea de código ocasionó una discrepancia.
Comparativa general de los niveles
La siguiente tabla resume los cinco niveles aplicados al flujo funcional de la solicitud de crédito:
| Nivel de prueba | Objeto de prueba principal | Ejemplo en la solicitud de préstamo | Responsable habitual |
|---|---|---|---|
| Componente | Módulos aislados, clases, funciones matemáticas. | Cálculo matemático del pago mensual. | Quien desarrolla el código. |
| Integración de componentes | Interfaces y comunicación entre módulos internos. | Envío de los datos del formulario hacia la lógica de negocio. | Quien desarrolla el código. |
| Sistema | Aplicación completa y flujos de extremo a extremo. | Recorrido completo de la solicitud de préstamo dentro de la app. | Especialistas de prueba independientes. |
| Integración de sistemas | Conexiones con plataformas externas o servicios ajenos. | Consulta del historial de crédito con el servicio del buró de crédito. | Especialistas de prueba. |
| Aceptación | Procesos de negocio y preparación operativa. | Evaluación y dictamen de solicitudes turnadas a la analista de crédito. | Usuarios de negocio y analistas. |
Para articular estos niveles dentro de un proyecto sin duplicar esfuerzos ni omitir escenarios críticos, conviene organizar las actividades en un plan de pruebas de software estructurado.
Distribuir las evaluaciones en el nivel que les corresponde evita depender de pruebas de sistema frágiles y reduce el costo de resolver defectos. Cada nivel tiene un propósito concreto: aislar la lógica, asegurar la comunicación interna, comprobar el sistema completo, verificar los enlaces externos o validar la utilidad para el negocio. Conocer estas fronteras permite diseñar pruebas precisas y mantener la estabilidad del software en cada entrega.
Fuentes
- ISTQB (2024). Certified Tester Foundation Level Syllabus v4.0.1, secciones 2.2, 2.2.1, 2.2.2 y 2.2.3. https://istqb.org/certifications/certified-tester-foundation-level-ctfl-v4-0/
- ISTQB (2019). Certified Tester Foundation Level Syllabus, Version 2018 V3.1, secciones 2.2 y 2.3. https://atsqa.org/assets/documents/ISTQB-CTFL_Syllabus_2018_V3.1.pdf
- Microsoft (s. f.). Consumer-Driven Contract Testing (CDC). Code With Engineering Playbook. https://microsoft.github.io/code-with-engineering-playbook/automated-testing/cdc-testing/
- Myers, G. J., Sandler, C., & Badgett, T. (2011). The Art of Software Testing (3.ª ed.). John Wiley & Sons. https://www.oreilly.com/library/view/-/9781118133156
- Glosario ISTQB (Foundation Level). https://glossary.istqb.org/es_ES/home