ATDD (Acceptance Test Driven Development)
INTRODUCCIÓN
En TDD las pruebas unitarias son definidas por el programador y no están necesariamente relacionadas con los requisitos. Existen dos enfoques cercanos que también han llevado la filosofía de TDD al terreno de los requisitos, estos son Acceptance Test Driven Development (ATDD) y Behaviour Driven Development (BDD), nosotros nos centraremos en ATDD.
ATDD es una evolución de TDD, orientada a resolver la falta de comunicación con el cliente y abordar adecuadamente los cambios que pueda introducir a lo largo del proceso de desarrollo. En ATDD el proceso de desarrollo está dirigido por las pruebas de aceptación, las cuales deberían ser escritas por el cliente con la ayuda de un desarrollador. Podríamos decir que las pruebas de aceptación proporcionan al cliente un contrato legible y ejecutable que el programador tiene que cumplir, y son usadas como documentación en un entorno ágil, dejando de ser únicamente un artefacto de pruebas como se utiliza en TDD. Para la mayoría de profesionales, un requisito en ATDD es una historia de usuario, especificada con una breve descripción narrativa y a la cual se le asocia un conjunto de pruebas de aceptación, escritas normalmente en lenguaje natural.
CARACTERÍSTICAS
El ATDD ayuda a coordinar los proyectos de software de manera que entregaremos lo que el cliente desea. Según Koskela, una buena prueba de aceptación debe ser:
- Propiedad de los clientes.
- Escrito en conjunto con los clientes, desarrolladores y analistas de prueba.
- Sobre el Qué y no sobre el Cómo.
- Expresada en lenguaje de dominio del problema.
- Conciso, preciso y sin ambigüedades.
PASOS A SEGUIR
Hasta aquí hemos descrito una prueba de aceptación que podría simplemente estar dentro de un documento Word o una plantilla Excel. Entonces, ¿cuál es la diferencia de la prueba de aceptación tradicional para la prueba de aceptación "clásica"? En primer lugar es que en ATDD la prueba debe ser automatizada. Este es un punto esencial para realizar las pruebas regresivas continuas. En segundo lugar, las pruebas de aceptación son escritas antes de la funcionalidad. Pero, ¿cómo? siguiendo los pasos a continuación:
- Tome una historia o flujo de caso de uso.
- Escriba las pruebas de aceptación en el lenguaje de dominio del cliente.
- Automatice las pruebas de aceptación.
- Implemente la funcionalidad.
HERRAMIENTAS
Existen actualmente en el mercado una enorme cantidad de herramientas para realizar las Pruebas de Aceptación:
- Canoo
- Concordion
- FitNesse
- JBehave
- JMeter
- Sahi
- Selenium
- SoapUI
- Watir
- easyb
CONCLUSIÓN
ATDD está orientado a la automatización de pruebas y generación de código.
En ATDD las pruebas se automatizan inmediatamente al ser identificadas, no existe separación temporal en cuanto a la especificación de la prueba y su correspondiente implementación.
Nuestro enfoque no obliga a instanciar las pruebas cuando se definen los requisitos ya que dejará en manos de los testers el determinar las mejores combinaciones de datos y el decidir si es conveniente la automatización de la prueba dentro de la misma iteración en la cual se incorpora el cambio asociado a la prueba.
Finalmente, el enfoque ATDD no aborda la problemática de gestionar la gran cantidad de pruebas que se generan. Es esencial disponer de mecanismos para manipular de forma ágil las PAs, particularmente en un contexto de mantenimiento continuo de un producto.
ATDD siempre vendrá acompañada de alguna metodología ágil, pienso que nos quedaremos cortos si solo apostamos por ATDD de forma aislada.
REFERENCIAS UTILIZADAS
PREGUNTAS:
1. Las pruebas de aceptación proporcionan al cliente:
a) Un contrato legible y ejecutable que el programador tiene que cumplir.
b b) La seguridad de que no ocurran errores.
c c) Unas bases para saber la capacidad del programador.
) d) La garantía de que el proyecto durara el tiempo estipulado.
2 2. ¿Porque es necesario instanciar las pruebas de aceptación?
a a) Porque el cliente tiene que guiar cada prueba de aceptación.
b b) Porque así se pueden verificar los errores en cada prueba.
c c) Porque así los grupos de programadores trabajan con más comunicación con el cliente.
d d) Porque no existe separación temporal en cuanto a la especificación de la prueba y su correspondiente implementación.
3 3. ¿Qué filosofía sigue ATDD?
a a) XP.
b b) RUP.
c c) TDD.
d d) BDD.
4 4. En ATDD, ¿Cómo realiza el cliente las pruebas de aceptación?
a a) Con un lenguaje de programación (C#, Java, etc.).
b b) En lenguaje natural.
c c) Mediante diagramas, utilizando UML.
d d) Ninguna de las anteriores.
5 5. ATDD está orientada a…
a a) La generación de código y su posterior análisis y depuración.
b b) La comunicación constante de cliente-desarrollador para omitir pruebas innecesarias.
c c) La automatización de pruebas y generación de código.
d d) Ninguna de las anteriores.
6 6. En Acceptance Test Driven Development (ATDD):
a a) Se intenta reducir el código innecesario generado.
b b) Se dan pluses a aquellos desarrolladores que más comunicación tengan con el cliente.
c c) Se generan gran cantidad de documentos técnicos para realizar las pruebas.
d d) Ninguna de las anteriores.
7 7. ¿Cuál de las siguientes herramientas puede servir en ATDD?
a a) FitNesse.
b b) Selenium.
c c) Concordion.
d d) Todas las anteriores son correctas.
8 8. En ATDD, ¿cómo debe ser una buena prueba de aceptación?
a a) Desarrollada por los programadores y revisada por los clientes.
b b) Escrita en conjunto con los clientes, desarrolladores y analistas de prueba.
c c)Escrita en lenguaje de programación por los clientes para que los programadores la entiendan de una forma más rápida.
d d) Ha de ser larga y muy bien detallada, para que no se escape ningún tipo de requisito.
No hay comentarios:
Publicar un comentario