Buenas Prácticas para Pruebas con Documentos Brasileños
Probar sistemas que aceptan documentos brasileños exige atención a reglas algorítmicas, casos límite y conformidad legal. Esta guía reúne las mejores prácticas para equipos de QA y desarrolladores.
Entienda los documentos que su sistema acepta
El primer paso para probar correctamente es entender la estructura de cada documento aceptado por el sistema. CPF y CNPJ tienen dígitos verificadores calculados por módulo 11. CNH tiene un dígito verificador propio. RENAVAM usa módulo 11 con pesos específicos. Tarjeta de crédito usa el algoritmo de Luhn (módulo 10).
Para cada tipo de documento, documente: (1) formato esperado con y sin máscara; (2) tamaño en dígitos; (3) reglas de dígitos verificadores; (4) casos conocidos de invalidez; (5) variaciones regionales cuando aplique.
Cubriendo los casos límite más importantes
Los casos límite para validación de documentos son predecibles: (1) Documento vacío o nulo. (2) Largo incorrecto. (3) Caracteres no numéricos. (4) Dígitos verificadores incorrectos. (5) Secuencias inválidas por definición. (6) Máscaras — ¿el sistema acepta ambos formatos?
(7) Documentos de estados específicos. (8) Valor en el límite. (9) SQL injection y XSS — los campos de documento son un vector de ataque común; valide que inputs maliciosos sean tratados correctamente.
Estructurando pruebas automatizadas eficientes
En frameworks como Cypress, Playwright o Selenium, organice las pruebas de documentos en tres categorías: pruebas de validación de campo (unitarias), pruebas de flujo con datos válidos (integración) y pruebas de flujo con datos inválidos (negativas).
Parametrice sus pruebas con múltiples documentos válidos para aumentar la cobertura sin multiplicar el código. Una única prueba parametrizada con 10 CPFs válidos diferentes cubre mucho más que 10 pruebas idénticas.
Gestión de datos de prueba y ambientes
Separe los datos de prueba por ambiente: desarrollo, QA, homologación y producción deben tener conjuntos de datos distintos. En desarrollo y QA, use exclusivamente datos ficticios. Nunca use datos reales de producción en ambientes de no-producción.
Versione sus datos de prueba junto con el código en el repositorio. Un archivo seeds.json o fixtures/documents.json con CPFs, CNPJs y otros datos ficticios válidos garantiza que todos en el equipo usen los mismos datos.
Errores comunes y cómo evitarlos
Los errores más frecuentes: (1) Usar CPFs famosos de internet. (2) No probar la máscara. (3) Ignorar la validación en el backend — siempre valide en el servidor.
(4) Reutilizar el mismo CPF en muchas pruebas. (5) No actualizar datos de prueba después de cambios en las reglas — el CNPJ alfanumérico es un buen ejemplo. Mantenga un proceso para revisar y actualizar los datos de prueba periódicamente.