I don't intend to get into the various merits / demerits of MDA - or the likelihood of viable MDA tools emerging -but I would note that it's my experience that code generation is on the increase - as evidence see the increasing number of tools on www.codegeneration.net.Code generation is of particular use where multiple similar products are to be produced in a software product line. In such cases the investment in producing code generators can be spread over multiple products. There are many documented examples of successful product lines using this approach - see the SEI's Software product Line Hall of Fame for some examples.However, what many of these case studies mention, and what I think is the core point of the article, is that when development get the capability to produce multiple differing products very quickly the testing job can become much harder.Techniques to help this situation do exist. However testers need to get involved early on to ensure the testability of the generated development artefacts and the generators themselves. This could involve production of a parallel test generator system.

I just have to say that I am astonished if this is the first time many of you are hearing of MDA. The technology and application thereof have been around for at least 4 years, if not more, and it makes me pause with wonder to realize that the majority of testing is still written and executed by hand.

Hi, Harry. I ran into this concept recently in the form of ASML, and of course I'm having the 'yeah, but' response.- I confess I don't get why it's supposedly such a big deal that this approach has this 'extra benefit' of design review. Maybe I'm missing something, but I've always taken it for granted that design review is implicit in the generation of tests, not in any given test-generation method. Writing tests manually has always led to questioning assumptions, ambiguities and contradictions just so we can fill in 'Expected Result' and make our work meaningful. Is there something more that ASM test generation provides? I'd love to understand what and why but I just don't get why it's better to tell a test engine what to expect than tell a Word document.- would it be true that this might have the same return-on-effort ratios by type of test as traditional automation? I've noticed that a tool like Robot or Winrunner works better for the 'method' testers than the fiendishly inventive people who just see the test plan itself as an envelope to push. Likewise, doesn't the opacity of something like ASML cut your returns in this higher register? I know I test weird and fiendish because a) I can see at a glance what the 'vanilla' test covers so I know where the uncharted turf is, and b) I get bored with actually executing the 'vanilla' test. If some engine is doing that vanilla for me, where's the simplicity/boredom I rely on?- My first thought on hearing about it was 'you're going to need QA people to QA the QA if you do this'. It seems to me that when testers start programming their work, they're prone to all the same pitfalls and blind spots as programmers. . . the presentation I saw suggested that ASML gives you automatic coverage stats on the code, which I suppose would help, but I don't know if it tells you how deep your *complexity* is. I'd go home and fret about that, at least until I got to where I could diagnose it myself by looking at a page of ASML. - What worries me here is what kind of assumptions we set up in project teams by keeping pace with developers. Do we gain anything, or do we just shovel the problems under a carpet that even we might have trouble reaching under? In my own experience, 'It will take us four weeks to write a worthwhile test plan for this' has actually been one of the most useful ways of getting dev to cough up their specs and designs early in the process. It's not just that it does take us that long. It's also the fact that because PM and dev *expect* it to take us that long, they're cheerful about fixing design. As soon as they start expecting I can keep up with them, I start getting more opposition to anything that will slow them down. It's been a running struggle any time automation was mentioned; I can't see it evaporating here.Very interested nevertheless.

>>>>>>>>>>>What you're describing is design inspection. ... It has not been easy to promote inspections at any phase in the SDLC.>>>>>>>>>>>>>I solved this 'problem' by creating a "Code Review / Modeling" QA Team. I setup the team within the Development Environment from developers who were burnt out and wanted to do something different. They reported to the Director of QA (me) but worked closely with the developers as they were developers. They were thus one-step removed from the other QA Teams who were outside of Development, doing gray & blackbox testing. After maturing the team structure, within 6 months, I moved the Code/Model Test Team back inside the QA Frame and then they cross-trained the other testers to do reviews of the UML cases. However, it is the developer-crossed-over-to-Testers who create these types of cases. This approach came out of my days as a developer (60s-80s) and then as Production Manager of CASE modelers, testers and programmers. As a long-time developer who still continues to upgrade her development skills through disciplined self-study, I think any kind of modeling technique for test cases design and hardening will work... if you use the right type of team members and steadfastly focus on the specs/design elements while creating high-level cases, then trickle down to lower-level cases, etc.

I do not believe that we (users of these new "UML to code" tools) need to develop and execute (automatically) a lot of test cases at all.Correct transformation of a UML model into code should be tested by a developer of this tool.In case of a mature tool we would get a lot of errors due to incorrect requirements and incorrect UML models. Automatically generated test cases are not able to catch these errors. They would report only that our incorrect model was correctly converted into code.In this case old fashion approach would work:- already discussed manual or automated verification of a UML model,- and testing against original requirements.

Harry, I would be more excited by MDA if I hadn't already seen several generations of technology and methodology promising leaps in productivity; this particular one has been around before, in the guise of CASE, in the late 80s - early 90s. Nevertheless, everything you propose is a good idea, regardless of whether MDA amounts to anything. In fact, testing as you describe is independent of MDA and dependent on something else: for us to be able to inspect models and to create test cases from them, the elements and components of the model must have well-defined semantics, and this calls for approaches like design-by-contract.

"As soon as development creates a UML model, testers review the model for ambiguities, completeness and correspondence to the customer's wishes." .... What you're describing is design inspection. The entire process improvement community just fainted in amazement! It has not been easy to promote inspections at any phase in the SDLC. To have a new technology come along that facilitates design inspections at the same time it (theoretically) obviates the need for code inspections (because generated code is always free of defects ^_^) is too good to be true! .... We always envisioned "roving bands" of inspectors who had a particular aptitude for it and honed that skill by practicing it, and furthermore brought an outsider's perspective that would catch defects that someone too close to the project might miss. But we won't complain if the testers want to take on the role. At least the inspections are not to be performed by the people who create the designs, which is a satisfactory separation of duties. .... Now if only we could propagate this outburst of sanity one step backward and implement requirements inspections, the world would be nearly perfect. Requirements defects are the most difficult to detect in the later phases of the project, the most troublesome to encounter in production, and the most expensive to fix. .... But we'll be patient. This is a great start!