¿Cómo preparar una prueba de aceptación de automatización?

Decir que funciona exige un criterio común

Una automatización lee archivos y crea una tabla de presupuestos. El desarrollador ve un resultado y considera terminado el trabajo; la empresa detecta filas ausentes. Evalúan de manera distinta la misma salida porque no acordaron antes los criterios de aceptación. La prueba define de forma compartida y comprobable qué entradas deben generar qué salidas. La conversación sobre la entrega deja así de depender solo de impresiones.

Empiece durante el diseño del proceso, no cuando el programa esté terminado. Prepare con el responsable un pequeño conjunto de ejemplos y explique manualmente el resultado correcto. Especifique qué campos intervienen en el cálculo, cuándo se omite un registro y qué operaciones requieren aprobación humana. El desarrollador debe utilizar los mismos ejemplos. Así será más claro si un caso nuevo amplía el alcance o incumple una regla existente.

Seleccione datos representativos

Probar solo registros correctos es fácil, pero el trabajo cotidiano incluye problemas. Añada campos vacíos, duplicados, fechas incorrectas, caracteres inesperados y clientes distintos con el mismo nombre. Explique por qué se eligió cada ejemplo. No lleve datos personales reales al entorno de pruebas sin necesidad. Al crear datos representativos, respete longitudes y formatos del sistema real para reproducir condiciones que encontrará la aplicación.

El número de filas no basta para demostrar exactitud. Compruebe la correspondencia de campos, el cálculo de totales y dónde se guardan los registros inválidos. Debe verse por qué se omite un registro. Ejecutar otra vez el proceso no debe crear duplicados. Puede compartir algunos ejemplos con el desarrollador y reservar otros para la entrega, pero todas las expectativas deben derivar de reglas de negocio explícitas.

Escriba el resultado esperado

Cada fila de prueba debe contener escenario, entrada, operación, salida esperada y resultado observado. Por ejemplo, un registro sin código de producto podría enviarse a revisión en lugar de producir un presupuesto. Incluya el significado del mensaje de error esperado. El usuario debe entender qué campo corregir. Impedir una operación incorrecta forma parte de la aceptación tanto como generar el archivo adecuado.

No emplee términos ambiguos sobre redondeo, fechas o comparación de textos. Muestre mediante un ejemplo la regla aceptada por el responsable. No se puede interpretar el resultado sin aclarar la fuente del precio o el tratamiento de monedas distintas. Si el programa debe detenerse o consultar a una persona autorizada cuando no puede decidir, pruebe ese comportamiento por separado. Continuar suponiendo no resulta apropiado para todos los procesos.

Incluya errores e interrupciones

Describa qué ocurre si falta un archivo, se corta la red o no responde un servicio externo. Si el proceso queda a medias, ¿reiniciarlo daña los registros anteriores? ¿Ve el usuario el error? ¿El registro de actividad indica qué terminó? Estas preguntas comprueban que la empresa conserve el control, además del recorrido exitoso. Simule interrupciones en un entorno que no genere operaciones reales.

Concrete también la recuperación. Ante una salida incorrecta, ¿se conservan los datos originales, puede archivarse el resultado anterior y qué pasos se pueden deshacer? Considere una aprobación humana o un control separado antes de automatizar una operación irreversible. Identifique claramente los registros de prueba como ejemplos. Enviar avisos a clientes reales o iniciar pagos reales no es un atajo apropiado para comprobar la aceptación.

Pruebe permisos y recorrido del usuario

Una prueba realizada solo con una cuenta administradora puede ocultar problemas de usuarios normales. Compruebe pantallas y operaciones con los roles correspondientes. El usuario sin autorización no solo debe dejar de ver el botón: debe ser incapaz de ejecutar la acción. Indique el rol utilizado en el informe. Sin esa información, no puede suponerse que un resultado satisfactorio se repita para otros empleados.

Recorra todos los pasos: seleccionar datos, comprobarlos, ejecutar, consultar el resultado y resolver excepciones. Si otra aplicación utilizará la salida, incluya su transferencia. Crear el archivo puede ser insuficiente. ¿Puede el responsable usarlo en su trabajo y reconocer un resultado incorrecto? Defina el flujo de automatización alrededor de esos puntos de entrega.

Convierta el informe en un documento de decisión

Separe escenarios superados, fallidos y no ejecutados. Para cada problema pendiente, describa impacto, solución provisional y condición para repetir la prueba. No cuente casos sin resolver como éxitos. El responsable debe disponer de información suficiente para aceptar la entrega o solicitar cambios. Registrar versión, fecha y datos utilizados permite identificar las pruebas necesarias en una nueva versión.

Tras la primera aceptación, no todo cambio pequeño exige probar de nuevo el sistema completo. Repita las pruebas relacionadas con la regla modificada y el flujo principal. Un resultado anterior no demuestra la nueva versión. En trabajos de datos, considere la transferencia masiva junto con la comparación de registros. Un conjunto pequeño, claro y repetible puede convertirse en control de cambios para la empresa.

Atención: demostrar no equivale a aceptar

Un vídeo preparado que muestra un recorrido correcto no sustituye una prueba real. Esta debe poder repetirse con versión y datos determinados. Si se exige rendimiento, explique entorno y método de medición; no prometa tiempos ni porcentajes de éxito sin verificar. El objetivo es mostrar los límites de la entrega y registrar el comportamiento aceptado, no afirmar perfección.

Al terminar, conserve juntos el ejemplo utilizado y la decisión adoptada. La siguiente persona debe entender por qué se eligió ese camino. Aclare las dudas con el responsable en lugar de ocultarlas. Una pequeña prueba práctica puede aportar más que un documento aparentemente completo que nadie usa. Mejórela mediante comentarios periódicos.

Preguntas frecuentes

¿Cuál es el primer paso?

Elija una tarea real y un ejemplo representativo y describa el resultado esperado.

¿Quién debe comprobarla?

La persona responsable del proceso y quien utiliza la aplicación deben revisarla conjuntamente.

¿Cuándo debe actualizarse?

Revise los pasos afectados cada vez que cambie el proceso o la aplicación.