Una batería de pruebas de formulario de facturación sirve para algo muy concreto: descubrir antes que el cliente qué combinaciones de datos rompen el alta de una factura. El problema es que casi todo el mundo prueba el camino feliz y deja fuera lo que de verdad falla, que son las combinaciones raras de datos correctos. Este artículo propone un mapa de casos, explica por qué los fallos se concentran siempre en los mismos sitios y sugiere cómo organizar la batería para que siga siendo útil cuando el producto crezca.
¿Qué casos debe cubrir una batería de pruebas?
La respuesta corta es: los que representan una decisión del sistema. No todos los datos posibles, sino las fronteras en las que el sistema cambia de comportamiento.
Ese criterio se traduce en seis familias de casos:
- Camino feliz. Datos completos y bien formados de un cliente del propio país. Es el caso que todo el mundo prueba y el que menos información aporta.
- Fronteras de longitud. El valor más corto y el más largo que debería aceptarse, y el primero que debería rechazarse en cada uno.
- Caracteres especiales. Acentos, eñes, diéresis, guiones, puntos, barras y espacios intermedios dentro de nombres y direcciones.
- Campos opcionales ausentes. Cada campo que puede faltar, ausente por separado y ausente en combinación con otro.
- Identificadores mal formados. Número de registro, de VAT y de identificación fiscal con un carácter cambiado o un dígito de control que no cuadra.
- Combinaciones incoherentes. Datos correctos por separado que no pueden ir juntos: un identificador de un país con una dirección de otro, o un tipo de empresa con campos que no le corresponden.
La sexta familia es la que más defectos descubre y la que casi nadie implementa, porque requiere que el sistema tenga una noción explícita de qué combinaciones son imposibles.
¿Por qué fallan los formularios de facturación?
Fallan por cuatro motivos que se repiten con independencia del producto.
El primero es la validación de forma demasiado estricta. Una expresión regular escrita pensando en un país concreto rechaza datos válidos de otro. El usuario no puede arreglarlo porque su dato es correcto.
El segundo es el almacenamiento numérico. Un número de registro o fiscal guardado como entero pierde ceros iniciales y prefijos alfabéticos. El fallo no aparece en el alta, aparece semanas después, cuando el dato tiene que coincidir con el documento original.
El tercero es la codificación de caracteres. Un nombre con acentos que se convierte mal en algún punto del recorrido llega a la factura deformado, y a veces la deformación solo se ve en el archivo que se envía a la administración.
El cuarto es la falta de un tercer estado. Cuando la comprobación contra un servicio externo falla, el sistema trata el fallo como un rechazo de los datos, y bloquea un alta que en realidad era correcta.
Ninguno de los cuatro es un error de programación en el sentido clásico. Son decisiones de diseño que solo se manifiestan con datos que no son los de la demostración.
¿Cómo se organiza la batería por capas?
Conviene separarla en tres niveles, de forma que un fallo se localice sin ambigüedad.
| Nivel | Qué prueba | Coste | Cuándo se ejecuta |
|---|---|---|---|
| Unidad | Funciones de normalización y de validación de forma | Muy bajo | En cada cambio |
| Integración | Guardado, lectura y generación del documento | Medio | En cada entrega |
| Extremo a extremo | Alta completa con cada familia de casos | Alto | Antes de publicar |
La ventaja de esta separación es que las familias de casos se convierten en datos de prueba que atraviesan los tres niveles. El mismo listado de identificadores raros alimenta la prueba unitaria del validador, la de integración del guardado y la de extremo a extremo del alta.
Dentro de cada nivel, un criterio de orden práctico: empieza por los casos que deberían rechazarse y sigue por los que deberían aceptarse. Los primeros son los que definen la frontera, y escribir primero los de aceptación tiende a producir pruebas que solo confirman lo que ya funciona.
Y una regla sobre los datos de prueba: que sean reconocibles como ficticios. Un nombre de ejemplo que parezca real acabará apareciendo en una captura de pantalla compartida con un cliente, y esa es una conversación que no quieres tener.
¿Qué revisar antes de dar por buena la batería?
Cinco comprobaciones que suelen faltar en la primera versión:
- Cada familia tiene al menos un caso de aceptación y uno de rechazo. Una familia solo con casos de rechazo no demuestra que el sistema acepte lo que debe.
- Los identificadores de prueba cubren varios países. Si todos son del mismo territorio, la validación por país no está probada.
- Hay un caso con identificador que no cuadra su dígito de control. Es la única forma de comprobar que la capa aritmética está activa.
- Hay un caso con el servicio externo caído. La respuesta debe ser no comprobado, no inválido.
- Hay un caso con los mismos datos en dos idiomas o dos alfabetos. Descubre problemas de codificación y de normalización.
La cuarta es la más olvidada y la que más incidencias produce en producción, porque el servicio externo falla de verdad y con cierta frecuencia.
En el generador de este sitio
En el generador de datos de empresa para pruebas cada ejecución devuelve una ficha completa de un país: nombre, forma jurídica, domicilio social, teléfono y los números de registro y de VAT. Eso permite alimentar las familias de casos sin escribir los datos a mano, y sobre todo permite generar muchos ejemplos distintos del mismo país para probar volúmenes.
Los datos son sintéticos y están construidos para reconocerse como ejemplos. No pertenecen a ninguna sociedad existente, no acreditan nada ante terceros y sirven únicamente para pruebas de software, demostraciones y entornos de desarrollo.
Para quien programa
Una batería de facturación solo sobrevive si es barata de mantener. Seis decisiones que ayudan:
- Datos de prueba en un archivo de datos, no dentro del código. Cada familia como una lista de casos con nombre, entrada esperada y resultado esperado.
- Nombres de caso que expliquen la intención. Un caso llamado con el identificador completo no dice nada; uno que diga qué frontera prueba, sí.
- Un caso, un motivo de fallo. Si un caso puede fallar por tres razones distintas, sepáralo en tres.
- Sin dependencia de la red en las pruebas unitarias. La consulta al registro se sustituye por un doble de prueba que devuelva cada uno de los tres estados.
- Reproducibilidad de las fechas. Si algo depende de la fecha de consulta, fija la fecha en la prueba en lugar de usar la del sistema.
- Cobertura por familia, no por línea. Es más útil saber que falta la familia de caracteres especiales que ver un porcentaje global alto.
Una nota sobre los entornos: prueba también el camino de la exportación y del envío del documento, no solo el del alta en pantalla. Los defectos de codificación y de formato numérico suelen aparecer justo ahí, en el paso en que el dato sale del sistema.
Siguientes pasos
Si necesitas datos para alimentar los casos, el generador de datos de empresa devuelve fichas completas por país en cada ejecución. Para construir los casos de rechazo con criterio, las guías del número de registro de empresa y de validación del número de identificación fiscal explican qué se puede comprobar de cada identificador. Y si lo que estás preparando es la validación de clientes empresariales, la lista de comprobación de KYB ayuda a decidir qué documentación pedir en cada caso.