Model-Driven Architecture

Powerful new development technologies such as model-based code generation will overwhelm test teams that continue to create tests by hand. It's time for testers to put their own productivity into a higher gear. Harry Robinson tells you all about it in this column.

Anything that changes the development process is going to change the testing process before long—so occasionally it's good to look up from the quality emergency of the moment to see what's coming over the horizon. The newest contender for changing the world of development is an initiative called Model-Driven Architecture (MDA).

The details of MDA can be complex, but its goal is simple. Instead of writing all the code for an application, developers will design their solutions in the Unified Modeling Language (UML). These UML designs will automatically generate code that, with minimal customization, can be mapped onto many different platforms. There will, of course, be platform-specific issues to consider, but if successful, MDA promises to generate as big a boost in productivity as the move from machine language to compilers forty years ago. Model-based code generation will make software faster to create, to update, to port, and to deliver. And MDA is gaining followers. Some development groups, notably in engineering firms, are already generating 40 to 80 percent of their code with MDA. Personally, I'm happy if MDA makes our developer brethren more productive, but how will MDA affect testers?

Here's an image for you to consider. Think of development and testing as two people walking together down a road at a mutually agreeable pace. The developer writes code by hand, the tester writes tests by hand to exercise that code; and this arrangement works pretty well. But if MDA increases developer productivity substantially, it would be as if the developer now has a bicycle and can now move at a much greater speed. How should the tester respond? Here are some options, illustrated with the bicycling image from above:

If the tester continues writing test cases by hand at the usual pace, while the developer generates code automatically, the development work will outpace the testing. This results in poor quality releases. Bicycle translation: The tester gets left in the dust as the developer rides over the horizon.

If the hand-written tests prevent the developer from moving as quickly as the MDA technology will allow, developers will accuse the test team of holding the project back. Bicycle translation: The developer grumbles at having to ride the bike at a walking pace.

If the test team tries to write tests by hand fast enough to keep up with the productivity of the developers, the testers will burn out. Bicycle translation: The tester runs alongside the developer's bike for awhile before falling down exhausted in the dust.

Since development is using models to generate code, the testers decide to use models to generate tests. Test generation would provide the flexibility, power, and rapid response needed to keep pace with development. Bicycle translation: The tester hops onto a bicycle and keeps up with development. Fighting tire with tire so to speak. The last option, generating tests, seems the most viable.

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.