[reposted from my old Blogger account]

In 2009 I needed to find ways to significantly improve my testing of an major, unfamiliar, product that used to have two long-term full time test engineers assigned to it. I had a few days a month, so there was no way I could reproduce their testing. I realized that every person on the project had gaps in their knowledge and understanding e.g. the developers often didn’t understand much of the business aspects, etc. which meant that features were slow to release, hard to develop and hard to test, and when they finally reached production they often had flaws and limitations.

Testing of features was performed by test engineers and the business teams, and typically lagged the development by several weeks, so when bugs were (finally) reported, the developer needed time to remember their work. The overhead of remembering their work slowed down the fixes and in practice meant that lower-priority issues might be deferred a month or two, rather than being fixed in the release being tested.

Trinity Testing was my approach to addressing all the issues I’ve mentioned so far. It works by combining three people:

• The developer of a feature or fix
• The business, feature, or story owner i.e. the domain expert for the feature/fix
• The test engineer

The people act as peers in the discussion, no one is ‘in charge’ or the ‘decision maker’ instead each participant is responsible for their commitments and actions.

We initially met for no more than 1 hour per developer after a release was created. We shared a computer and screen and ‘walked through’ each feature or significant change, spending a few minutes per item. Generally the developer was responsible for the walk-through; they described how their code works and received comments and questions from the other 2 participants e.g. the domain expert asked about how the feature behaved for other types of account; and the test engineer asked about how they could test the new feature. People noted any follow-up work or actions e.g. the developer may need to revise their implementation based on what they’ve learnt during the session.

At the end of each session, each participant follows-up on their work e.g. the test engineer may target additional testing on areas that are of concern (to any of the participants).

Within 2 releases, the Trinity Testing sessions had proved their value. Everyone who participated found them useful and better than the traditional development and testing process. Furthermore I was able to test each release in about 2 to 3 days, which reduced the manual testing effort to about 1/10th of the original.

Trinity Testing sessions are ideal at a couple of stages in the lifecycle of a feature or fix:

• At the outset, when the design is being considered
• As soon as practical after the feature is ‘code complete’, preferably before the formal release candidate is created and while the developer knows the software intimately

At design time, a Trinity Testing session should:

• help devise the tests that will be needed to confirm the feature will work as desired
• help the tester to know what to look for to spot problems (how would I know the software is not working?)
• help the developer to know what the feature/fix needs to do; so they don’t need to guess as often
• give the ‘owner’ justified confidence that their feature/fix will be more correct, and available sooner

A year on I’m continuing to receive positive comments about how useful Trinity Testing was for the project.

Note: Janet Gregory and Lisa Crispin devised the ‘power of three’ testing several years before I ‘discovered’ Trinity Testing. I wasn’t aware of their work at the time. You might be interested in reading their work as our approaches are similar but not identical. Their work is available in their Agile Testing book http://www.agiletester.ca/.