MSDW readers: Get a 25% discount. on the new edition of the book by Microsoft MVP Luc van Vugt with the link and the promotional code in the article below, valid until March 10, 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 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 aligning custom extensions and ISV solutions.
An automated testing book may seem like purely technical work, but in a successful Business Central implementation, an automated testing initiative requires many roles. There are, of course, tests to code. But as Luc told MSDW in a new interview, test automation should be viewed in a broader context in terms of 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 this. One very obvious one is to free all those manual testers from the boredom of having to retest, on a regular basis, functionality or even an entire application. If boredom creeps into your work, you will most likely not deliver the right quality. All those recurring tests should then be replaced by coded tests. These will be done much faster and will not be affected by boredom. Finally, human testers will have room to do more rigorous testing; to really challenge the robustness of the so-called system-under-test (SUT).
Other reasons could be:
- Gaining a better grip on the quality of your software with automated testing means you’ll be able to easily retest after a subsequent change or addition. There is no need to free up and plan your human resources. Automation becomes another additional tool in the developer’s toolset.
- Improve requirements, as automated testing forces you to be more specific about how the system should behave and how this behavior can be verified. For me, an unexpected trade-off of test automation has been that the developers, who will code those tests, will tend to question the requirements much more than before.
Write about integrating automated testing into daily practices. What does it really mean?
Good question. It’s about making it work; take steps, of any size, to initiate test automation. As with any type of educational book, mine is primarily about learning new skills; on how to get from a customer wish in the test code. But beyond that, and certainly just as important, I’m also discussing how to make these skills work in your daily practices. Chapter 9 provides a multitude of suggestions. Perhaps the most obvious, yet most powerful, is to start and continue to learn and improve by taking these steps.
How does automated testing relate to a customer’s implementation of functional requirements?
For me it’s a one-on-one relationship. Or it should be as close to a one-to-one relationship as possible. As I mentioned earlier, your requirements will improve when test automation is involved. You need to be more specific about how the SUT behaves. As I began to devote myself more and more to test automation, it became more evident than ever that implementing software features is about implementing behavior. And the test is about verifying this behavior. It is not about concepts. It is a major flaw IMHO that requirements are a conceptual description of a customer’s desire. It’s only 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’s book Adzic Specification by Example. A must read for all software developers. Once your requirements end up in the behavioral descriptions, the step to testing and testing automation becomes a lot easier. In my book I have tried to reflect this with various examples and discussions of how to express a customer’s desire in so-called acceptance test-driven development (ATDD) scenarios.
Support 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 begin with the customer’s desire and the resulting requirements. This is IMHO a pure functional exercise, with technical consequences for sure. Answering your previous question – test automation and requirements is a one-to-one relationship – I actually answer that too, right? But let me be more specific.