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.
Putting Some Wheels Under Testing
So, what would this world of test generation look like? It will look different from much of the software testing that happens today. Here are some examples of behaviors we would see:
As soon as development creates a UML model, testers review the model for ambiguities, completeness, and correspondence to the customer's wishes. And test creates its own version of the model that will generate tests for the system.
When development generates code; testers will generate tests to exercise that code. Likewise, when development makes a change to the UML model and regenerates the code, test will make a change to the test model and regenerate the tests.
As development deploys code to specific platforms, the test team generates tests that execute against those platforms.
I don't think test generation from models can ever be a complete solution. Just as there are trails where walking is more appropriate than biking, there will always be parts of a software system that are best tested by hand. What I am suggesting, however, is that much of the mundane work of both development and testing will be handled by machines. And this is a good thing: it means that testers can focus their efforts on the creative aspects of their jobs.
Strap on Your Training Wheels
In a test-generating world, tester activities will begin to look a lot like developer activities. And, the skills that testers need will begin to look a lot like the skills that developers need: abstraction, planning, and design. So, what should testers do to prepare? Consider upgrading your skills, especially in understanding the UML and model-based test-generation techniques. Even if you don't see your team needing test generation for awhile, it is certainly worth your time to take the technology for a test ride, or at least a spin around the block!
Suggestions for further reading
- Find out more about Model-Driven Architecture at www.omg.org/mda.
- Take a look at Bob Binder's book, "Testing Object-Oriented Systems: Models, Patterns, and Tools," especially Chapter 8 "A Tester's Guide to the UML"
