Este documento habla sobre la validación de desarrollos en Dynamics NAV y Business Central. Explica que la validación tradicional se basa en si compila o sigue el DDT, mientras que una validación más completa usa casos de prueba automatizados. Estos casos de prueba tienen beneficios como minimizar errores, permitir validaciones repetibles y satisfacer metodologías ágiles. También cubre tipos de errores como los del estándar, desarrollos aislados y errores entre sistemas.

1. José Ángel López
Aguilar
• Validación en
Dynamics NAV y BC

3. About the Speaker
• José Ángel López Aguilar
• Dynamics NAV / Business Central
Technical Leader en CDART
• 12 años trabajando con NAV, en cliente
final y posteriormente en partners.
• www.linkedin.com/in/josé-ángel-
lópez-aguilar-688a0b1b
• jalopez@quonext.com

4. Validación de desarrollos en
Dynamics NAV y Business Central
• Agenda

5. Validación de desarrollos en
Dynamics NAV y Business Central
• Agenda
• ¿Qué significa validación?
• Beneficios de usar casos de prueba y automated testing.
• Tipos de errores y tipos de test asociados.
• TDD. Test Driven Development.

6. ¿Cómo se valida un desarrollo?

7. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico ->

8. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico -> “Compila”.

9. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico -> “Compila”.
- Para el responsable técnico ->

10. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico -> “Compila”.
- Para el responsable técnico -> “Compila y sigue el DDT”.

11. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico -> “Compila”.
- Para el responsable técnico -> “Compila y sigue el DDT”.
- Para el consultor/jefe de proyecto ->

12. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico -> “Compila”.
- Para el responsable técnico -> “Compila y sigue el DDT”.
- Para el consultor/jefe de proyecto -> “Hace lo que creo
que el cliente necesita”

13. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico -> “Compila”.
- Para el responsable técnico -> “Compila y sigue el DDT”.
- Para el consultor/jefe de proyecto -> “Hace lo que creo
que el cliente necesita”.
- Para el cliente ->

14. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico -> “Compila”.
- Para el responsable técnico -> “Compila y sigue el DDT”.
- Para el consultor/jefe de proyecto -> “Hace lo que creo
que el cliente necesita”.
- Para el cliente -> “Hace lo que creo que necesito”.

15. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico -> “Compila”.
- Para el responsable técnico -> “Compila y sigue el DDT”.
- Para el consultor/jefe de proyecto -> “Hace lo que creo
que el cliente necesita”.
- Para el cliente -> “Hace lo que (hoy) creo que necesito”.

16. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico -> “Compila”.
- Para el responsable técnico -> “Compila y sigue el DDT”.
- Para el consultor/jefe de proyecto -> “Hace lo que creo
que el cliente necesita”.
- Para el cliente -> “Hace lo que (hoy) creo que necesito”.
- Para gerencia/administración ->

17. ¿Cómo se valida un desarrollo?
Tradicionalmente (visión pesimista):
- Para un técnico -> “Compila”.
- Para el responsable técnico -> “Compila y sigue el DDT”.
- Para el consultor/jefe de proyecto -> “Hace lo que creo
que el cliente necesita”.
- Para el cliente -> “Hace lo que (hoy) creo que necesito”.
- Para gerencia/administración -> “Hemos cobrado”.

18. Casos de prueba

19. Casos de prueba
- Si son consensuados con cliente, “garantiza” objetivos.

20. Casos de prueba
- Si son consensuados con cliente, “garantiza” objetivos.
- Dpto. técnico puede hacer validaciones más completas.

21. Casos de prueba
- Si son consensuados con cliente, “garantiza” objetivos.
- Dpto. técnico puede hacer validaciones más completas.
- Repetibles, nos sirven para revalidar pasado el tiempo.

22. Casos de prueba
- Si son consensuados con cliente, “garantiza” objetivos.
- Dpto. técnico puede hacer validaciones más completas.
- Repetibles, nos sirven para revalidar pasado el tiempo.
- Nos pueden servir para guiar el desarrollo (TDD).

23. Casos de prueba + Automated testing
Beneficios:

24. Casos de prueba + Automated testing
Beneficios:
- Es obligatorio enviar casos de prueba para subir
extensiones a Dynamics 365 Business Central.

25. Casos de prueba + Automated testing
Beneficios:
- Minimiza los errores no detectados de “última hora”.

