Imagine two people sitting back-to-back in chairs. You ask each to draw a picture of a circle, a square, and three triangles. They complete their drawings, face each other to compare pictures, and no surprise the pictures look nothing alike. Well, the world of software development can be a lot like that scenario; clients and software developers often tend to come up with their own notion of what a project should accomplish and how the product should work. Steve Timmerman, CEO of SWAT Solutions, a Plymouth based software testing firm, is working to bridge that gap.

SWAT, which has been around since 1997 and boasts a lineup of clients that includes Guidant, Pillsbury, and 3M, prefers to start at the beginning of the software development cycle, during what's commonly known as the requirements definition phase. According to Timmerman, the client firm typically has a clear vision of what it wants at that point. However, if it doesn't specifically communicate that vision, it will end up with a software developer's interpretation, which often includes additional functionality. "The added functionality might be cool, but it is often not wanted," he notes. "You need to bring a strong sense of discipline to this process. You need to stick to the requirements."

According to Timmerman, similar mishaps can happen later in the development cycle as well. Companies either don't have any documented requirements or they confuse testable with non-testable requirements. Non-testable requirements can be elements such as configuration issues (Client: "This must run on an Oracle database!") or process requirements (Client: "The user and policy guide must be available at all times."). According to Timmerman, a testable requirement is one that calls for an action and produces a specific result.

Once the testable requirements are defined, SWAT develops a test plan. While running through a test suite can take days, Timmerman says his company automates the test scripts so they can be run again in hours. "Automation has saved our clients time and money," he notes, citing one client whose testing typically cycle took 72 hours - a number that was reduced to 16 hours after automation. After the 25th time through the testing cycle, the ROI was obvious.

Timmerman is nothing if not confident in his operation, noting that its processes, discipline, and automation offerings differentiate it from other software testing firms. To emphasize that point, he often displays his 15-page "little black book" of testing processes during sales calls. "We don't expect the client to tell us how we should test," he says, adding that he has spent 20 years developing his methodology and has repeatable evidence that it works. "We tell them how we test."