Starting early with automating tests has the following benefits:

• You can optimize your Mendix models for testing. This brings no additional costs when building the app, but can become costly when done too late.
• You prevent ending up with a large test debt. A large test debt is potentially dangerous and might lead to unexpected errors.
• It takes the developer/tester less time to write an automated test case shortly after the new functionality is built/tested manually, because the topic is then still top of mind

Here are some examples on how you can embed testing in your development process

• Write unit and process tests right after the team has developed the functionality. Even better, make the creation of an automated test part of the “definition of done”.
• Save your developers time and execute regression tests on new functionality as early as possible (shift left testing). This allows for early error detection and lower costs of fixing errors.
• Make test automators part of the development team and keep the domain knowledge of the app in one team. This saves (communication) time and reduces chances of errors.

A good collaboration between testers and developers is valuable because:

• When testers and developers work in the same team it is easier to speed up the delivery process of new functionality
• When testers and developers both contribute to automated test scripts they use their (different) expertises to increase the quality of the app. This results in better test cases and improved quality of the code
• Writing test cases becomes part of your team process and culture and fosters a quality driven mindset

If you want to automate tests in Mendix you should focus on the stable parts of the application that contain most of the risks. In other words, you can best focus your test strategy on testing the business logic that is captured in Microflows. The reason for this is the following:

• Screen errors are easily detected and can be fixed really fast, therefore screen errors represent a relatively low risk
• Errors in logic that result in the storage of corrupt data are much harder to detect and to fix, therefore errors in logic create a higher risk