6. Flujos críticos del negocio y selección de escenarios

6.1 Introducción

Una suite de pruebas End-to-End no debería intentar probar todos los recorridos posibles de una aplicación. El objetivo es seleccionar escenarios que aporten mucha confianza sobre los procesos más importantes.

Para lograrlo, necesitamos identificar los flujos críticos del negocio: aquellos recorridos que, si fallan, afectan de manera importante al usuario, a la operación, a los ingresos, a la seguridad o a la reputación del producto.

En este tema veremos cómo reconocer esos flujos y cómo convertirlos en escenarios E2E bien elegidos.

6.2 Qué es un flujo crítico del negocio

Un flujo crítico del negocio es una secuencia de acciones necesaria para que la aplicación cumpla un objetivo importante. No siempre se trata de dinero; también puede estar relacionado con cumplimiento legal, continuidad operativa, atención al cliente o seguridad.

Un flujo es crítico cuando su falla genera impacto significativo para usuarios, negocio, operación o confianza en el sistema.

Por ejemplo, en una tienda en línea, comprar un producto es un flujo crítico. En una aplicación bancaria, transferir dinero es crítico. En un sistema educativo, inscribirse a un curso o rendir una evaluación puede ser crítico.

6.3 Por qué no probar todo con E2E

Las pruebas E2E tienen más costo que otros niveles de prueba. Requieren ambiente, datos, usuarios, dependencias y tiempo de ejecución. Si intentamos cubrir todos los detalles con E2E, la suite puede volverse lenta y difícil de mantener.

Por eso la selección de escenarios es una actividad clave. No buscamos una lista enorme de pruebas, sino una lista valiosa.

  • Menos escenarios, pero mejor elegidos.
  • Menos repetición, pero más cobertura de riesgo real.
  • Menos pruebas frágiles, pero más confianza sobre procesos críticos.

Una suite E2E profesional protege los recorridos esenciales y deja los detalles numerosos a pruebas unitarias, de integración o de API.

6.4 Fuentes para detectar flujos críticos

Los flujos críticos no se inventan solamente desde el equipo técnico. Deben identificarse mirando cómo se usa realmente el producto y qué consecuencias tendría una falla.

Algunas fuentes útiles son:

  • Objetivos del negocio: ventas, reservas, altas, aprobaciones, pagos o reportes importantes.
  • Usuarios frecuentes: recorridos que se ejecutan todos los días o muchas veces por hora.
  • Historial de defectos: zonas donde hubo fallas graves o repetidas.
  • Analítica del producto: pantallas y acciones más usadas.
  • Soporte al cliente: problemas reportados por usuarios reales.
  • Riesgos legales o de seguridad: operaciones que deben ejecutarse correctamente por obligación.
  • Personas del negocio: product owners, responsables operativos y usuarios clave.

Cuanto más conectada esté la selección de pruebas con el uso real, mayor será el valor de la suite E2E.

6.5 Criterios de criticidad

Para decidir si un flujo merece una prueba E2E, podemos evaluar varios criterios. No todos tienen el mismo peso en todos los proyectos.

Criterio Pregunta Ejemplo
Impacto económico ¿Una falla impide ingresos o genera pérdidas? No se puede completar una compra.
Frecuencia ¿El flujo se usa muchas veces? Inicio de sesión diario de usuarios.
Riesgo operativo ¿La operación depende de este proceso? Asignar turnos o despachar pedidos.
Visibilidad ¿La falla afecta directamente a muchos usuarios? La página pública no permite registrarse.
Cumplimiento ¿Hay obligaciones legales o normativas? Generar comprobantes o reportes obligatorios.
Historial ¿Ya tuvo defectos importantes? El proceso de pago falló en versiones anteriores.

6.6 De flujo crítico a escenario de prueba

Un flujo crítico es una idea de negocio. Un escenario de prueba es una descripción concreta y verificable de cómo se validará ese flujo.

Por ejemplo:

Flujo crítico Escenario E2E
Comprar un producto. Usuario registrado compra un producto disponible con pago aprobado y ve la orden confirmada.
Reservar un turno. Paciente autenticado reserva un turno disponible y lo ve en su agenda.
Enviar una solicitud. Usuario completa una solicitud con datos válidos y el sistema la registra con estado pendiente.

El escenario debe ser específico: quién lo ejecuta, con qué datos, qué pasos principales realiza y qué resultado esperamos.

6.7 Seleccionar el camino principal

Cuando se comienza a construir una suite E2E, conviene partir por el camino principal, también llamado camino feliz. Es la versión del flujo donde todo sale correctamente.

Por ejemplo, en una compra:

  • El usuario ya tiene cuenta.
  • El producto está disponible.
  • El pago es aprobado.
  • La orden se genera correctamente.
  • El usuario ve la confirmación.

Este escenario inicial ofrece una verificación rápida de que el proceso esencial funciona. Luego pueden agregarse escenarios alternativos o de error.

6.8 Seleccionar variantes importantes

Después del camino principal, podemos evaluar variantes que tengan valor real. No todas las variantes merecen una prueba E2E. Debemos elegir las que cambian el riesgo o el comportamiento del flujo.

