Análisis de valores límite: la técnica de pruebas funcionales que detecta errores de desfase de uno

Un equipo despliega una exportación nocturna que funciona sin problemas con 999 usuarios en el entorno de staging, pero se agota exactamente al llegar a 1.000 en producción. Nadie escribió «1.000» en la especificación. No hay ningún formulario que validar, ni ningún rango de edad que comprobar. El límite es real, y la batería de pruebas nunca lo tocó.

Ese es el vacío que deja la mayoría de los textos sobre pruebas. El análisis de valores límite (BVA) se describe como una técnica para probar entradas de formularios en los extremos: edades 17, 18, 19 y 64, 65, 66. Eso funciona para el formulario, pero deja fuera todo lo demás. En la práctica, los límites viven en el tamaño de las cookies, los horarios de cron, los pools de conexiones y los tiempos de ejecución por lotes, y ninguno de ellos está documentado en ningún lugar donde un tester pensaría en buscar. Para fundadores y líderes de producto, el costo de negocio de pasarlos por alto es directo: un límite que falla en producción es un incendio de soporte, un cliente perdido y una hoja de ruta retrasada. Es precisamente aquí donde una revisión sistemática de pruebas funcionales recupera su inversión.

Este artículo traza los cinco lugares donde realmente se esconden los límites en un producto ya lanzado, y qué probar en cada uno.

El límite que nadie documentó

El análisis de valores límite en las pruebas de software es una técnica de diseño de pruebas que se centra en los valores que se ubican en los extremos del comportamiento de un sistema, el punto donde termina una regla y empieza otra. La versión de manual se ocupa de los rangos de entrada. La versión útil se ocupa de todo lo demás.

La mayoría de los competidores se detienen en el formulario de entrada porque ahí el límite es fácil de ver. Un campo dice «de 18 a 65». Se prueban 17, 18, 65, 66. Listo. Los productos reales tienen cientos de límites que la especificación nunca menciona: el tamaño que puede alcanzar una cookie de sesión antes de que el navegador la descarte, la cantidad de filas que una Lambda puede procesar antes de que el tiempo de ejecución la mate, el milisegundo exacto en que se reinicia una ventana de limitación de solicitudes. Cada uno de ellos es un límite. Ninguno parece serlo hasta que falla.

El replanteamiento que vale la pena mantener durante el resto de este artículo: el análisis de valores límite es una disciplina de descubrimiento de límites, no un ejercicio de sustitución de valores. El trabajo del tester es encontrar dónde cambia el comportamiento del sistema y luego poner a prueba cada uno de esos puntos.

Por qué los errores de desfase de uno siguen llegando a producción

Los errores de desfase de uno siguen llegando a producción porque los documentos de requisitos describen la entrada ideal, los testers prueban lo que está escrito, y los límites implícitos solo aparecen bajo carga. El Consorcio para la Calidad de la Información y el Software (CISQ) reportó que el costo del software de mala calidad en Estados Unidos asciende a 2,41 billones de dólares en su análisis más reciente, y una parte considerable de esa cifra corresponde a los límites que nadie se molestó en documentar.

Tres patrones lo explican:

• El límite de 1.000 filas por lote vive en la configuración de tiempo de espera del ejecutor de tareas, no en el PRD
• Si nadie escribe «el tamaño de la cookie debe mantenerse por debajo de 4 KB», nadie agrega una prueba para eso
• Los límites explícitos se automatizan en pruebas unitarias durante el desarrollo; los implícitos los descubren los usuarios a las 2 de la madrugada.

El informe 2025 Annual Outage Analysis del Uptime Institute indica que el 85% de las interrupciones por error humano se remontan a que el personal no siguió los procedimientos o a fallas en los propios procedimientos. Las pruebas faltantes para límites no documentados caen exactamente en el segundo grupo. Deja de preguntar «¿cuál es el rango en la especificación?». Empieza a preguntar «¿dónde cambia el comportamiento este sistema?».

