¿Quién escribe los casos de prueba para su cliente cuando llega el momento de las Pruebas de aceptación del cliente?

La prueba de aceptación del cliente (o usuario) (CAT o UAT) es una fase crítica de los proyectos de implementación del sistema y debe estar bien planificada, estructurada y documentada.

Acerca de los casos de prueba (o scripts de prueba):

• Los casos de prueba son instrucciones detalladas paso a paso que permiten validar cómo funciona la funcionalidad desde la perspectiva del usuario final .
• Deben cubrir todos los requisitos de los usuarios en el ámbito del proyecto, así como los procesos de negocio soportados por el sistema.
• La mejor manera de escribir un caso de prueba es basarlo en un proceso comercial (p. ej., realizar un pedido) y validar los requisitos relacionados como parte de la ejecución de ese proceso (p. ej., modificar la especificación del producto como parte del pedido).

Quién debe escribir casos de prueba:

• Los casos de prueba deben ser escritos por miembros del equipo del proyecto que tengan un buen dominio de las funcionalidades del sistema, así como de los procesos comerciales del cliente . Entonces, dependiendo de la estructura de su equipo de proyecto, podría ser un analista comercial o un líder funcional (o incluso un desarrollador en proyectos pequeños, aunque eso es menos común). En implementaciones de sistemas grandes, hay equipos de prueba dedicados que tienen la tarea de redactar los scripts, así como de preparar y administrar los ciclos de prueba.
• Por lo general, no es el cliente o el usuario final quien escribe los scripts de prueba, a menos que el cliente haya asignado recursos al proyecto para hacerlo. En cualquier caso, para mantener la integridad del proceso de prueba, la persona que escribe el caso de prueba no debe ser la persona que ejecuta la prueba .

Recomendaciones adicionales:

• No deje que su cliente se pierda : le aconsejo encarecidamente que no acepte una prueba de "haga lo que quiera". Aunque esto se debe a una buena intención (dar libertad al cliente), es probable que lo lleve a una situación problemática: no solo el sistema no se probará a fondo, sino que probablemente verá que su cliente plantea problemas y preguntas que no son válidas. (por ejemplo, "esto no funciona" porque el cliente no sabe cómo usarlo, o "esto no hace X" porque no era un requisito en primer lugar).
• Realice siempre pruebas de regresión : cuando implementa un nuevo sistema o realiza una actualización significativa, debe probar toda la aplicación. Sin embargo, para pequeñas mejoras, no es necesario poner la misma cantidad de esfuerzo en las pruebas. Debe probar las funcionalidades nuevas/modificadas (ya sea a través de nuevos casos de prueba o casos de prueba actualizados existentes) y también probar funcionalidades críticas "regulares" para garantizar que las mejoras no hayan afectado la utilización normal del sistema. Por lo tanto, es una buena idea identificar entre sus scripts de prueba un conjunto de casos de prueba críticos que puede usar en el futuro para sus pruebas de regresión.
• Optimice el esfuerzo de sus casos de prueba: Los casos de prueba pueden tomar algún tiempo para escribir dependiendo de la complejidad y el alcance de las funcionalidades desarrolladas. Sin embargo, dado que están diseñados para validar cómo usar el sistema, también pueden usarse como base para desarrollar materiales de capacitación (particularmente si están escritos en base a procesos comerciales). Así que esta es una forma de aprovechar el esfuerzo que se dedica a los scripts de prueba para otra área de la implementación de su sistema.