Ejemplos de variantes valiosas:

  • Compra con cupón de descuento.
  • Reserva de turno para un familiar.
  • Solicitud que requiere aprobación de otro rol.
  • Pago rechazado con mensaje claro al usuario.
  • Usuario sin permisos intenta acceder a una acción protegida.

Una variante es valiosa si cubre una decisión importante, una regla diferente o un riesgo que no aparece en el camino principal.

6.9 Evitar escenarios duplicados

Una suite E2E puede crecer rápido si no se controla la duplicación. Dos escenarios pueden parecer distintos, pero validar prácticamente el mismo riesgo.

Por ejemplo, si ya tenemos una prueba E2E que compra un producto, no necesariamente necesitamos otra prueba completa para comprar un producto de color diferente, otro talle y otra categoría, salvo que esas diferencias afecten reglas relevantes.

Si dos escenarios recorren el mismo flujo y solo cambian un dato sin impacto real, probablemente uno de ellos sobra o debe moverse a otro nivel de prueba.

6.10 Priorización por riesgo

Cuando hay muchos escenarios candidatos, conviene priorizar por riesgo. Una forma simple es evaluar impacto y probabilidad.

Impacto Probabilidad Prioridad Ejemplo
Alto Alta Muy alta Flujo de pago modificado recientemente.
Alto Baja Alta o media Generación anual de reporte legal.
Bajo Alta Media o baja Cambio visual en una página secundaria.
Bajo Baja Baja Variante poco usada sin impacto operativo.

Este análisis ayuda a justificar por qué algunos escenarios entran en la suite E2E y otros no.

6.11 Escenarios mínimos para una primera suite

En una primera versión de la suite E2E, es mejor comenzar con pocos escenarios bien elegidos. Un conjunto inicial podría incluir:

  • Un flujo de autenticación básico.
  • El flujo principal que genera valor para el negocio.
  • Un flujo de consulta o visualización importante.
  • Un flujo administrativo esencial, si existe.
  • Un caso de error crítico que debe manejarse correctamente.

Este conjunto no cubre todo, pero puede dar una señal temprana de salud del sistema.

6.12 Ejemplo: plataforma de cursos

Para una plataforma de cursos, podríamos identificar estos flujos candidatos:

Flujo candidato Criticidad ¿Conviene E2E?
Alumno compra un curso y accede al contenido. Alta Sí, es el flujo principal de valor.
Alumno cambia su foto de perfil. Baja No al inicio; puede probarse en otro nivel o manualmente.
Docente publica una nueva clase. Alta Sí, si es central para la operación.
Alumno filtra cursos por categoría. Media Depende del uso y del riesgo.
Pago rechazado muestra mensaje claro. Alta Sí, si evita confusión y reclamos.

6.13 Errores comunes al seleccionar escenarios

Al elegir escenarios E2E, conviene evitar estos errores:

  • Elegir escenarios solo porque son fáciles de automatizar.
  • Crear una prueba E2E para cada pantalla de la aplicación.
  • Repetir el mismo flujo con cambios mínimos de datos.
  • Ignorar flujos críticos porque son más difíciles de preparar.
  • No consultar a negocio, soporte o usuarios clave.
  • Confundir cantidad de pruebas con calidad de cobertura.

La selección de escenarios debe estar guiada por riesgo, valor y claridad, no por comodidad o volumen.

6.14 Documentar la decisión

Es útil registrar por qué un escenario fue elegido para E2E. Esto ayuda a mantener la suite en el tiempo y evita discusiones repetidas cuando cambian las prioridades.

Una documentación simple puede incluir:

  • Nombre del flujo.
  • Usuario o rol que lo ejecuta.
  • Motivo de criticidad.
  • Resultado esperado principal.
  • Datos necesarios.
  • Riesgo cubierto.
  • Razón por la que se eligió E2E y no otro nivel.

Esta información vuelve más fácil revisar si una prueba sigue siendo necesaria meses después.

6.15 Qué debes recordar de este tema

  • Una suite E2E debe centrarse en flujos críticos, no en todos los recorridos posibles.
  • Un flujo es crítico si su falla tiene impacto importante en usuarios, negocio u operación.
  • La selección de escenarios debe basarse en riesgo, frecuencia, impacto e historial de defectos.
  • Primero conviene cubrir caminos principales y luego variantes de alto valor.
  • Los escenarios duplicados aumentan mantenimiento sin aportar confianza real.
  • Una primera suite E2E debe ser pequeña, clara y defendible.
  • Documentar por qué se eligió cada escenario ayuda a mantener la estrategia.

6.16 Conclusión

Seleccionar escenarios E2E es una decisión estratégica. La pregunta central no es cuántas pruebas podemos crear, sino cuáles aportan más confianza sobre los procesos que realmente importan.

Una buena suite End-to-End protege los flujos críticos del negocio, evita duplicaciones y se mantiene enfocada en riesgos concretos. Así entrega valor sin transformarse en una carga excesiva para el equipo.

En el próximo tema veremos cómo relacionar historias de usuario, criterios de aceptación y escenarios E2E.