Elegir países para datos de prueba es una decisión de diseño y no una lista que se copia de un sitio a otro. El conjunto que uses determina qué defectos vas a descubrir y, sobre todo, cuáles van a pasar desapercibidos hasta que aparezcan en producción. Esta guía propone tres ejes concretos para armar ese conjunto, explica para qué sirve cada tipo de territorio y cierra con la parte que casi todos los equipos olvidan: darle versión propia al conjunto.
Ten en cuenta desde el principio que aquí se habla de la capa de datos entre países, no de cómo se escribe cada campo. Si lo que necesitas es el detalle de un formato concreto, lo tienes en la guía sobre los formatos de código postal por país, que trata ese tema campo por campo.
¿Por qué conviene elegir los países del conjunto y no tomarlos al azar?
Porque un conjunto tomado al azar concentra sus muestras en los territorios que el propio equipo conoce. Si quien monta las pruebas vive en un país donde la dirección siempre tiene la misma forma, la lista acabará con variantes de esa misma forma y con nombres de ciudades inventadas que se parecen demasiado entre sí.
El segundo motivo es más incómodo: un conjunto sesgado no falla ruidosamente, simplemente nunca activa las ramas difíciles. El formulario parece funcionar durante meses y luego recibe un pedido real desde un territorio donde la división administrativa no viene en el código postal y la dirección se rechaza aunque sea correcta.
Un tercer motivo es el coste de mantenimiento. Cada territorio de la lista hay que mantenerlo, refrescarlo y saber quién responde por él. Un conjunto grande elegido sin criterio se vuelve caro de sostener y nadie se atreve a borrar nada.
Los tres ejes: alcance comercial, dificultad del dato y valor límite
Los tres ejes se solapan en parte, pero responden a preguntas distintas y conviene puntuarlos por separado.
| Eje | Pregunta que responde | Qué aporta al conjunto |
|---|---|---|
| Alcance comercial | ¿A qué territorios llega de verdad el negocio? | Medios de pago, zonas de envío, moneda de liquidación |
| Dificultad del dato | ¿Qué forma tiene el dato que hay que aceptar? | Alfabetos, sentidos de escritura, longitudes de línea |
| Valor límite | ¿Dónde es más probable que se rompa algo? | Territorios muy pequeños o muy grandes, campos que no aplican |
El primer eje evita que el conjunto describa un producto que no existe: probar envíos a territorios que nunca se atenderán consume tiempo y da una falsa sensación de cobertura. El segundo eje mira el dato, no el mercado: un territorio puede ser comercialmente irrelevante y aun así aportar una forma de escritura que ningún otro de la lista tiene. El tercero es el que suele faltar, y es el que más defectos encuentra.
Qué territorios funcionan como valor límite
Un valor límite aquí no es una curiosidad exótica: es un caso que ejerce presión sobre una validación concreta. Los más útiles suelen caer en cuatro grupos.
- Territorios cuya línea de dirección puede ser muy larga, que ponen a prueba el recorte y el ajuste de línea en etiquetas y plantillas.
- Territorios con nombres de país extensos, que rompen menús desplegables estrechos y columnas de ancho fijo.
- Territorios con caracteres fuera del alfabeto latino, que revelan conversiones de codificación mal hechas.
- Territorios donde el dato del campo no aplica en absoluto, que son el punto siguiente.
La razón de incluirlos es mecánica: son los que activan los límites que el resto de la lista nunca toca. Sin ellos, un error de truncado puede vivir tranquilo durante años.
¿Cómo se prueban los territorios donde un campo no existe?
Se prueban cambiando la pregunta. En lugar de comprobar si el campo acepta un valor, se comprueba si el sistema admite que ese campo no tenga valor sin tratarlo como un error.
Hay territorios sin red de códigos postales y territorios sin un nivel administrativo intermedio en la dirección. Si tu conjunto no los incluye, la aserción de campo obligatorio nunca se enfrentará a un caso legítimo de campo ausente, y el formulario rechazará direcciones válidas.
La forma de cubrirlo no es marcar el campo como opcional en todas partes, sino declarar explícitamente para qué territorios el campo no aplica y hacer que esa declaración venga de los datos y no de una condición escrita a mano en el formulario. Si te interesa el lado de la cobertura y de los estados posibles del dato, la guía sobre la lista de cobertura de datos por país desarrolla ese punto.
La composición de un conjunto por defecto
Un conjunto que funciona en la práctica suele mezclar tres bloques, y cada uno tiene una función que los otros no cubren.
- Un territorio de base, donde se originan la mayoría de las pruebas manuales y donde el equipo reconoce un error a simple vista.
- Unos pocos mercados principales, que son los que sostienen el negocio real y cuyos flujos hay que proteger de regresiones.
- Un puñado de valores límite, elegidos por lo que rompen y no por lo que representan en ventas.
La proporción importa menos que la presencia de los tres. Un conjunto con veinte mercados principales y ningún valor límite está peor preparado que uno con cuatro territorios bien elegidos.
¿Qué pasa cuando el conjunto cambia?
Pasa que el significado de las aserciones antiguas cambia con él. Un informe de regresión de la semana pasada se generó contra una lista que ya no existe, y comparar los dos resultados lleva a conclusiones falsas sobre qué se rompió.
La salida es tratar el conjunto como un objeto con versiones. Cada versión declara qué territorios entran, cuáles salen y por qué. Así, cuando una prueba empieza a fallar, se puede consultar si el fallo viene de un cambio de código o de un cambio de lista.
Además, conviene registrar por separado las aserciones que dependen de la lista y las que no. Las primeras hay que volver a ejecutarlas tras cada cambio de versión; las segundas no.
Notas para quien programa
- Declara el conjunto en un solo sitio y consúmelo desde ahí. Si cada suite arma su propia lista, ninguna versión significa nada.
- Nombra los territorios por código estable y guarda el nombre solo para mostrar. Un cambio de nombre no debe obligar a tocar las pruebas.
- Marca la aplicabilidad de cada campo por territorio como dato explícito, no como excepción escrita en el formulario.
- Deja el conjunto fuera del código de la aplicación: así se puede revisar y reemplazar sin recompilar nada.
- Registra la fecha de cada versión del conjunto junto a los informes de regresión que la usaron.
- Nunca rellenes el conjunto con datos de personas reales, ni siquiera en entornos internos.
Siguientes pasos
Abre el conjunto que usa tu equipo hoy y clasifica sus territorios según los tres ejes. Si el eje de valor límite está vacío, ya sabes dónde empezar. Para comparar candidatos y ver qué territorios tienen página propia en este sitio, el directorio de países y regiones reúne la información de cada uno en un solo lugar. Y si el problema que tienes es que los datos ya no coinciden con la realidad, la guía sobre la vigencia de los datos de país explica qué guardar para poder detectarlo a tiempo.
Aviso sobre los ejemplos: los territorios, agrupaciones y conjuntos que aparecen en este texto se han construido solo para ilustrar el razonamiento. No describen la lista de ningún producto real ni el alcance de cobertura de ningún sistema, y no deben tomarse como una recomendación de qué territorios atender.