With quality and testing becoming increasingly important in Mendix projects, is our approach to training and guidance keeping up?
Historically, testing was often considered a task that “anyone” on the team could handle, without specific training or focus. Today, however, we’re seeing the impact of limited testing knowledge across various roles, from business stakeholders to developers.
In my experience, a lack of platform-specific guidance often results in quality gaps. For example, developers might focus on technical correctness without fully understanding the business requirements. Testers lack insights into how to use Mendix-specific testing tools. Business analysts and product owners often make decisions and write stories without a clear understanding of the dependencies and technical impacts on the Mendix application. It’s crucial that developers not only adopt the platform’s best practices but also learn to think as testers—applying a quality-first mindset from the start. Likewise, other roles benefit significantly from platform-based training to understand the basics of the Mendix platform.
As developers grow within the Mendix ecosystem, I find that the focus often shifts naturally from just “building fast” to prioritizing quality and maintainability. The question is: how valuable is targeted training and role-specific guidance in elevating quality and testing standards? Should Mendix teams invest more in structured, platform-based training for all roles? And have you seen improvements in quality when team members have a strong foundational understanding of Mendix?
Let’s discuss— what do you think about the role of training and guidance regarding quality and testing in Mendix teams?
Contributing to this topic as a QA newly in Mendix… It seems challenging to find a QA professional well-trained in Mendix, and I’ve experienced some resistance from developers in adopting a QA mindset.
Even without directly developing or coding the solution, it’s important that everyone in the low-code squad has at least a basic understanding of Mendix. And when it comes to quality and testing, as Emiel rightly said, it’s should not be considered anymore as a simple task that "just anyone" on the team can handle.
When a mature and highly skilled team isn’t available for the project, I agree that training becomes essential. It’s important to identify the kind of training needed. For Mendix specifically, QA/PM/PO/etc., don’t necessarily need to be certified, but they should at least know open the tool and understand how it works. When it comes to quality and testing, it’s necessary for everyone to understand its value, learn proper techniques, and recognize that testing in low-code requires a different approach compared to traditional high-code solutions (a common mistake I’ve observed recently).
Implementing Shift-Left Testing (perhaps starting with DevBox Testing) can help bring QAs and their mindset closer to the development team, fostering a stronger quality culture. At the same time, DEV team introduces all Mendix layers to other team members, ensuring a better understanding of the platform and its capabilities.
For the sake of this comment, I'll organize development team in terms of technical knowledge with developers being at the bottom holding the most, then QA/BA/PM and so on..
I have not seen any substantial benefits of mendix training from the top down. Giving product folks for example knowledge on mendix is good context for them to a certain degree, but in my opinion has little impact. Product should be writing user stories agnostic to what the solution looks like any way. When grooming and refining, they lean on the developer lead/architect to give them advice on dependencies and engineering scope of their request. If product is prescribing the solution then they're doing it wrong.
I have however seen positive results in going bottom-up. Encouraging developers to learn more about QA and take on more of a personal responsibility to make sure QA and others above them are enabled as best they can.