¿Cuáles son los tipos de pruebas de software más importantes?

Imagina que trabajas en el equipo de tecnología de Liverpool. Tu equipo lanza una actualización al carrito de compras. Al día siguiente, cientos de clientes no pueden terminar su pedido. Las ventas caen y el equipo entra en modo de emergencia.

Ese escenario ocurre cuando no se aplican los tipos de prueba correctos en el momento correcto. Conocer cada tipo de prueba te da el mapa para evitar esas crisis.

El mapa del testing: cuatro tipos esenciales

Existen docenas de tipos de pruebas en la industria. Pero hay cuatro que todo QA profesional debe dominar desde el primer día. Aquí los organizamos en un sistema llamado La Pirámide de Pruebas, que va de lo más pequeño y rápido hasta lo más amplio y complejo.

Cada nivel tiene un propósito específico. Saltarte uno es como construir un edificio sin revisar los cimientos.

Pruebas unitarias: el microscopio del código

Una prueba unitaria verifica la pieza más pequeña de código posible: una sola función o método.

Piensa en una calculadora de descuentos. Si tienes una función que calcula el 20% de descuento sobre un precio, la prueba unitaria confirma que esa función devuelve el resultado correcto con diferentes valores de entrada. No importa el resto del sistema. Solo esa función.

Ejemplo concreto: El equipo de Mercado Libre tiene una función llamada calcular_comision(). Esta función toma el precio de venta de un producto y devuelve la comisión del vendedor. Una prueba unitaria verifica que si el precio es $1,000, la función devuelve exactamente $130. Si el precio es $500, devuelve $65. Rápido, preciso, automatizable.

Las pruebas unitarias las escriben normalmente los desarrolladores. Pero un QA intermedio debe saber leerlas y proponer casos de prueba adicionales. Por ejemplo: ¿qué pasa si el precio es $0? ¿O negativo? Esos casos límite son territorio QA.

¿Cuándo usarlas? Siempre que se escriba código nuevo. Son la primera línea de defensa.

Pruebas de integración: verificar que las piezas hablen entre sí

Una prueba de integración verifica que dos o más componentes del sistema funcionen correctamente juntos.

Aquí el foco no es una función aislada, sino la comunicación entre módulos. Una función puede funcionar perfecta sola y aun así fallar cuando interactúa con otra.

Ejemplo concreto: FEMSA tiene una app de conveniencia donde el usuario selecciona productos, aplica un cupón y paga con tarjeta. La prueba de integración verifica que el módulo de cupones se comunica bien con el módulo de precios. Si el cupón dice "20% de descuento" y el módulo de precios no lo aplica correctamente, la prueba lo detecta antes de que el cliente lo vea.

Otro ejemplo: el sistema de nómina de Bimbo se conecta al IMSS para reportar altas y bajas de empleados. Una prueba de integración confirma que los datos que salen del sistema de Bimbo llegan correctamente a la API del IMSS, con el formato y los campos requeridos por la norma.

¿Cuándo usarlas? Cada vez que conectas dos módulos o servicios. Son especialmente críticas en sistemas con APIs externas, como las del SAT o del IMSS.

Pruebas funcionales: el punto de vista del usuario

Una prueba funcional verifica que una función completa del sistema produce el resultado esperado desde la perspectiva del usuario.

No le importa cómo está construido el código por dentro. Solo le importa: ¿el sistema hace lo que se supone que debe hacer?

Ejemplo concreto: Liverpool tiene un flujo de compra en línea. La prueba funcional sigue estos pasos:

1. El usuario busca un refrigerador.
2. Lo agrega al carrito.
3. Ingresa su dirección de entrega en CDMX.
4. Selecciona pago con tarjeta de crédito.
5. Confirma el pedido.

La prueba verifica que al final el usuario recibe un número de pedido, le llega un correo de confirmación y el inventario del producto se actualiza. Si cualquiera de esos pasos falla, la prueba lo reporta.

Las pruebas funcionales se basan en los casos de uso o historias de usuario definidos en el proyecto. Si la historia dice "el usuario puede filtrar productos por precio", la prueba funcional confirma exactamente eso.

¿Cuándo usarlas? Antes de cada entrega al usuario o cliente. Son el "sello de aprobación" del QA sobre una funcionalidad completa.

Pruebas de regresión: proteger lo que ya funcionaba

Una prueba de regresión verifica que los cambios nuevos en el sistema no rompieron algo que antes funcionaba bien.

Este es uno de los errores más comunes en desarrollo: arreglas un bug y, sin querer, rompes otra parte del sistema. La regresión lo detecta.

Ejemplo concreto: El equipo de Mercado Libre corrige un error en el módulo de pagos. Después de ese cambio, el equipo ejecuta un suite de regresión que prueba 200 funciones del sistema. Así confirman que el fix del módulo de pagos no afectó el módulo de envíos, el de reseñas ni el de descuentos.

Las pruebas de regresión suelen ser automatizadas porque se ejecutan con frecuencia. Cada vez que el equipo sube código nuevo, el sistema corre las pruebas de regresión automáticamente. Si algo falla, el equipo recibe una alerta antes de que el cambio llegue a producción.

¿Cuándo usarlas? Después de cada cambio significativo en el código. En equipos ágiles, se corren en cada sprint o incluso en cada commit.

Errores comunes al elegir el tipo de prueba

Muchos equipos cometen estos errores. Reconocerlos te ayuda a evitarlos desde el inicio.

Error 1: Solo hacer pruebas funcionales y saltarse las unitarias. Es como revisar si el edificio se ve bonito sin verificar si los cimientos son sólidos. Cuando hay un bug, no sabes en qué parte exacta del código está. Las pruebas unitarias te lo dicen de inmediato.

Error 2: No correr regresión después de un "arreglo pequeño". No existe el cambio tan pequeño que no pueda romper algo. Un desarrollador cambia una línea de código en el sistema de facturación de una empresa y, sin regresión, nadie nota que ahora los XMLs del SAT salen con un campo vacío. El problema se descubre cuando el SAT rechaza las facturas.

Error 3: Confundir pruebas de integración con funcionales. Las de integración verifican la comunicación entre componentes internos. Las funcionales verifican el comportamiento desde el punto de vista del usuario. Son diferentes niveles de abstracción. Mezclarlos genera confusión en los reportes de defectos.

Error 4: Hacer solo pruebas manuales y nunca automatizar la regresión. Si tu suite de regresión tiene 500 casos y los corres a mano cada semana, pierdes días enteros. Automatizar esa regresión libera tu tiempo para explorar áreas nuevas del sistema.

Cómo aplicar los cuatro tipos en un proyecto real

Aquí tienes un flujo práctico que puedes seguir en cualquier proyecto:

1. Al escribir código nuevo: asegúrate de que haya pruebas unitarias para cada función crítica.
2. Al conectar módulos: diseña pruebas de integración que verifiquen los puntos de conexión.
3. Al entregar una funcionalidad: ejecuta pruebas funcionales basadas en las historias de usuario.
4. Al hacer cualquier cambio: corre el suite de regresión antes de subir a producción.

Este ciclo es repetible. Lo puedes aplicar en el sistema de inventario de una tienda, en la app de recursos humanos de una empresa o en el portal de pagos de un banco.

Los cuatro tipos trabajan juntos, no por separado

Cada tipo de prueba cubre un ángulo diferente del sistema. Las unitarias te dicen que cada pieza está bien construida. Las de integración confirman que las piezas encajan. Las funcionales verifican que el resultado final tiene sentido para el usuario. La regresión protege todo lo anterior cuando el sistema cambia.

El profesional de QA que entiende cuándo usar cada tipo de prueba no solo encuentra bugs: previene las crisis antes de que lleguen al usuario.