Successful testers need to be continually critical of other people's work. Yet this critical approach can spill over into other aspects of our work. Therein lies the paradox within every test team. How do we prevent that continual criticality from denting our own motivation and leaving the test team dispirited? In this article, William Echlin helps us look to the bright side of testing.
I'm lucky to be working with an extremely talented test team, yet I get the feeling that we haven't quite reached our true potential. So what's preventing us from reaching it? It's not that we don't have the right people or the right skills. It's not even the test process or the project. What holds us and every test team back are issues unique to testing.
The American Heritage Dictionary defines testing as "a procedure for critical evaluation," so it stands to reason that a huge part of our job involves being critical. It's probably also fair to say that being a tester means we need to be skilled at thinking critically. Does it hold true, though, that the more critical the test team is, the more successful it will be?
Defining success for a test team is always difficult. We will always release software with bugs. We will always wonder if our test coverage was as thorough as it could have been. Yet if we are to accept these as part of our job, how do we know if we've been successful? These issues can make it difficult to create a successful test team.
It can be difficult and demotivating to be part of a team that is constantly critical. Test teams by their very nature are more critical than complimentary. A tester has to look for all the negative aspects of the software. The problem for many testers--and I'm no exception--is letting this pessimistic, critical attitude creep beyond the software you are testing.
Take, for example, a great test team I worked with a couple of years ago. We were working with a company that had decided to relocate down the road to a fantastic new building on the edge of a nature reserve with all of the facilities you could ever want. On paper this move looked fantastic. In fact, in reality it turned out to be fantastic. But reality wasn't going to stop this test team from pulling the idea to pieces. Out of all of the teams being relocated, the test team was by far the most critical about the move.
This is where the paradox lies. If your test team is positive, upbeat, and happy, you can almost guarantee that you've got the wrong people. You need a team to be critical, judgmental, and, well, negative. To be a good tester you've got to be pessimistic ("I know bugs are still in there somewhere"). You've got to be negative ("I'm not sure dev has implemented that functionality quite as well as they could have done"). If your testers are saying things like "I'm sure there aren't any bugs left," then you aren't dealing with a successful test team.
I've worked with a lot of talented testers, many on par with some of the most talented developers I've known. But when these testers lift their heads from the software, they can find it very difficult to remove the critical hat. They criticize project management, development, managers, tea ladies--you name it, they've got something critical to say about it. You can't blame them. They need to be critical. They're good at being critical. I mean, they're paid to be critical.
Perception of Success
The development team has one clear goal: to create a piece of shippable software. It may want to add just one more bell or whistle before shipping, but in general the goal is achieved once the coding stops and the product ships. For testers things are much different--it comes down to the question of when enough is enough.
Our goal is