Author Interview: Why Test Automation for Microsoft Dynamics 365 Business Central is Teamwork
MSDW drives: Obtain a 25% off on the new edition of Microsoft MVP Luc van Vugt’s book with the link and promo code in the article below, valid until March 10, 2022.
Last December the 2nd edition of Luc van Vugt’s book Automated tests in Microsoft Dynamics 365 Business Central was published by Packt Publishing. The book aims to explain how to “effectively automate test cases for faster development with less time needed for manual testing”. And speed of development work is an urgent need for Business Central customers and their partners as they embrace Microsoft’s SaaS ERP model with its frequent updates and new requirements for alignment of custom extensions and ISV solutions.
A book on automated testing may seem like purely technical work, but in a successful deployment of Business Central, an automated testing initiative involves many roles. There are of course tests to code. But as Luc told MSDW in a new interview, test automation needs to be seen in a broader context in terms of the project roles, departments, and interest groups that can impact it.
MSDW: When should an organization consider implementing automated testing?
Luc van Vugt: There are various reasons for doing so. One of the most obvious is to free all those manual testers from the boredom of having to retest – regularly – features or even an entire application. If boredom creeps into your work, you’re probably not delivering the right quality. All these recurring tests should therefore be replaced by coded tests. These will be executed much faster and will not be influenced by boredom. Finally, human testers will have the ability to do more rigorous testing; to really challenge the robustness of what is called the system under test (SUT).
Other reasons could be:
- Better control of software quality with automated testing means you can easily retest everything after the next change or addition. No need to free up and plan your human resources. Automation becomes another additional tool in the developer’s toolset.
- Improve requirements because automated testing forces you to be more specific about how the system should behave and how that behavior can be verified. For me, an unexpected trade-off of test automation was that the developers, who will be coding these tests, will tend to question the requirements much more than before.
You write about integrating automated testing into daily practice. What does this really mean?
Good question. It’s about making it work; take steps, no matter how small, to initiate test automation. As with any educational book, mine is primarily about learning new skills; on how to go from a customer wish to a test code. But alongside that – and surely equally important – I also discuss how to make these skills work in your daily practices. Chapter 9 gives a wealth of advice. Perhaps the most obvious, yet most powerful, is to start and continue to learn and improve by following these steps.
What is the relationship between automated testing and the implementation of a customer’s functional requirements?
For me, it’s a one-to-one relationship. Or should be as close to a one-to-one relationship as possible. As I already mentioned earlier, your requirements will improve when test automation is involved. You need to be more specific about the behavior of the SUT. When I started to get more and more interested in test automation, it became more obvious than ever that implementing software functionality was all about implementing behavior. And the tests are to verify this behavior. It’s not about concepts. It is a major flaw IMHO that the requirements are a conceptual description of a customer wish. This is just the beginning. From there, they should turn into a behavioral description. In realizing this, I owe a lot to Nicole de Swart who pointed me to Gojko Adzic’s book Specification for example. A must read for all software developers. Once your requirements are in behavioral descriptions, the testing and test automation step becomes much easier. In my book, I have tried to reflect all of this with various examples and discussions of how to turn a customer’s wish into so-called Acceptance Test Driven Development (ATDD) scenarios.
You advocate for the involvement of non-development roles in automated testing initiatives, such as functional consultants or power users. Can you give examples of how these more functional roles can participate?
Software implementations all start with the customer’s wish and the resulting requirements. It is in my humble opinion a pure functional exercise, with technical consequences for sure. Answering your previous question – test automation and requirements are a one-to-one relationship – I’m also answering this one, right? But let me be more specific.