From my experience with Mendix project testing, it's evident that testing plays a vital role in ensuring application quality and reliability. A test-driven development (TDD) approach can be highly effective as it promotes early and continuous testing.

That said, the approach to testing may vary between projects, and there is no strict guideline suggesting that a tester with Mendix experience will necessarily outperform a non-experienced Mendix developer. The choice depends largely on the team composition and project needs.

In the projects I’ve worked on, we adopted a balanced approach:

• Developers take responsibility for creating unit tests and basic test cases during development.
• Testers—whether experienced in Mendix or not—contribute by reviewing these tests, expanding functional coverage, and managing the overall testing strategy.
• Automation tools are employed to handle regression testing and repetitive scenarios effectively.

Both manual and automated testing are essential:

• Manual Testing: Crucial for exploratory scenarios and user acceptance testing (UAT).
• Automated Testing: Efficient for repetitive tasks and regression tests, saving time and ensuring consistent results.

This adaptable strategy ensures testing aligns with project requirements while leveraging the skills of the team, regardless of their prior Mendix expertise.

Sharing my recent experience, I work on a project with five developers and one QA who initially had no Mendix skills. Most tests are manual and exploratory. After completing some learning paths and obtaining the Rapid MX Certification, the QA gained a better understanding of the SDLC and was able to contribute more effectively during discussions and reviews with the development team.

I agree that Mendix knowledge is very important for a QA, as the testing strategy differs from traditional SDLC. Understanding Mendix makes it easier to determine the right approach for each testing level, such as unit, integration, functional, automated, performance testing, and so on.

(And I don't think having 5 developers and only 1 QA is a good approach, considering how quickly features are developed compared to the amount of testing required.)

From my experience in testing 1 Tester with test-automation skills is enough for a team with 3 developers.

Mendix knowledge is not required. What is:

1 Being able to quickly understand business logic and needs

2 What testing is about: giving insight of the quality of the software and how it supports the business (finding a bug is merely evidence that the quality is low)

3 Having skills to use a test automation framework (Selenium / Playwright / etc.)

Hi Bas,

In my experience the amount of dedicated testing capacity greatly differs from app to app. It depends on many factors such as the maturity of the team, complexity and maturity of the app, the impact of a possible bug, the likelihood of a bug etc.

I worked in Mendix dev teams:

• Where 50% of the team were dedicated testers doing manual tests
• Without dedicated testers
• With dedicated automated testers
• With unittests and teams doing no unittests at all

I don't think there is a basic recipe, to be honest. You have to guarantee quality up to a required level. If that level can be achieved by doing thourough peer reviews and user tests alone: why not? But if you're doing an app to control a nuclear power plant, i suggest you go heavy on the testing.

I hope this helps.

Michiel

From my experience, having a dedicated tester with Mendix knowledge is valuable, but strong collaboration with developers is key. Developers should handle unit tests, while testers ensure functional and regression tests. A mix of manual and automated testing works best for consistent and thorough coverage.