Niveles y Tipos de Prueba

Un desarrollador ejecuta pruebas unitarias sobre la función `calcularDescuento()` en aislamiento, con stubs para el servicio de precios.

Un equipo de QA verifica que el servicio de pagos y el servicio de facturación intercambien correctamente los datos de una transacción a través de su contrato de API, sin usar dobles de prueba para ninguno de los dos.

El equipo de rendimiento ejecuta una prueba de carga con 5.000 usuarios concurrentes contra el sistema completo desplegado en staging, midiendo los tiempos de respuesta bajo estrés.

Antes del lanzamiento, representantes del área de negocio ejecutan el flujo completo de compra siguiendo los criterios de aceptación acordados, para decidir si el sistema está listo para producción.

Tras aplicar un hotfix en producción, el equipo vuelve a ejecutar exactamente el caso de prueba que antes había fallado, sobre el sistema completo desplegado, para confirmar que el defecto quedó corregido.

Un desarrollador escribe pruebas basadas en la estructura interna de un módulo, diseñadas para ejercitar todas las ramas de sus decisiones (cobertura de decisión), con acceso directo al código fuente.

Un equipo de UX conduce una sesión de pruebas de usabilidad de punta a punta sobre el producto completo, midiendo cuán fácil les resulta a los participantes completar tareas típicas.

Después de que el equipo de backend modifica la estructura de un payload, se ejecutan pruebas de contrato entre la app móvil y su backend para confirmar que la interfaz entre ambos sigue funcionando tras el cambio.

Un grupo de clientes reales prueba una versión beta del producto en su propio entorno de uso cotidiano, evaluando si el software resuelve sus necesidades antes del lanzamiento general.

Un especialista en seguridad realiza un test de penetración sobre la aplicación completa ya desplegada, buscando vulnerabilidades explotables en el sistema en su conjunto.

Tras refactorizar el bus de mensajería interno, el equipo ejecuta una suite de regresión enfocada en los límites entre los módulos que se comunican a través de él, para detectar efectos secundarios del cambio.

Un desarrollador ejecuta un micro-benchmark de rendimiento sobre una función de parseo aislada, midiendo si su tiempo de ejecución se mantiene dentro de un presupuesto definido.