Menú

Prueba del campo de selección de país: búsqueda y teclado

La prueba del campo de selección de país va más allá de comprobar que se puede elegir: hay que cubrir las formas del control, las variantes de escritura, el orden y la accesibilidad.

Publicado el

  • formularios
  • accesibilidad

La prueba del campo de selección de país casi nunca falla por el motivo que se prueba. Que un valor se pueda seleccionar es la parte fácil; lo que se rompe en producción es la búsqueda que no encuentra una variante de escritura, el orden alfabético equivocado o el teclado que no puede salir del control. Esta guía repasa las formas habituales del campo, qué variantes debe reconocer la búsqueda y qué hay que comprobar después de cambiar el valor.

¿Qué formas puede tener un campo de selección de país?

Al menos cinco, y cada una tiene un perfil de riesgo distinto.

Forma Riesgo principal
Lista desplegable simple Orden incorrecto y listas largas que no se pueden recorrer
Lista con búsqueda Variantes de escritura que no coinciden
Lista agrupada por región Grupos que se pliegan y dejan opciones inalcanzables
Lista limitada a territorios atendidos Territorio ausente que el usuario no puede justificar
Campo de texto con sugerencias Escritura libre que no se resuelve a un valor válido

La prueba cambia según la forma. En una lista simple hay que comprobar el orden y la navegación; en un campo con sugerencias hay que comprobar qué pasa cuando el texto no coincide con nada. Aplicar el mismo guion a las cinco formas deja sin cubrir las partes específicas de cada una.

Un caso que se olvida siempre es el de la lista limitada: cuando el catálogo del formulario no coincide con el catálogo del sistema, aparecen registros con valores que la interfaz ya no ofrece y no se pueden corregir desde ella.

Qué variantes de escritura debe reconocer la búsqueda

La búsqueda debe encontrar el mismo territorio escrito de varias maneras, porque las personas escriben lo que aprendieron y no lo que dice el catálogo.

  • El nombre en la lengua local del territorio.
  • El nombre en el idioma de la interfaz, si difiere.
  • El código corto de dos letras, en mayúsculas o minúsculas.
  • Una forma abreviada de uso corriente.
  • Un nombre antiguo que todavía circula.

Si solo responde a una de estas formas, la búsqueda funciona en las pruebas y falla con usuarios reales. Merece la pena decidir explícitamente qué se hace con las variantes reconocidas: se puede mostrar el resultado con el nombre canónico y aceptar la variante como entrada, sin cambiar lo que se guarda.

Otro punto que suele faltar es el comportamiento con varios resultados. Cuando el texto coincide parcialmente con varios territorios, la lista debe ordenar por relevancia de forma previsible y no por el orden interno de la estructura de datos.

Por qué el orden alfabético tiene que seguir las reglas del idioma

Porque el orden por puntos de código no es el orden que espera quien lee. Las lenguas tienen reglas propias para colocar letras con acentos, dígrafos y caracteres que en el alfabeto latino básico no existen o van en otro sitio.

Cuando el orden se calcula de forma ingenua, los nombres acentuados caen al final de la lista y los caracteres de otros alfabetos aparecen agrupados en un bloque sin sentido. El usuario no encuentra nada y la única explicación visible es que el catálogo «está mal ordenado».

La solución es ordenar con las reglas de la lengua de la interfaz y no con una comparación directa de cadenas. Eso implica que el orden cambia con el idioma, y está bien: lo que se ordena es la presentación, no el dato guardado.

¿Cómo se prueban el teclado y el lector de pantalla?

Se prueban sin ratón y sin mirar, que es lo que hace quien depende de ellos.

Con el teclado hay que comprobar que el control se puede abrir, recorrer y cerrar solo con teclas; que al escribir una letra la lista salta al primer territorio que empieza por ella; que las flechas mueven la selección de forma previsible; que la tecla de escape cierra sin cambiar el valor; y que al cerrar el foco vuelve al campo que lo abrió.

Con el lector de pantalla hay que comprobar que se anuncia la etiqueta del campo, que se anuncia cuántas opciones hay y cuál está seleccionada, y que los grupos por región se anuncian como tales y no como opciones sueltas.

En listas grandes conviene además comprobar que el número de elementos visibles está acotado y que los resultados filtrados se anuncian cuando cambian, porque si no la persona no sabe que la lista se ha reducido.

Qué campos hay que recalcular al cambiar de país

Cambiar el valor de este campo invalida datos que dependían del anterior, y el sistema debe decidir para cada uno si lo borra, lo recalcula o lo conserva marcándolo.

Los candidatos habituales son los que se derivan del territorio: la división administrativa, la ciudad de la lista sugerida y el código postal. Dejarlos con el valor anterior produce direcciones imposibles que pasan la validación porque cada campo por separado está bien formado.

La decisión debe ser explícita y estar escrita. Borrar todo sin avisar pierde trabajo legítimo; conservarlo todo produce mezclas silenciosas. Lo que mejor funciona suele ser limpiar lo que ya no aplica, conservar lo que sigue siendo válido y avisar de lo que se ha limpiado.

Notas para quien programa

  • Almacena el código como valor y el nombre como texto de presentación; nunca guardes el nombre como clave.
  • Construye el índice de búsqueda con las variantes y mantenlo en datos, no en condiciones escritas dentro del componente.
  • Ordena con las reglas de la lengua de la interfaz y vuelve a probar el orden cuando se añada una lengua nueva.
  • Haz que el grupo de resto sea siempre alcanzable y visible aunque esté plegado.
  • Limpia los campos derivados al cambiar el valor y deja rastro de lo que se limpió.
  • Prueba la lista con más elementos de los que caben en pantalla, no solo con una muestra corta.
  • Comprueba que el valor guardado sobrevive a un cambio de idioma de la interfaz.

Siguientes pasos

Abre el formulario de alta y recorrelo solo con el teclado; si en algún momento no sabes dónde está el foco, ya tienes un defecto real. Si vas a ampliar la cobertura, el directorio de países y regiones te sirve para comprobar qué territorios tienen página propia y cuáles conviene añadir al catálogo del campo. Y si el problema aparece al combinar este campo con otros, la guía sobre escenarios de dirección transfronteriza trata precisamente los casos en que varios territorios conviven en el mismo registro. Y si lo que falla es encontrar un territorio al escribir su nombre, la guía sobre coincidencia de nombres de países y alias explica cómo resolverlo.

Los ejemplos de esta página son sintéticos: los nombres, las variantes de escritura y las entradas de la lista se han redactado para describir el método de prueba. No son envíos reales ni el contenido real de ningún formulario en producción.

Seguir leyendo

Artículos sobre Formatos de dirección e identidad por país