Test Automation in Mendix: Is your QA Living Up To its Potential?

CAPE Digital Solutions - Forget gold and Diamonds - feedback is the real treasure - mendix mini survey - chelsea

Hey! I’m Darcy.

In this article, I’m going to take you through the recent Menditect Test Automation (MTA) trial we conducted here at CAPE Digital Solutions in partnership with one of our clients. I will tell you how I leveraged my background in game development and utilising build pipelines in conjunction with my recent Mendix learnings to approach a gap in standard Mendix development cycles: automated testing.

In game development, the user’s (player’s) experience is paramount. If the game isn’t fun to play, people simply won’t play. Software development projects are a lot more similar than people may realise; at the heart of everything, if the user doesn’t enjoy the experience, they may not come back.

MTA eliminates a typical time-sink for developers through automated testing, freeing up Agile teams to focus more on such user-centric developmental practises, improving both the quality and usability of their applications in the process.

Author of the blog:

Introduction Darcy - Team - CAPE - Business IT Consultant - news

Darcy Glover

What is Menditect Test Automation?

MTA provides automated dynamic testing of Mendix applications ranging from smaller unit tests to large end-to-end process tests. MTA can perform backend and front-end tests, to capture all parts of your user’s journey. Servicing Mendix teams of any size, small organisations with a single app, or even large ones with complex landscapes, MTA allows for smooth, development integrated testing which saves time and removes bottlenecks.

Why use MTA?

Let’s talk about some benefits the tool brings.

  • MTA executes at lightning speed, reducing the testing time of your application by 4-10x. End-to-end tests that would normally take 4 days manually can be completed in less than 1.
  • MTA could save you money in the long term by cutting down on manual QA work and removing the need for going back and forth between testers and developers.
  • Test code exist outside of the app’s model, meaning a cleaner, easier to maintain application in general.
  • Managers can be confident that potential issues are captured and fixed well ahead of release days as bug fixing becomes a proactive measure from developers, not a reactive one.
  • Your application is future proofed in case of shifting developers or product owner roles, as MTA tests point out the exact location of issues and what exactly broke during the test run.

Learnings from the Trial

As I mentioned earlier, recently we conducted a trial with one of our clients to learn about how MTA could improve our processes here in Australia and reinforce our standards of user experience, application maintainability, and innovative practises. Over the course of roughly 6 weeks, a member of the client’s team and I learnt how to utilise and leverage MTA, discovered how to integrate it into our client’s existing Mendix application, and discussed MTA’s viability; its benefits as well as its shortcomings.
I’d like to share some of the key things we learnt.

First, the positives:

  • Back-end data variations allow for all user journey paths to be tested during a testing cycle – if you can think of an edge case, MTA can test for it.
  • Application user experience is smoother as a greater number of issues are found before reaching Live environments than with traditional QA testing.
  • Once some core test cases are built, they can be rolled out and used in similar test cases, further shortening development time.
  • MTA allows for front-end UI testing which can test a user’s direct UX journey through the application. Comparatively to a back-end or traditional test, there is almost no “faking” of certain test components needed, leading to an accurate, clean test that can be confidently relied on.
  • MTA can also test for cases where you expect something to go wrong, such as ensuring a user does not have access to admin parts of your application.

What about some of the shortcomings?

  • MTA is not a “set and forget” tool. A consistent, steady hand on the wheel is needed to continue to see positive results emerging from tests.
  • Tests need to wait to be built until the application’s functionality is semi-stable. New functionalities are always in flux near the beginning, so tests cannot be reliable until the design or code of something is settled.
  • MTA does have a steep learning curve, especially when one tries to apply a traditional QA mindset to building its tests. Once over that hump, however, it becomes an effective and easy-to-use tool.
  • Productively can potentially see a dip during the initial set-up of MTA’s integration, due to the time needed to implement the plugins needed.

Conclusion

Overall, our experience with MTA was hugely positive and our trial was a massive success. We found MTA to be a clean, re-usable tool which, when implemented in tandem with a developmental lifecycle for a Mendix application, improves the quality and maintainability of said application. MTA improves the efficiency of development time, reducing hours spent running through tests and diagnosing bugs, allowing you to spend more time improving your application and letting it live up to its greatest potential.

MTA might be a great fit for your Mendix application if:

  • You don’t have a dedicated tester or test-team, or want to free them up to be more efficient and specialised
  • Your UI/UX flows are complex and involve lots of edge-cases and branches
  • You are budgeting days or weeks for your end-to-end tests, and would prefer to have them done in mere hours
  • You feel there is a gap in your Agile workflows when it comes to testing

Of course, MTA is not something that will fit nicely into every single Mendix application. Some examples of projects that might be unsuitable for MTA are:

  • Projects at or near to their beginning
  • Applications that don’t deal with a lot of data sets or API calls
  • Applications that don’t have a big focus on user experience or front-end
  • Stable applications that don’t have a lot of functionalities in flux, or aren’t pushing to Live environments very often

I am excited to bring the magic of MTA to our existing and new clients alike, and I can’t wait to get stuck into some more automated testing and discover everything this fantastic tool can do.
If you’d like to read more about MTA from its creator Menditect, you can here
That’s all from me for now!

Ready to cut the monotony out of your QA testing?

Would you like to automate your testing and focus more on application quality and user experience? Do you think your Mendix application and Agile workflows would be improved through an effective implementation of MTA? Get in touch, and let’s find out!

Have you used MTA in the past? How did your experience compare to ours? Drop us a message!

Introduction Darcy - Team - CAPE - Business IT Consultant - news

Darcy Glover

More about Mendix

Low-Code Development Explained

Low-Code Development Explained

Articles Low-Code Development explained Reading time: 2 minutes  Understanding what low‑code is only tells part of the story. The real value emerges when low‑code is applied in practice, through the way applications are designed, built, governed,...

read more
What is Low-Code?

What is Low-Code?

Articles What is Low-Code?  An introduction to custom software development with Low-Code. Reading time: 2 minutes  Low‑code is a modern approach to software development that enables applications to be built with minimal hand‑written code. Instead...

read more