Análisis de valores límite frente a pruebas de casos extremos

Los dos términos se usan indistintamente, lo que oculta una distinción útil. El BVA es numérico y preciso: vive en un umbral medible, como la fila 999 frente a la 1.000 o el byte 4.095 frente al 4.096. Las pruebas de casos extremos son más amplias y cubren estados raros y combinaciones inusuales que pueden no tener un límite numérico claro, como un dispositivo sin conexión, un usuario sin permisos o una carga de archivo corrupta.

Todo límite es un caso extremo. No todo caso extremo es un límite. Si puedes ponerle un número al punto donde cambia el comportamiento, el BVA es la herramienta adecuada. Si el cambio es cualitativo en lugar de cuantitativo, las pruebas de casos extremos son más apropiadas, y cubren una porción más amplia de «donde terminan los requisitos y comienza la realidad».

Cinco lugares donde se esconden los límites

A continuación se presentan las cinco categorías donde viven los límites que el documento de requisitos no menciona. Cada una comienza con un patrón de error, nombra el límite que nadie documentó y ofrece los casos de prueba que lo revelan. Un ejemplo concreto de análisis de valores límite aparece en cada categoría, en lugar de limitarse a un único campo de juguete.

Límites de infraestructura que nadie documentó

La cookie de sesión de un usuario supera los 4 KB después de agregar un quinto proveedor de OAuth, y cada solicitud posterior descarta la sesión en silencio. Una URL con 50 parámetros de filtro supera el límite de encabezado de 8 KB de un proxy intermedio, y la API devuelve un 400 sin ningún motivo registrado. Ninguno de los dos límites está en la especificación del producto. Ambos están en un archivo de configuración.

Los límites ocultos en esta capa incluyen:

• El tamaño de la cookie, limitado a unos 4 KB por cookie en la mayoría de los navegadores
• El tamaño del encabezado HTTP, normalmente de 8 a 16 KB según el servidor
• La longitud de la URL, con límites prácticos de CDN y navegador alrededor de 2 KB
• El tamaño del cuerpo de la solicitud, con un valor predeterminado de 1 MB en nginx
• La MTU del paquete, de 1.500 bytes en Ethernet estándar

Casos de prueba que vale la pena agregar: una carga útil justo por debajo y justo por encima de cada límite, una cookie de sesión cercana a los 4 KB, una URL con suficientes parámetros de consulta para superar los 2 KB, una carga cuyo tamaño roce el límite del cuerpo del proxy. Revisa la configuración, no la especificación. Cuando estos casos aparecen en la capa de la API, las pruebas de API es donde se detectan.

Trampas de tiempo y calendario

El tiempo es la categoría que más castiga las suposiciones. Una suscripción facturada el día 31 se cobra dos veces en marzo y se salta abril. Una tarea cron programada para las 2:30 a. m. se ejecuta dos veces en el cambio de horario de otoño y ninguna vez en el de primavera. Un campo de marca de tiempo escrito como int32 se desbordará el 19 de enero de 2038, a las 03:14:07 UTC, y el problema del año 2038 es un límite con fecha propia.

Los límites temporales que hay que probar incluyen las transiciones de fin de mes en meses de 28, 29, 30 y 31 días, el día bisiesto, los cambios de horario de verano en ambas direcciones, los cambios a la semana ISO 53, y los aniversarios de facturación que se desplazan cuando un mes tiene menos días que la fecha de aniversario. Configura una suscripción el 31 de enero, avanza el reloj hasta el 28 de febrero y observa qué hace el motor de facturación. Ejecuta una tarea programada a través de un cambio de horario en una zona horaria que lo observe. Reserva un hotel con entrada el 28 de febrero de 2028 y salida el 1 de marzo.

Techos de los tipos de datos

