Briefing: TestArchitect 2.0
FOster City, California
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
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
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
- 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
Mike Gunderloy has been developing software for a quarter-century now, and writing about it for nearly as long. He walked away from a .NET development career in 2006 and has been a happy Rails user ever since. Mike blogs at A Fresh Cup.