While I love to write, I occasionally prefer the role of reviewer or editor. I find it a nice break to sit on the other side and evaluate someone else’s work for a change. How much more comfortable to critique someone else’s product then to summon the courage to create something myself!

But how much easier would it be to create if we had a magical safety-net that guaranteed whatever we did would turn out well? How much more would we accomplish if we knew our every endeavor would be a success? Imagine a kick ass editor or, in software, a fabulous tester who had our back. Let’s call them Rumpelstiltskin. Able to take Garbage In, and turn Greatness Out.

We might find that the tables had turned. That the need for courage had passed from the creator to the tester. We only have to give them straw. They have to find a way to turn it to gold.

I have seen this happen on software projects, where the senior developers’ time has been deemed too valuable to “waste” on bug fixes. Have you seen this? A team of developers up in their ivory tower, banging out new features, while a test and bug team come in to clean up behind them. All so the senior folks can go work on the next big thing.

I just can’t imagine this situation is satisfactory for anyone involved. Not for the senior developers because we ask them to invest all that hard work but then deprive them the satisfaction of a job well done by forcing them to stop short of learning whether they got it right or allowing them to sculpt it into the final solution. Not for the testers or bug team, because they’re left with the onus of getting it right, while the senior developers get all of the credit.

Even when the developers are writing unit tests to ensure their code “works,” so many of the problems we find in software are communication, rather than technical, issues. And the further we remove developers from the process of validating whether their software does what the customer really wants, the more the problem gets compounded.

In agile, we seek a better answer with our notion of All Together. One where we all require courage, but where finding that courage is made easier by the safety nets we put in place. If testers are really good at working with completed software to ensure it meets the customers needs, why not just allow them to do this throughout? Let’s skip the separate bug team and it’s test/fix cycle and just get it right the first time.

Testers can work with customers up front, before a feature has been developed. They can dig beyond the stated requirement to learn what it will take for the feature to actually be usable. The criteria by which users will judge it. In the end, success is defined by the software’s usefulness to the user, not by its adherence to documents. And so if testers are going to have to figure out how to validate that it meets those user needs, why not figure that out up front – and allow that knowledge to help drive development in the right direction?

The truth is, it’s a waste of testers’ skills and an exercise in frustration to leave them until the end – trying to inject quality into something that’s already built.

In the beginning…

So, agile puts testers at the beginning. It gets them involved with the customer, helping elicit acceptance criteria in terms of objective tests. And sharing these with developers so they can design the right solution to build from the start.

The middle

And it puts testers in the middle. We talk a lot about having developers testing their own code. Well good! As developers, we should be able to test our own code. But the truth is, most developers haven’t been trained in testing and so figuring out what to test can sometimes be daunting. Why not let testers sit down and pair with us while we’re writing some of our tests? Give us a second set of eyes and help us find techniques for writing effective tests as simply as possible.

At the end

And it put testers at the end. Not the end of a release, but the end of a feature. As we integrate our new features, testers provide us with their wonderful safety net of tests to ensure that our software continues working as expected. And since most defects will have been prevented or dealt with by this point, it allows testers to look further. To inspect the software and feed ideas for improvement back into the process we use as we move on to the next feature.

—

I know that for a long time our industry has believed that to be effective, tests must be independent. But in agile, we value the customer’s opinion as the final say, not some techie’s. So lets allow our testers to instead work with the team and help us move forward with the confidence of knowing that it is within our ability to deliver success.

Where does your project put its testers?
—

» See Agile Testing by Lisa Crispin and Janet Gregory for more information and wonderful ideas on testing in agile.