Un contador de vistas almacenado como INT llega a 2.147.483.647, y el siguiente incremento se convierte en un número negativo o lanza un error. Un campo de moneda almacenado como float acumula errores de redondeo, y una factura de 100,00 $ termina reconciliándose como 99,9999998 $. Una columna de nombre de usuario ampliada de VARCHAR(50) a VARCHAR(100) entre versiones trunca en silencio las filas migradas del esquema anterior.

Los límites que se esconden en el esquema:

Lee el esquema antes de escribir el plan de pruebas. Estos límites son invisibles en la interfaz y evidentes en la base de datos.

Precipicios de paginación y procesos por lotes

Los límites de paginación viven en la primera página, la última página y la transición entre páginas cuando el total es un múltiplo exacto del tamaño de página. Los límites de los procesos por lotes viven en el límite de tiempo de ejecución que imponga el ejecutor, ya sean los 15 minutos de Lambda, los 60 minutos de Cloud Run o el cron de 5 minutos que el equipo de SRE configuró hace dos años.

El patrón clásico: una exportación procesa 999 filas en staging y se agota al llegar a 1.000 en producción, porque el límite real es el tiempo de ejecución, no la cantidad de filas. Otro caso: una vista de lista muestra 10 elementos por página, y la página 10 se renderiza vacía porque la lógica del cursor es offset = página × límite, con la indexación de páginas empezando en 1 en la URL y en 0 en la consulta.

Casos que conviene agregar: cargar exactamente page_size × N registros y solicitar la página N y la N+1. Solicitar la página 0 y la página −1. Ejecutar el trabajo por lotes con un conjunto de datos una fila por encima del umbral de tiempo de espera observado. Exportar una tabla con exactamente el límite de filas de la herramienta; Google Sheets tiene un tope de 10 millones de celdas, y Excel de 1.048.576 filas.

Umbrales de concurrencia

El quinto usuario simultáneo en una cuenta con límite de sesiones provoca la expulsión de la sesión 1, pero el bloqueo de expulsión entra en un interbloqueo con el flujo de inicio de sesión. El pool de conexiones de la base de datos está fijado en 20, y la consulta número 21 se bloquea en silencio en lugar de arrojar un error. Un limitador de tasa permite 100 solicitudes por minuto; la solicitud número 101 en una ráfaga devuelve un 429, pero el contador se reinicia un milisegundo después de comenzar la siguiente ventana, y el mismo cliente vuelve a dispararse de inmediato.

Los límites de concurrencia incluyen el tope de puestos del plan, el techo del pool de conexiones de la base de datos, el tamaño del pool de hilos, el límite de la ventana de limitación de tasa (fija frente a deslizante), los umbrales de contención de bloqueos y la profundidad de cola a partir de la cual los consumidores se quedan atrás de los productores. Pruébalo abriendo una sesión más de las que permite el plan y observando el comportamiento de expulsión. Ejecuta pool_size + 1 consultas simultáneas y mide si se bloquean o arrojan error. Dispara N solicitudes justo en el límite de la ventana fija de la limitación de tasa, y luego dispara N más un milisegundo después del reinicio.

Estos son los límites que permanecen ocultos hasta que el tráfico escala. El 2025 ITIC/Calyptix SMB Downtime Survey encontró que el 8% de las pequeñas y medianas empresas ahora reportan costos de inactividad que superan los 25.000 $ por hora, y un techo de concurrencia que se activa a las 3 de la madrugada es una de las formas más rápidas de llegar a esa cifra.

Cómo encontrar los límites que la especificación pasó por alto

El descubrimiento vale más que la sustitución de valores. Cuatro preguntas funcionan para cualquier funcionalidad bajo prueba:

• ¿De qué depende esta funcionalidad? Cookies, encabezados, URLs, cuerpos de solicitud, temporizadores, columnas de base de datos, pools de conexiones. Cada dependencia tiene un límite.
• ¿Cuál es el límite de cada dependencia? Revisa el archivo de configuración, el esquema, el SLA, la página de cuotas del proveedor de la nube. Si el límite no está escrito en ningún lado, ejecuta una prueba de carga para encontrarlo.
• ¿Qué sucede exactamente en ese límite, uno por debajo y uno por encima? Este es el movimiento clásico del BVA, aplicado a la infraestructura en lugar de a un campo de formulario.
• ¿Qué sucede cuando el límite cambia? Una migración de esquema, una mejora de plan, un cambio de configuración. Los límites se mueven. Las pruebas deben moverse con ellos.

