IBAN de prueba para QA: guía de datos sintéticos seguros

Respuesta rápida: ¿qué es un IBAN de prueba?

Un IBAN de prueba es un International Bank Account Number sintético creado para probar el comportamiento de un software. Los equipos lo usan en campos de pago, selectores de país, normalización, fixtures de API, pruebas de navegador, capturas, formación y documentación. La cadena debe parecerse al formato del país seleccionado y puede superar las reglas matemáticas que necesita tu código.

La palabra importante es prueba. Un valor generado no sirve para localizar una cuenta real, identificar a un beneficiario ni consultar un directorio bancario. El generador IBAN masivo crea filas sintéticas aisladas y el comprobador IBAN revisa los caracteres introducidos. Ninguna de las dos herramientas contacta con un banco ni verifica la titularidad.

• Uso adecuado: validación de formularios, parsers, fixtures, regresiones, demos y documentación técnica.
• Uso inadecuado: transferencias, adeudos, altas de beneficiarios, afirmaciones de titularidad o búsqueda de cuentas.
• Guarda la etiqueta del fixture, el límite del entorno y la regla de limpieza junto al dato.

Un dato sintético no es una cuenta bancaria real

Un valor sintético sirve para ejercitar un formato. Puede tener el prefijo de país correcto, la longitud total esperada, clases de caracteres BBAN plausibles y un resto MOD-97 igual a 1. Esas comprobaciones responden a una pregunta técnica limitada: ¿la cadena se comporta como un IBAN estructuralmente válido para esa regla?

Un IBAN emitido por un banco responde a otras preguntas. Puede estar ligado a una cuenta, un banco, una sucursal, una moneda, una vía de pago, un beneficiario y un estado actual. Un comprobador local no puede demostrar esos hechos a partir de los caracteres. Por eso una cadena puede superar el checksum y aun así estar sin asignar, inactiva, ser inadecuada para un pago o estar diseñada solo como fixture.

Valida un IBAN de prueba en tres capas

Un fixture útil no es solo una cadena aleatoria. Empieza por el formato registrado del país y prueba cada capa por separado para que el fallo apunte al código correcto. El directorio de países IBAN ayuda a comparar longitudes y patrones BBAN; el decodificador IBAN muestra las partes visibles de un valor completo.

Primero comprueba el código de país y la longitud total. Después revisa si el BBAN permite caracteres numéricos, alfabéticos o alfanuméricos. Por último ejecuta MOD-97-10. Una suite de pruebas debe incluir valores correctos y fallos intencionados, porque el tratamiento del error también forma parte del contrato.

1. 1. País y longitudSelecciona un país admitido y confirma la longitud fija registrada para el valor completo.
2. 2. Patrón de caracteresComprueba que cada campo nacional acepta los dígitos o letras definidos por la regla.
3. 3. Checksum MOD-97Aplica el cálculo internacional y confirma el resto esperado.
4. 4. Límite de negocioRegistra que el resultado es solo estructural; no lo conviertas en una afirmación de titularidad o pago.

• Separa el fallo de longitud del fallo de checksum para que la interfaz explique el primer problema útil.
• Cambia un solo dígito de control en un fixture válido para probar un error preciso.
• Usa letras en un campo numérico solo cuando el caso negativo sea intencionado y esté documentado.

Un flujo seguro para fixtures de QA

Trata un IBAN de prueba como cualquier fixture sintético: define su objetivo, genéralo con una regla conocida, valídalo, etiquétalo y mantenlo dentro del entorno que lo necesita. El orden importa porque una cadena matemáticamente válida puede ser peligrosa si termina en una semilla de producción, una factura, una exportación de clientes o una lista de beneficiarios reales.

Para pocos casos puedes crear un valor con el generador de la portada. Para una matriz o regresión usa el generador masivo y exporta CSV o JSON. Añade en tu fixture país, longitud, resultado esperado, propósito y responsable de limpieza. El navegador genera los valores, pero tu repositorio y tu CI siguen necesitando controles propios de datos de producción.

1. DefinirEscribe el país, el comportamiento del campo, el resultado esperado y el motivo del fixture.
2. GenerarCrea valores sintéticos según la regla del país; no copies datos de clientes a una base de pruebas.
3. ValidarEjecuta aserciones de longitud, patrón y MOD-97 y guarda el resultado esperado.
4. Aislar y limpiarMantén los fixtures en datasets de prueba, bloquea su promoción y elimínalos o rótalos tras la ejecución.

Crea una matriz de pruebas, no solo un caso feliz

Un único valor que pasa demuestra muy poco. Una suite sólida cubre diferencias entre países, formatos de presentación y fallos previsibles. Incluye un formato corto y uno largo, BBAN numérico y alfanumérico, un valor impreso con espacios, uno electrónico compacto, entrada en minúsculas y un valor con un dígito de control cambiado.

Los países exactos dependen de tu producto. La tabla es un patrón de planificación, no una promesa de que todos los valores funcionen en un sandbox de proveedor. Si un proveedor de pagos entrega identificadores propios de sandbox, sigue su documentación y sepáralos de los fixtures genéricos de formato.

• Guarda el resultado esperado junto al fixture para que un cambio de validador sea revisable.
• Usa IDs descriptivos como `iban-de-length-22-valid` en lugar de una cadena aleatoria sin etiqueta.
• No incluyas nombres, tarjetas, facturas ni extractos reales en un caso sintético.

Errores comunes y límites prácticos

El error más habitual es usar fake IBAN como si significara un valor seguro para pagar. En las búsquedas, fake puede significar fixture sintético, pero también puede sugerir engaño. En código, documentación y comunicación de equipo es mejor usar IBAN de prueba, IBAN sintético o fixture. Si alguien pide un dato para una transferencia, remítelo a una fuente bancaria propia y actualizada, no a un ejemplo público.

Otro error es tratar el comprobador como una consulta bancaria. Una herramienta de navegador puede explicar los caracteres que ve, pero no sabe si un identificador está activo, si una cuenta pertenece a una persona, si un beneficiario superó un control o si el pago se liquidará. Para esas preguntas hay que usar el banco, el proveedor o el proceso de verificación correspondiente.

• No llames oficial, seguro para pagar, asignado o verificado por titularidad a un valor sintético.
• No deduzcas un IBAN a partir de un nombre, tarjeta, cuenta local o captura de pantalla.
• No publiques un fixture en una factura, nómina, instrucción de reembolso o mandato de adeudo real.
• No dependas de un rango universal reservado; aísla y etiqueta todos los datos generados.