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?
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.
FREE Membership Required to View Full Content:
Joining MSDynamicsWorld.com gives you free, unlimited access to news, analysis, white papers, case studies, product brochures, and more. You can also receive periodic email newsletters with the latest relevant articles and content updates.
Learn more about us here