Model Driven Development, the end of the test profession?
Last month I was invited to give a keynote talk at the Dutch Testnet 2010 event. I explained the basic concepts of Model-Driven Development (MDD) to an audience of about 500 professional software testers and gave some food-for-thought (I hope) about the impact of MDD on the test profession.
I really enjoyed the event. Please find a brief overview of my talk and the slides below.
Storyline: Marvin discovers MDD
I tried to explain the basic concepts of MDD by sharing the story of Marvin, a smart, imaginary programmer who discovers the key elements of Model-Driven Development. Marvin develops web applications and is tired of executing multiple changes in all parts of the software to deliver one business change. "Good programmers are lazy" means that good programmers always strive to efficiency. Marvin starts to use the DRY principle: Don’t Repeat Yourself. He makes sure to use one program definition and generate all parts of the software from that definition. The result: one business changes means one change in the program definition.
The question is what elements should be part of the program definition (model, if you like) and what elements should be generated from that definition? Marvin analyzes the web applications he has build for his customers and divides them into a static part and a variable part. The static part is the same for every web application. The variable part can change, based on the wishes of the customer. The static part can be put in a platform, the variable part should be defined in the model. By performing this analysis Marvin has a clear idea what to model and what to put in the platform. Marvin used a bottom-up approach, it’s also possible to use a top-down approach and start by performing a domain analysis.
Business is going well for Marvin, but it comes with a price: he doesn’t have the time to focus on improving the platform, to focus on technology. Marvin tries to solve this by providing tooling to make the specification of the model and the execution of that model easier. He provides a graphical syntax for the Domain-Specific Languages and introduces a "one-click-deploy" option. In this way he enables business engineers to build software for customers, while he can focus on the technological details and the tooling (separation of concerns). By providing abstraction (high-level modeling languages) and automation (tool support) he empowers business engineers to build software, to focus on the business problem instead of the technology.
MDD will change the test profession
What is the impact of MDD on the test profession? Does MDD lead to higher quality software and is testing less required? Let’s look at the V-model. This model is well-known by professional testers. The left part focuses on system development, the right part on system verification and validation.
The impact of MDD on the left part is that the lower half will be automated (i.e. will move to the MDD tool vendor), the focus will be on the upper half. The focus in software development will move from programming to requirements and functional design.
In the right part of the V-model we will see the same movement. The focus of professional testers will move from low-level system testing (unit tests, component tests, "technical testing") to validation and verification of the models. Testers will focus more on testing the business fit of a software system and will have more time to test the non-functionals (e.g. usability, security, performance) of a system.
Will this mean the end of the test profession? I don’t think so because:
- We still need to validate and verify the models.
- We need to test complex systems in complex environments (organization fit, supply chains).
- We need to test and verify the MDD tools!
- In practice MDD also includes technical models and in some cases custom code, which means sometimes testing will be needed on lower levels.
What is your opinion about the impact of MDD on software testing?
Photo of bear by dcdante03