El límite es real, se haya documentado o no. El trabajo del tester es encontrarlo antes de que lo haga el usuario.

Dónde encaja el BVA en el diseño de tus pruebas

Las pruebas de valores límite descubren dónde cambia de comportamiento un sistema. La partición de equivalencia te indica cuáles de los valores entre los límites puedes omitir con seguridad. Juntas comprimen un espacio de entrada enorme en un conjunto de pruebas pequeño y de alta señal que detecta los fallos que vale la pena detectar.

Dos técnicas vecinas en la misma caja de herramientas hacen que el BVA sea más preciso. La partición de equivalencia agrupa los valores que se comportan de la misma manera, indicándote cuáles de los valores entre los límites puedes omitir con seguridad. Las pruebas negativas generan las entradas incorrectas que los requisitos nunca autorizaron, detectando los fallos que el BVA no persigue. Juntas, las tres técnicas comprimen un espacio de entrada enorme en un conjunto de pruebas pequeño y de alta señal que detecta los fallos que vale la pena detectar.

Mapea el límite antes de que lo hagan tus usuarios

El tester que domina los límites ocultos no prueba valores. Mapea los lugares donde el sistema cambia de comportamiento y luego pone a prueba cada uno. El documento de requisitos es el punto de partida del análisis de límites, no el mapa completo.

Si tu último error de desfase de uno logró pasar la batería de pruebas, la solución no son más casos de prueba: es una revisión sistemática de los límites que nadie documentó. Contáctanos y revisaremos dónde podrían estar escondidos en tu producto.

Preguntas frecuentes

¿Qué límites debo probar además de los rangos de entrada?

Prueba los límites que el documento de requisitos no menciona: el tamaño de cookies y encabezados, la longitud de la URL, los topes del cuerpo de la solicitud, la MTU, las transiciones de horario de verano y fin de mes, los límites de precisión de int32 y float, el ancho de VARCHAR entre versiones de esquema, las páginas de paginación primera/última/múltiplo exacto, los topes de tiempo de ejecución por lotes, los techos del pool de conexiones, los bordes de la ventana de limitación de tasa y los topes de puestos del plan. Es ahí donde realmente llegan a producción los errores de desfase de uno.

¿Cómo se encuentran los límites que no están en los requisitos?

Aplica cuatro preguntas a cada funcionalidad: de qué depende, cuál es el límite de cada dependencia, qué sucede en ese límite y justo alrededor de él, y qué sucede cuando el límite cambia. Revisa el archivo de configuración, el esquema y la página de cuotas del proveedor de la nube. Si un límite no está documentado, una prueba de carga lo revelará.

¿Cuál es la diferencia entre el análisis de valores límite y las pruebas de casos extremos?

El análisis de valores límite es numérico y preciso; vive en un umbral medible, como la fila 999 frente a la 1.000. Las pruebas de casos extremos son más amplias y cubren estados raros o combinaciones inusuales que pueden no tener un límite numérico claro, como un dispositivo sin conexión o un usuario sin permisos. Todo límite es un caso extremo; no todo caso extremo es un límite.

¿Por qué los errores de desfase de uno todavía llegan a producción en 2026?

Los documentos de requisitos describen la entrada ideal, los testers prueban lo que está escrito, y los límites implícitos solo salen a la luz bajo carga. Los límites explícitos se automatizan durante el desarrollo. Los implícitos, como un tope de tiempo de ejecución de Lambda o un límite de tamaño de cookie, los descubren los usuarios a las 2 de la madrugada, porque nadie escribió una prueba para un límite que nadie documentó.