I used this presentation in my keynote talk at the Dutch Testnet 2010 event. For an audience of 500+ professional software testers I explained the basic concepts of Model-Driven Development and gave some food-for-thought about the impact of MDD on the test profession.

1. Model-Driven Development,
the end of the test profession?
Johan den Haan
Head R&D Mendix
@JohanDenHaan

3. I’m not a test
expert

4. Meet Marvin!

5. How Marvin discovered MDD
1. Good programmers are lazy
2. Creating a product line
3. Empowering business engineers
4. Changing the test profession

6. 1. Good programmers
are lazy

7. Marvin needs to add a field to
the Order entity…
User Interface
Application Layer
Domain Layer
ORM
Database

8. Marvin wants 1 place to
change instead of 5
User Interface
Application Layer
Domain Layer
ORM
Database

9. DRY
Don’t repeat yourself

10. Good programmers are lazy
 Don’t repeat yourself
 Generate different parts from one program
definition
 One business change means one change in
program definition
 Program definition can be seen as a model
 First step into direction of MDD

11. 2. Creating a
product line

12. Marvin needs to serve
a lot of customers…
Customer 1 Customer 2 Customer 3

13. Software Product Line:
assemble assets

14. Platform Assets Assemble Application

15. Proactive vs. Reactive
Software Product Line
design

16. Creating a product line
 What should be part of the model?
 Define a domain and specify the static and
variable part
 Model can be at higher abstraction level
 Second step into direction of MDD

17. Summary
1. Don’t repeat yourself: one business change is
one change in your program specification
2. Define a domain: separation between static
(platform) and variability (model) leads to a
high-level model

18. 3. Empowering
business engineers

19. Marvin wants to focus
on technology…

20. … so he empowers business engineers

21. Language Transf. rules
Specified in Defined by
Model Generator Code
Uses
Domain
Framework

22. Domain-Specific Language

23. Code Generation vs. Model Interpretation
+ =
+ =

24. Abstraction and Automation
empower business engineers

25. Empowering business engineers
 High-level modeling language (abstraction)
 Tool support (automation)
 Empowers business engineers
 Focus on business problem instead of
technology
 Third step into direction of MDD

26. Summary
1. Don’t repeat yourself: one business change is
one change in your program specification
2. Define a domain: separation between static
(platform) and variability (model) leads to a
high-level model
3. Use DSLs: easily specify a high-level model
which is automatically converted into a
working application

27. 4. Changing the
test profession

28. Marvin…!! What’s
in it for me?

29. … no billable
hours for Marvin

30. Marvin explains…
 Higher productivity
 More agile
 Business-IT alignment
– Communication using models
– Empowering domain experts
– Short feedback cycles
 Improved quality
– Separation of concerns
– Engine contains knowledge
– Less technical errors

31. Is MDD less
error-prone?

32. User Acceptance
requirements test
System
System test
requirements
Integration
Design
test
Detailed Component
design test
Code Unit tests

33. User Acceptance
requirements test
System
System test
requirements
Integration
Design
test
Detailed Component
design test
No code Code Unit tests

34. User Acceptance
requirements test
System
System test
requirements
Integration
Design
test
No detailed design
Detailed Component
design test
Code Unit tests

35. User Acceptance
requirements test
System
System test
requirements
Integration
Design
test
No technical design
Detailed Component
design test
Code Unit tests

36. Focus on requirements, Focus on validation,
functional design reviews, business fit
User Acceptance
requirements test
System
System test
requirements
Integration
Design
test
Detailed Component
design test
Code Unit tests

37. Are we approaching
the end of the test
profession?

38. Why MDD doesn’t mean the end of
the test profession
 Validation and verification still needed
 Testing of complex systems in complex
environments
 Testing and verification of MDD tools!
 Is creating software by only defining the
functional design ever feasible?

39. How Marvin discovered MDD
1. Good programmers are lazy
2. Creating a product line
3. Empowering business engineers
4. Changing the test profession

40. Model-Driven Development
will change the test profession!
Read more (blog): www.theenterprisearchitect.eu
Connect (twitter): @JohanDenHaan