¿Qué es Volume Testing?

¿Qué es volume testing?

Volume testing mide cómo se comporta un sistema cuando los datos que maneja son muy grandes: una tabla de base de datos con 500 millones de rows, un upload de archivo de 5 GB, una queue con 10 millones de mensajes en backlog, un índice de búsqueda de 50 millones de documentos. La meta es encontrar el failure mode que aparece solo a escala de datos: una query que usa un índice a 1 millón de rows pero un sequential scan a 100 millones; un endpoint streaming que bufferea el payload completo en memoria; un queue consumer que bloquea en un solo poison message a depth 8 millones.

Volume testing es una disciplina de data-path, no de concurrencia. Un solo usuario subiendo un archivo de 10 GB o corriendo un reporte sobre 5 años de datos es un volume test aunque la concurrencia sea 1.

Volume testing vs load testing

Ambos estresan el sistema pero por ejes distintos:

• Volume testing: fijar concurrencia, escalar tamaño de datos. Pregunta "¿qué pasa cuando la tabla tiene 1 billón de rows o el message body es de 100 MB?"
• Load testing: fijar tamaño de datos, escalar concurrencia. Pregunta "¿qué pasa cuando 10.000 usuarios hitean un request normal simultáneamente?" Ver load testing.

Necesitas ambos. Un sistema puede pasar load tests con un dataset pequeño de staging y colapsar de inmediato en producción donde la tabla customers es 100x más grande. El failure clásico: un developer escribe una query ORM que produce un execution plan limpio sobre 10.000 rows, y en producción hace un full table scan que lockea la tabla por 4 minutos. Volume tests atrapan esto; load tests no.

Cuándo correr volume tests

• Antes de una migración de datos: staging tiene 1 GB de datos, producción tiene 1 TB. El script de migración que corre en 30 segundos en staging puede correr 8 horas en producción.
• Antes de añadir bulk import o export: CSV upload, bulk API, export a data warehouse. El endpoint que maneja 1.000 rows puede OOMear a 100.000.
• Antes de que una feature de reporting shippeé: una query que agrega sobre 5 años de transacciones a full row count se comporta nada parecido a la misma query sobre un test dataset.
• Cuando los datos de cliente crecen sustancialmente: el primer cliente enterprise se onboardea con 200x el dataset de cualquier cliente previo.
• Al actualizar versiones de base de datos: los query planners de Postgres o MySQL pueden cambiar comportamiento a row counts grandes. Volume test el upgrade contra una copia.
• Antes de cambiar backends de storage: S3 a disco local, single-region a multi-region, primary-replica a sharded. Volume tests sacan a la luz los supuestos de data plane que se rompieron.

Volume failure modes a buscar

1. Flips de query plan: la base de datos deja de usar un índice sobre cierto threshold de rows y empieza a escanear. Atrapar con EXPLAIN ANALYZE a row counts de producción.
2. Presión de memoria en code paths streaming: código que debería streamear una respuesta bufferea el result set completo en memoria.
3. Escalación de locks: un row-level lock que escala a table lock a row counts altos.
4. Colapso de paginación: paginación basada en OFFSET que cuesta O(N) por página, se vuelve inusable pasada la página 10.000.
5. Starvation de queue consumer: un poison message a queue depth 8 millones bloquea cada consumer detrás.
6. Ventana de backup explotada: un backup nightly que termina en 20 minutos en staging tarda 12 horas en datos de producción.
7. Tiempo de rebuild de índice: dropear y recrear un índice en una tabla es instantáneo a 100k rows, lockea la tabla por 6 horas a 100 millones.

Cómo correr volume tests

Construir un dataset del tamaño de producción (un backup reciente restored a una copia de staging es el camino más fácil; redactar PII primero). Correr el workload targeteado: un solo usuario hiteando el endpoint de bulk import, el batch job nightly, la query de reporting, el queue consumer con un backlog real. Medir tiempo de ejecución, peak de memoria, duración de locks y cualquier error.

Volume testing complementa load testing, soak testing y capacity testing. Cada uno atrapa una clase distinta de failure: load tests atrapan bugs de concurrencia, soak tests atrapan memory leaks en el tiempo, volume tests atrapan bugs de data scale.

Para workloads que necesitan datos full-production-shape más carga concurrente (el caso realista), LoadFocus ofrece servicios de load testing donde ingenieros diseñan la matriz de test combinando volumen de datos y carga concurrente.