Model Driven Development, the end of the test profession?

MDD, 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

Testnet Keynote
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

Impact of MDD on V-modelWhat 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

Slides


10 Comments Added

Join Discussion
  1. Jason Gorman November 3, 2010 | Reply

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

  2. Rafael Chaves November 3, 2010 | Reply

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

  3. Jason Gorman November 3, 2010 | Reply

    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.

  4. Rafael Chaves November 3, 2010 | Reply

    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).

  5. andreas November 4, 2010 | Reply

    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.

  6. 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/29595265951.
    Otherwise, if the title was chosen to provoke, I think it has served well šŸ™‚

  7. Johan den Haan November 6, 2010 | Reply

    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.

  8. Johan den Haan November 9, 2010 | Reply

    There’s also an interesting discussion about this article in the LinkedIn MDA group: http://www.linkedin.com/newsArticle?viewDiscussion=&articleID=244108048&gid=50539&type=member&item=34075188&goback=.gde_50539_member_34075188

  9. Rahul Agarwal March 14, 2011 | Reply

    Hi,
    I strongly believe that the MDD will surely not undermine the importance of testing in the development V cycle, and thereby will never throw the testing out of business. The “human” factor indeed plays a significant role at various stages of development, and they cannot be done away with!
    However, I also feel a strong need to metntion another point of view here. Rather than looking at the negative impact of MDD on the testing jobs, we need to focus on the advantages of the approach in the development process by itself.
    We all know in typical development cycle, it takes all – design, development and testing – before any requirements can be realized in a “visualizable” form where they can be ratified by the requirements owners. If there are any mismatches or misinterpretations between the requirements and the developed software, the entire process has to be cycled again with the corrected interpretations. Going through 2 or 3 iterations just to ensure all requirements are correctly captured and implemented, defintely does not raise an eyebrow.
    With the advent of MDD, however, this is set to change, and is chaging – rapidly. As the FIRST step in MDD, the requirements are converted into models, thereby converting them a “SIMULATABLE” and “VISUALLY REALIZABLE” form. This step, with the modern day tools, is not only quick but also easy. The requirement stake holders can thus use these “WORKING” models and identify any functional requirements mismatches! This saves rounds and rounds of going through the entire development cycle! And this, IMHO, is truly the most significant and valuable advantages of MDD over the traditional approach.
    Of course, I am in no way advocating that with MDD the testers’ jobs can be done away with. In fact they will still hold the flagstaff, and will continue doing the most important job in the cycle – ensruring correctness – no matter the development model – MDD, TDD, or whatever!
    Though, speaking of the impact of MDD on testing business – yes, there is! But not that of eliminating the business, but that of shrinking the size and quantum of business. With reduced cycles of development, where each cycle involved testing, we are surely in for a reduced quantum of testing jobs !
    (Though, lets also hope that with reduced turn-around-time as above, and thus increased cost efficiency, MDD will promote more and more applications to be developed, thereby balancing the ecosystem).
    Rahul

  10. Johan den Haan March 14, 2011 | Reply

    Hi Rahul,
    Thanks for sharing your opinion! I agree with you: the test profession will not disappear, but the focus will move to to verification of models instead of unit testing code.

Leave a Reply to Johan den Haan Cancel reply