« Model Driven Engineer… | Home | Domain Specific Model… »

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.

Slides

8 comments

In MDD, what is the difference between “programming” and modeling, and between “code” and models?

Jason Gorman (URL) - 03 11 10 - 21:04

Jason, what is the difference between programming in Java or Ruby and programming in Assembly, and between “source code” and “object code”?

Rafael Chaves () (URL) - 03 11 10 - 21:07

So no real difference then. Object code is code. java is code. Executable models are code. And executable modeling is programming. Just at a higher level of abstraction. Testers will test the compiled outputs of executable models, just as they do today, except today executable models are mostly written in languages like Java and Ruby.

Jason Gorman () (URL) - 03 11 10 - 22:02

I see what you were getting to, now. I mostly agree, except for “just as they do today”.

Some classes of problems that occur today occur less commonly with the added degree of automation MDD leads to, just like some classes of problems that occurred before Algol and the 3GL approach were common and now are no-issues (“wait, your jump does not go back to the test instruction!”).

IOW, the raise in the level abstraction also benefits testing, which can devote more attention to the solution from a POV of the business domain instead of implementation/technological concerns.

For instance, testers could possibly test the models themselves (running in a simulator/model VM), and only smoke test the actually generated application (because they gained confidence that there rarely is an issue with the code generation, and when it happens it happens everywhere).

Also, MDD enables seeing domain concerns and implementation concerns as belonging to different dimensions, and testers will benefit from that by being able to focus on testing along those two dimensions separately (possibly different people, with different skills, and in different organizations).

Rafael Chaves () (URL) - 03 11 10 - 22:31

Besides the aspects you mentioned at the end of your post we have to test several other things:

* security, however application is already a part of the output there are lot’s of issues that must be checked. Things like configuration of the servers, and infrastructured related issues.
* Usability, I can imagine that you can’t generate all wished of the using regardig usability
* interfaces with our famous old systems. the integration in the chain.
* specific parts of the app that aren’t generated but build traditionally.

I think it will change the way we’re doing our work, but testing will not dissappear.

andreas () (URL) - 04 11 10 - 07:21

In my opinion, the title of this post and your talk is really valuable in order to evaluate whether someone really knows what testing is. Naive software engineers tipycally rely on tools to solve their problems. Have to analyze the needs of the customer? Use a CASE tool, draw use cases and apply whatever template to have a nice doc. Have to test software? Buy an expensive tool, code tests… In my opinion, all the technology used in software engineering may be valuable if you have a good engineer there to make sure the objectives are met. Test engineers evaluate software, basically to detect faults. Will MDD be the end of their profession? Obviously not because MDD does not make a difference on what software is, and any software must be evaluated. Anyone that has a doubt about these answer does not get the point on what testing is.

This I tried to compact in a tweet: http://twitter.com/#!/jgfanjul/status/29...

Otherwise, if the title was chosen to provoke, I think it has served well

José García-Fanjul (@jgfanjul) (URL) - 05 11 10 - 10:36

Hi Jose,

Thank you for your clarification.

>Otherwise, if the title was chosen to provoke, I think it has served well

That’s indeed the case ;)

>Will MDD be the end of their profession? Obviously not because MDD does not make a difference on what software is, and any software must be evaluated.

My point is that MDD isn’t the end of the test profession. However, it will change the test profession. I think we will see a separation of concerns where the technical testing part will move to tool vendors and the project team will focus more on validation and verification at the model level.

You can compare it to the .Net framework or the JVM. You don’t test them in your project. Your verification is at a higher abstraction level. I think MDD can raise that level a bit more.

Johan den Haan () (URL) - 06 11 10 - 14:45

There’s also an interesting discussion about this article in the LinkedIn MDA group: http://www.linkedin.com/newsArticle?view..

Johan den Haan () (URL) - 09 11 10 - 08:52