Desarrollo orientado a pruebas de aceptación (ATDD)

De forma análoga al desarrollo basado en pruebas, el desarrollo basado en pruebas de aceptación (Acceptance Test Driven Development, ATDD) involucra a miembros del equipo con diferentes perspectivas (cliente, desarrollo, pruebas) que colaboran en la redacción de pruebas de aceptación antes de implementar la funcionalidad correspondiente.

Las discusiones colaborativas que se producen para generar la prueba de aceptación a menudo se denominan los tres amigos, representando las tres perspectivas del cliente (¿qué problema estamos tratando de resolver?), el desarrollo (¿cómo podríamos resolver este problema?), y las pruebas (¿qué pasa con….).

Estas pruebas de aceptación representan el punto de vista del usuario y actúan como una forma de requisitos para describir cómo funcionará el sistema, así como para verificar que el sistema funciona según lo previsto. En algunos casos, el equipo automatiza las pruebas de aceptación.

También conocido como

ATDD también puede ser referido como Desarrollo Impulsado por Pruebas de Historias (SDD), Especificación por Ejemplo o Desarrollo Impulsado por Comportamiento (BDD). Estos diferentes términos existen para enfatizar algunas diferencias en el enfoque que conducen a resultados similares.

Beneficios Esperados

Del mismo modo que la DDT da lugar a aplicaciones diseñadas para facilitar las pruebas unitarias, la ATDD favorece la creación de interfaces específicas para las pruebas funcionales. (Las pruebas a través de la interfaz de usuario real de una aplicación se consideran menos efectivas.

Obstáculos comunes

Incluso más que el uso de pruebas de aceptación automatizadas, esta práctica está fuertemente asociada con el uso de herramientas específicas como Fit/FitNess, cucumber u otras.

Por lo tanto, uno de los principales riesgos es que la herramienta elegida dificulte, en lugar de hacer avanzar, el objetivo principal de esta práctica: facilitar la conversación entre los desarrolladores y los propietarios de los productos sobre los requisitos de los mismos. Las herramientas deben adaptarse para satisfacer las necesidades de los propietarios de los productos y no al revés.

Orígenes

  • 2003: Kent Beck briefly mentions ATDD in the book “Test Driven Development: By Example” but dismisses it as impractical
  • 2003 to 2004: driven by the popularity of Fit/FitNesse ATDD becomes accepted practice in spite of Beck’s objections

Deja un comentario

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar