Here are five species of application that seem, at first glance, to have little in common: mainframe "green screen," Win32/VB, Java/Swing, Web browser, and .Net WinForms. An enterprise application portfolio is likely to include members of each of these species. Nobody chooses this diversity; it just happens, and it complicates everything from development and deployment to maintenance and testing.
Might these various species in fact share common DNA? That depends on whom you ask. Platform vendors claim there's no way to abstract away what's different while zeroing in on what's the same. But then, they don't have much incentive to make that happen. Developers would love to develop and test Windows and Web software in a common way, for example, but Microsoft would prefer they didn't and so isn't investing in that scenario.
When platform allegiance isn't a factor, though, it's amazing how differences melt away. One company with a refreshingly pragmatic approach to isolating common software DNA is Worksoft, whose flagship product, Certify, tests all of the application flavors I've named.
Certify works by distilling each flavor down to a neutral representation of its data-bound objects. It creates an object map by any of four methods: parsing source code, inspecting the running application, manual specification, or importing from another tool. After the map is built, testers who know how to use the application -- but not how to write code that exercises it -- can choose from an inventory of screens and widgets, describe inputs and expected outputs in a spreadsheetlike interface, and compose sequences of tests.
To run the tests, Certify intercepts whatever APIs are necessary to translate its neutral objects into the object system of the application under test. Methods of interception include mainframe APIs, Java or .Net class libraries, and the browser's DOM.
Worksoft CTO Linda Hayes showed me an example that involved three application flavors: Web, mainframe, and Win32/VB. The sequence was just a demo, but it could well have been a real composite application. Although enabling power users to do cross-disciplinary integration work isn't a primary focus for Worksoft, the abstraction layer makes that a possible future direction.
Meanwhile, in the realm of test automation, abstraction yields several key benefits. Because tests are expressed as data, not code, testers use the same methodology in all supported languages and environments. Tests might even survive a migration from a mainframe app to its Web reincarnation.
Change analysis also benefits hugely, Hayes says. In cases where the object map is built and refreshed automatically, differences are shown in terms of objects, rather than lines of code. A database query correlates those objects with the associated tests.
Is Worksoft's no-coding approach an alternative to the coding-intensive methods advocated by practitioners of test-driven development? Hayes thinks so. One Worksoft customer runs 64,000 tests for each release of its product. If the tests were expressed as code rather than data, they'd require six times the quantity of production code. "As we say in Texas," Hayes jokes, "that dog won't hunt."
Agile developers will argue that point, but whatever your views, it's clearly strategic to distill software's common DNA.