26. Casos de prueba + Automated testing
Beneficios:
- Minimiza los errores no detectados de “última hora”.
- Son fácilmente repetibles, nos permite validar en el
tiempo.

27. Casos de prueba + Automated testing
Beneficios:
- Minimiza los errores no detectados de “última hora”.
- Son fácilmente repetibles, nos permite validar en el
tiempo.
- Actualizaciones mensuales + extensiones -> Validación
constante.

28. Casos de prueba + Automated testing
Beneficios:
- Minimiza los errores no detectados de “última hora”.
- Son fácilmente repetibles, nos permite validar en el
tiempo.
- Actualizaciones mensuales + extensiones -> Validación
constante.
- Cambios en sistemas interconectados.

29. Casos de prueba + Automated testing
Beneficios:
- Minimiza los errores no detectados de “última hora”.
- Son fácilmente repetibles, nos permite validar en el
tiempo.
- Actualizaciones mensuales + extensiones -> Validación
constante.
- Cambios en sistemas interconectados.
- Testing del cliente -> Posible desánimo.

30. Casos de prueba + Automated testing
Beneficios:
- Metodologías agile. Revisión/validación constante.

31. Casos de prueba + Automated testing
Beneficios:
- Metodologías agile. Revisión/validación constante.
- Crear datos para validar una y otra vez es muy costoso.

32. Casos de prueba + Automated testing
Beneficios:
- Metodologías agile. Revisión/validación constante.
- Crear datos para validar una y otra vez es muy costoso.
- Aumenta la satisfacción de todos los implicados.

33. Casos de prueba + Automated testing
Beneficios:
- Metodologías agile. Revisión/validación constante.
- Crear datos para validar una y otra vez es muy costoso.
- Aumenta la satisfacción de todos los implicados.
- Superada curva de aprendizaje, menos costoso que validar
manualmente.

34. Casos de prueba + Automated testing
Beneficios:
- Metodologías agile. Revisión/validación constante.
- Crear datos para validar una y otra vez es muy costoso.
- Aumenta la satisfacción de todos los implicados.
- Superada curva de aprendizaje, menos costoso que validar
manualmente.
- No son subjetivos.

35. Casos de prueba + Automated testing
Importante
- Diseñar las pruebas antes de empezar el desarrollo.
- Acordar y coordinar con cliente del desarrollo.
- Basarlos en los casos de uso.

36. Tipos de errores
- Errores en el estándar de Dynamics NAV/D365BC
- Errores en nuestros desarrollos “aislados”.
- Errores en desarrollos “enlazados” con Dynamics
NAV/D365BC

37. Tipos de errores
• Errores en el estándar de Dynamics
NAV/D365BC

38. Tipos de errores
• Errores en el estándar de Dynamics
NAV/D365BC
• Detectados en el uso o por
validaciones “manuales”.
Reproducidos en la última CU.
• Reportar a Microsoft
https://mbs.microsoft.com/partnersou
rce/spain/support
• Sin coste si se escala a desarrollo.

39. Tipos de errores
• Errores de desarrollos aislados
del estándar de Dynamics
NAV / D365BC

40. Tipos de errores
• Errores de desarrollos aislados
del estándar de Dynamics
NAV / D365BC
- Detectados en tests personalizados.
- Demo de test personalizado.

41. Tipos de errores
• Errores interrelacionados con
el estándar de Dynamics
NAV/D365BC

42. Tipos de errores
• Errores interrelacionados con
el estándar de Dynamics
NAV/D365BC
- Detectados en tests estándar de
Dynamics NAV/D365BC
- Desde Dynamics NAV 2009 SP1
- +19000 tests (NAV 2017).
- DEMO

43. TDD (Desarrollo guiado por pruebas)

44. TDD (Desarrollo guiado por pruebas)

45. Qué queremos evitar

46. Qué queremos evitar

47. Algunos enlaces interesantes
• Testing para D365BC:
• https://docs.microsoft.com/en-us/dynamics365/business-
central/dev-itpro/developer/devenv-extension-advanced-
example-test
• Testing para Dynamics NAV:
• https://docs.microsoft.com/es-es/dynamics-nav/testing-
the-application
• Van Vugt’s dynamiXs
• https://dynamicsuser.net/nav/b/vanvugt

48. Dynamics 365 Community
The Dynamics 365 Community is a site where you can find community contributions, ask questions and
interact with Microsoft Dynamics peers and experts. The community has over 200K members and is
growing.
New UI/UX: https://community.dynamics365.com

49. ¡Muchas gracias!