El problema con las matrices de prueba en proyectos ERP no es que sean largas. Es que están escritas para quien las hace, no para quien debe aprobarlas. Y esa diferencia cuesta retrabajo.
Por qué no leen la matriz
En la mayoría de los proyectos ERP, la matriz de pruebas llega al cliente como un Excel de 400 filas sin contexto, con columnas que solo tienen sentido para quien las armó. El cliente la abre, hojea las primeras pestañas y la firma. No porque esté conforme — sino porque no sabe qué hacer con ella.
El resultado es predecible: el go-live ocurre con casos sin ejecutar, defectos sin registrar formalmente y, cuando algo falla en producción, nadie puede señalar en qué punto del proceso de pruebas se debió haber detectado. La trazabilidad desaparece exactamente cuando más se necesita.
Los patrones que se repiten con más frecuencia:
Estructura mínima
ID del caso
Referencia única trazable al requerimiento o elemento de DevOps que origina el caso.
Módulo + responsable
Quién ejecuta y quién valida. Sin ambigüedad entre integrador y cliente.
Precondición
Estado exacto del sistema antes de ejecutar. Incluye datos de prueba específicos.
Pasos de ejecución
Acciones numeradas, sin saltos de lógica. Reproducibles por cualquier miembro del equipo.
Resultado esperado
Verificable sin interpretación: campos, estados, montos, mensajes exactos.
Checklist antes de la sesión
- Datos de prueba configurados en el ambiente correcto
- Responsable asignado a cada caso
- Resultados esperados con valores numéricos donde aplica
- Casos de error (flujo negativo) incluidos, no solo flujo feliz
- Criterio de aceptación del módulo acordado con el cliente
- Canal de registro de evidencia definido (capturas, exportación CSV)
La anatomía de un caso que funciona
Un caso de prueba útil tiene tres componentes que no son negociables: una precondición que establece el punto de partida exacto, pasos de ejecución que cualquier persona del equipo puede seguir sin interpretación, y un resultado esperado que define con precisión qué debe ocurrir — no cómo debería sentirse.
La diferencia entre un resultado esperado vago y uno verificable no es de extensión, es de especificidad:
✗ Vago
El segundo resultado esperado puede ser verificado por el cliente sin ayuda del integrador. El primero requiere que alguien interprete si “correctamente” se cumplió. En una sesión de pruebas bajo presión de tiempo, esa diferencia decide si el caso se registra como pasado o como pendiente de aclaración.
Un ejemplo de estructura completa, aplicado a un módulo de facturación en campo:
El detalle que más falla en campo: los datos de prueba
El caso puede estar perfectamente redactado y fallar igual en la sesión de pruebas — porque nadie preparó los datos. Este es el punto donde más tiempo se pierde en campo: el ejecutor llega, no tiene el cliente de prueba configurado, improvisa con un registro productivo y el resultado no es reproducible ni comparable con el caso documentado.
Los datos de prueba no son un apéndice de la matriz. Son parte del caso. Y deben estar resueltos antes de la sesión, no durante.
- Especificar identificadores exactos, no categorías
Cliente 1005948, Ruta 0044, UDN 1408. El ejecutor no debe tomar decisiones sobre qué datos usar.- Distinguir ambientes: desarrollo, QA, producción
- Documentar montos esperados, no solo flujos
343,854.48, no “el monto correcto”. Eso convierte la verificación en algo objetivo.- Señalar qué datos deben prepararse con anticipación
Conclusión — qué debe mejorar a partir de aquí
Adoptar estas buenas prácticas no requiere una transformación de proceso ni una herramienta nueva. Requiere disciplina al redactar y rigor al revisar. Cinco frentes concretos donde se nota la diferencia desde la primera matriz:
Incluir casos de error con la misma jerarquía que los casos felices
El flujo negativo — qué pasa si el monto es insuficiente, si el cliente no existe, si la red se cae a mitad de la transacción — debe estar documentado con la misma especificidad que el flujo principal. La mayoría de los defectos detectados en producción provienen de escenarios negativos que nunca se incluyeron en la matriz original.
