Briefing: TestArchitect 2.0

• By Mike Gunderloy
• January 21, 2005

TestArchitect 2.0
LogiGear Corporation
FOster City, California
(650) 572-1400
www.logigear.com

Developers do not, in general, make the world's greatest testers. But sooner or later we all get roped into the testing process, whether to test our own code (not a great practice!) to scrutinize other developers' code (not much better) or to work with a dedicated QA organization. So I think it's worth keeping track of some of the more interesting things going on in the testing tools market. From that perspective, it's definitely worth knowing about TestArchitect 2.0.

Suppose you're producing an application for use by your company's purchasing department. The folks who really should be testing it are those who will be using it: they know that they want to look up product details and place an order, for example. But the folks who know how to express these tasks in computer-eses (click this button, type in this textbox) are the test engineers. What TestArchitect does it make it easier for these two groups to work together, so that the test engineers can concentrate on what they're good at without becoming a bottleneck, and the business users can actually specify their own tests.

To accomplish this, TestArchitect runs as an Excel add-in (there's also a standalone interface for people who prefer to go that route). Business users can enter tests in their own language: look up details on product 123, place an order for 5 units. These keyword-driven tests (Logigear uses the term Action Based Testing(TM)) are stored in a central repository (which can use Microsoft Access or SQL Server as its underlying database) that manages its own checkin and checkout processes. Test engineers then use the tools in TestArchitect to hook up the keywords to actual product actions.

There are a lot of benefits to this approach. One of the big ones is that you get an immense amount of test reusability: if part of the job of many tests is to log in, you define a single login action one time and then reuse it everywhere, without the test engineer needing to write additional code. Another is that test design can start before the first software build is delivered. If things change as the builds progress (controls are moved around or renamed, for example) the test engineer can fix the low level and changes propagate instantly to the higher levels.

TestArchitect can do its own test automation, or it can drive other products such as Silk. So if you've already got a library of tests, but are drowning in disorganization, TestArchitect can help you clean up what you have and use it more efficiently. If you're starting from scratch, TestArchitect will cover the whole field for you. I had a chance to see a solid demo, and TestArchitect is well-polished and impressively fast and flexible.

In talking with Hans Buwalda (developer of the keyword-based method and co-author of INTEGRATED TEST DESIGN AND AUTOMATION, as well as the product's architect), though, it became clear that the product isn't the most important part of LogiGear's offerings in this area. Instead of being a company that sells a product and offers consulting on the side, LogiGear sells testing solutions and has a product to help implement those solutions. Buwalda says that there are three main things that need to be sorted out when they start a new engagement:

• Proper test design
• Test automation architecture (which may or may not use TestArchitect)
• Effective organization to use testing seriously

It's good to see this recognition that a tool isn't enough, as opposed to some other company's that push boxes full of magic bullets at their customers. If you're wrestling with a testing process gone awry, you ought to stop by the LogiGear Web site or give them a call to see what they can do for you. You might find that their services are what you need to get things running smoothly again.