Un sistema de software puede probarse en distintos niveles. No es lo mismo comprobar una función aislada que revisar un flujo completo de negocio. Cada nivel de prueba observa el producto desde una perspectiva diferente.
Los niveles más habituales son: pruebas unitarias, pruebas de integración, pruebas de sistema y pruebas de aceptación. En este tema veremos qué significa cada uno, qué tipo de defectos ayuda a encontrar y cómo se relacionan entre sí.
Conocer estos niveles permite organizar mejor el esfuerzo de testing y evitar una confusión frecuente: intentar encontrar todos los problemas con un solo tipo de prueba.
Un nivel de prueba es una etapa o perspectiva desde la cual evaluamos el software. Cada nivel tiene un alcance distinto:
La idea no es elegir un único nivel, sino combinarlos. Los defectos simples deberían detectarse temprano y cerca de su origen. Los defectos de flujo completo se detectan mejor cuando el sistema se prueba como un todo.
Las pruebas unitarias verifican unidades pequeñas de código de forma aislada. Una unidad puede ser una función, un método, una clase o un componente pequeño, según el lenguaje y la arquitectura.
Su objetivo es comprobar que una pieza específica se comporta correctamente ante entradas conocidas.
Ejemplos:
Estas pruebas suelen ser escritas por desarrolladores y se ejecutan con mucha frecuencia porque son rápidas y ayudan a detectar errores cerca del código que los produce.
Las pruebas unitarias tienen varias ventajas:
Pero también tienen límites:
Una aplicación puede tener muchas pruebas unitarias correctas y aun así fallar cuando sus partes trabajan juntas.
Las pruebas de integración verifican que dos o más componentes funcionen correctamente cuando interactúan. Su foco no está en una unidad aislada, sino en la comunicación entre partes.
Ejemplos de integración:
Estas pruebas ayudan a encontrar defectos que no aparecen cuando cada componente se prueba por separado.
Muchos problemas aparecen en los puntos donde los sistemas se conectan. Algunos defectos típicos son:
Por ejemplo, una prueba unitaria puede confirmar que el sistema calcula bien el total de una compra, pero una prueba de integración puede descubrir que el módulo de pagos recibe el importe con un formato incorrecto.
Las pruebas de sistema evalúan el sistema completo ya integrado. El objetivo es comprobar que el producto funciona como un conjunto y cumple los requisitos definidos.
En este nivel se prueban flujos completos y comportamientos visibles para el usuario o para otros sistemas. Por ejemplo:
Las pruebas de sistema suelen incluir pruebas funcionales y también pueden incluir pruebas no funcionales, como rendimiento, seguridad, compatibilidad o usabilidad.
En pruebas de sistema se revisa el comportamiento general. Esto puede incluir:
Este nivel se acerca más a la experiencia real de uso, pero suele ser más costoso y lento que las pruebas unitarias o de integración.
Las pruebas de aceptación buscan confirmar que el sistema satisface las necesidades del usuario, del cliente o del negocio. Están relacionadas con la validación: no solo importa que el sistema funcione, sino que sea aceptable para su propósito.
Estas pruebas pueden ser realizadas por usuarios, representantes del negocio, clientes, product owners o testers con criterios definidos por el negocio.
Ejemplos:
Una prueba de aceptación puede detectar que el sistema cumple técnicamente, pero no resulta útil o claro para el usuario real.
| Nivel | Qué prueba | Quién suele participar | Ejemplo |
|---|---|---|---|
| Unitario | Una parte pequeña del código. | Desarrolladores. | Una función que calcula descuentos. |
| Integración | Comunicación entre componentes. | Desarrolladores y testers técnicos. | Backend que guarda una compra en base de datos. |
| Sistema | El producto completo integrado. | Testers, desarrolladores y equipo de QA. | Flujo completo de compra. |
| Aceptación | Necesidad del usuario o negocio. | Usuarios, cliente, negocio, product owner y QA. | Validar que el reporte sirve para la operación mensual. |
Supongamos que estamos probando una tienda en línea. La funcionalidad permite comprar un producto con descuento.
| Nivel | Prueba posible |
|---|---|
| Unitaria | Verificar que la función de descuento calcule $900 para una compra de $1000 con 10% de descuento. |
| Integración | Comprobar que el carrito envíe el total correcto al módulo de pagos. |
| Sistema | Realizar el flujo completo: buscar producto, agregar al carrito, aplicar descuento, pagar y recibir confirmación. |
| Aceptación | Confirmar con negocio que la promoción se aplica según las reglas comerciales acordadas. |
El mismo requisito puede evaluarse en distintos niveles. Cada nivel aporta información diferente.
La pirámide de pruebas es una idea usada para explicar el equilibrio entre niveles. En general, recomienda tener muchas pruebas rápidas de bajo nivel, una cantidad moderada de pruebas de integración y menos pruebas completas de extremo a extremo o sistema, porque suelen ser más lentas y costosas.
Una forma simple de entenderla:
La pirámide no es una regla rígida. Es una guía para evitar depender únicamente de pruebas lentas y frágiles. El equilibrio real depende del contexto.
Como regla general, conviene encontrar un defecto en el nivel más bajo posible. Si una función calcula mal un impuesto, es mejor descubrirlo con una prueba unitaria que recién durante una prueba completa de facturación.
Encontrar defectos en niveles bajos suele tener ventajas:
Sin embargo, algunos defectos solo aparecen al integrar partes o ejecutar flujos completos. Por eso todos los niveles siguen siendo necesarios.
Depender de un solo nivel de prueba puede dejar huecos importantes:
Una estrategia sólida combina niveles para equilibrar rapidez, profundidad, cobertura y confianza.
Cada nivel puede requerir ambientes diferentes. Una prueba unitaria puede ejecutarse en la máquina del desarrollador. Una prueba de integración puede necesitar una base de datos o un servicio de prueba. Una prueba de sistema puede requerir una versión desplegada en un ambiente similar a producción.
Ejemplos de ambientes:
Cuanto más alto es el nivel de prueba, más importante suele ser que el ambiente represente correctamente el uso real.
Al trabajar con niveles de prueba, algunos errores frecuentes son:
Estos errores pueden generar pruebas lentas, repetidas o incapaces de detectar los defectos más importantes a tiempo.
Para organizar bien los niveles de prueba conviene:
Una buena estrategia no mide calidad solo por cantidad de pruebas, sino por el valor que aporta cada nivel.
Los niveles de prueba organizan el testing de manera más efectiva. Cada nivel responde preguntas distintas: si una unidad funciona, si las partes se comunican, si el sistema completo cumple los requisitos y si el producto satisface al usuario o al negocio.
No existe un único nivel suficiente para todo. Las pruebas unitarias aportan rapidez, las de integración detectan problemas de comunicación, las de sistema revisan flujos completos y las de aceptación validan valor real.
En el próximo tema estudiaremos los tipos de prueba: funcionales y no funcionales, para comprender qué aspectos del producto podemos evaluar más allá del nivel donde se ejecuten.