Uno de los conceptos de agilidad que más impacto pueden tener en los proyectos que participas, son las pruebas de aceptación, y por eso es el primero que destaco en este blog.

Las pruebas de aceptación (Acceptance Tests), como su nombre lo insinúa, son verificaciones que se realizan sobre las funcionalidades de la aplicación o producto en desarrollo. La importancia de estas pruebas son que una vez concluidas con éxito, dan por aceptada la funcionalidad. Hasta ahí nada nuevo respecto de los procesos normales de QA, ¿cierto?.

Bueno, hay una pequeña diferencia. Generalmente QA es un área interna del proveedor de software, y por lo tanto que apruebe un desarrollo, no significa que el cliente haya quedado satisfecho. Con las pruebas de aceptación queremos solucionar eso. Para que todo funcione de la manera en que debiera, deben pasar las siguientes cosas:

• Las pruebas de aceptación se escriben junto a la definición de la funcionalidad, con desarrolladores, cliente y usuarios participando.
• Se le informa y recuerda al cliente, que estas pruebas definen su aceptación, es decir, son “el contrato” (y pueden ser forzadas como contractuales si se requiriera, pero ojo, colaboración por sobre negociación contractual…).
• Las pruebas se automatizan al mayor nivel posible para que podamos enfocarnos en desarrollar las funcionalidades y para que tengamos resultados confiables.

Generalmente este es un proceso tedioso, de reunirse con el cliente, explicarle porqué esto es importante y porqué él debe estar presente, lo mismo con los usuarios, especialmente cuando tratamos con clientes poco acostumbrados al desarrollo de software profesional (solo han tratado con cowboys que preguntan que hay que hacer y dos meses después llegan de vuelta con cualquier cosa. Yo he sido de esos), pero esto se realiza iterativamente, a medida que las tareas del backlog ingresan a la cola de trabajo, de lo contrario sería un desperdicio enorme ocupar dos días o una semana definiendo a cabalidad cada uno de los requerimientos, para que tres meses después cuando toque implementarlos, ya todo sea diferente y haya que hacerlo de nuevo.

La forma de una prueba de aceptación, cuando se redacta, es generalmente un texto que indica varias líneas del tipo “dadas ciertas condiciones, este debe ser el resultado”. Cuando las funcionalidades son definidas por historias de usuario, las pruebas de aceptación son los escenarios; cuando utilizamos casos de uso para un análisis más profundo, podemos usar los escenarios de los casos de usos como pruebas de aceptación.

Tanto las historias de usuario como los casos de uso recalcan esto, pero no está demás repetir que las condiciones de un escenario tienen que ser claras y determinantes (una acción del usuario, un evento del sistema, etc) y los resultados deben ser medibles. En caso de tener un resultado variable, por ejemplo un cálculo utilizando una formula matemática, esta puede dar varios resultados dependiendo de sus entradas, se puede hacer una tabla de entradas -> resultado, que indique resultados esperados para casos de borde y casos normales, así como también se deben definir los casos de error y como será notificado tanto el usuario como el personal de operaciones.

Todo esto pavimenta el camino para que las pruebas sean automatizadas. Un script puede leer estas especificaciones, ingresar los inputs hacia el sistema y luego verificar los resultados versus los resultados esperados. Hay varias herramientas para hacer esto y con el tiempo haré posts de algunos de ellos para que se vallan familiarizando.

Si se dan cuenta, aun sin automatización, las pruebas de aceptación son de un gran valor, porque redactan el acuerdo del cliente con el equipo de desarrollo, permitiendo al equipo desarrollar con un claro horizonte y pudiendo verificar su desarrollo versus las pruebas cada vez que sea necesario. También podemos dar tranquilamente por “hecho” una tarea cuando pase todas las pruebas. Si el cliente aun tiene reparos: se pueden tratar como cambios y debido que estamos en un proceso iterativo, no hay problema; los cambios son el día a día en nuestro que hacer.