La idea de automatizar las pruebas de usuario es una práctica que se origina con XP (Extreme Programming), específicamente como una práctica de TDD (Test-Development Driven).
En lugar de que el usuario de negocio pase los requerimientos al equipo de desarrollo sin mayor oportunidad de retro alimentar al equipo, el desarrollador y el usuario colaboran para escribir las pruebas automatizadas que expresen lo que el usuario de negocio requiere. Esto es denominado pruebas de aceptación, pues expresan lo que el software necesita realizar de forma que el usuario de negocio acepte dicha funcionalidad. El test inicialmente falla al ser escrito, pues no hay código relacionado, pero captura lo que el usuario de negocio necesita y proporciona información clara de lo que significa HECHO para este.
Estas pruebas son diferentes a las pruebas unitarias, que están destinadas a los programadores y ayudan a comprobar el diseño de software. De esta forma las pruebas unitarias aseguran que usted construye las cosas en forma correcta, mientras que las pruebas de aceptación aseguran que usted está construyendo correctamente lo que se necesita.
La automatización de pruebas de aceptación ha sido establecido como una práctica de XP por muchos años, pero muchos equipos que implementan XP y que tienen menos experiencia, ven a TDD como una práctica sólo de los programadores. Pero tal como se indica en el libro “Agile Testing: A practical Guide for Testers and Agile Teams”, sin la participación del usuario de negocio en las pruebas de aceptación, es difícil para los programadores saber que pruebas ellos necesitan escribir. Las pruebas de aceptación ayudan al equipo a enfocarse, asegurando que el trabajo realizado en cada iteración presenta el mayor valor posible a ser entregado. Igualmente se pueden cometer errores, pero de esta forma se minimizan los errores.
