Interview: Why test automation for Microsoft Dynamics 365 Business Central is a team effort

MSDW Readers: Get a 25% discount on the new edition of Microsoft MVP Luc van Vugt's book with the link and promo code in the article below, valid until 10 March 2022.

Last December the 2nd edition of Luc van Vugt’s book Automated Testing in Microsoft Dynamics 365 Business Central was released by Packt Publishing. The book aims to explain how to "efficiently automate test cases for faster development with less time needed for manual testing.” And speed in development work is an urgent need for Business Central customers and their partners as they adopt 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 a purely technical work, but in a successful Business Central deployment, an automated testing initiative calls on many roles. There are, of course, tests to code. But as Luc told MSDW in a new interview, test automation should be considered in a wider context in terms of the project roles, departments, and interest groups that can impact it.

MSDW: When should an organization look at implementing automated testing?

Luc van Vugt: There are various reasons to do that. A very obvious one is freeing up all those manual testers from the boredom of having to retest - on a regular base – features or even a whole application. If boredom sneaks into your work you most probably will not deliver the right quality. All those recurring tests should therefore be replaced by coded tests. These will be much faster executed and not be influenced by boredom. Finally, the human testers will have room to do more rigorous tests; to really challenge the robustness of the so-called system-under-test (SUT).

Other reasons could be:

• Getting a better hold on the quality of the software with automated tests means you will be able to easily retest everything after a next change or addition. No need to get your human resources freed up and planned. Automation becomes another and extra tool in the toolset of the developer.
• Improving the requirements, as automated test forces you to be more specific in how the system should behave and how this behavior can be verified. To me, an unexpected trade-off of test automation was that developers, who will code those tests, will tend to question the requirements much more than before.

You write about integrating automated testing into daily practices. What does that really mean?

Good question. It’s about making it work; making steps, whatever size, to get test automation going. Like in any educational kind of book, mine is first of all about learning new skills; about how to get from a customer wish into test code. But next to that – and surely as important – I am also discussing how to make these skills work in your daily practices. Chapter 9 gives a multitude of tips. Maybe the most obvious, and yet most powerful one is to start, and keep learning and improving by making those steps.

How does automated testing relate to the implementation of a customer's functional requirements?

To me that’s a one-to-one relation. Or should be as close as possible to a one-to-one relation. As I already mentioned earlier, your requirements will improve when test automation gets involved. You need to be more specific in how the SUT is behaving. When I started to get more and more into test automation it became more apparent than ever that implementing software features is about implementing behaviour. And testing is about verifying this behaviour. It’s not about concepts. It is a major flaw IMHO that requirements are a conceptual description of a customer wish. It’s only the start of it. From there they should transform into a behavioral description. In realizing this, I owe a lot to Nicole de Swart who pointed me to Gojko Adzic’s book Specification by Example. A must read to all software developers. Once your requirements end up in behavioral descriptions, the step to testing and test automation becomes a much simpler one. In my book I strived to reflect this all with various examples and discussions how to cast a customer wish into so-called Acceptance Test-Driven Development (ATDD) scenarios.

You make the case for involving non-development roles in automated testing initiatives, like functional consultants or power users. Can you give examples of how these more functional roles can participate?

Software implementations all start with the customer wish and the requirements that come from it. That’s IMHO a pure functional exercise, with technical consequences for sure. With answering your previous question – test automation and requirements is a one-to-one relation – I actually also answer this one, right? But let me be more specific.