Increasing Productivity #1

When I worked as a Tester, we didn’t have any kind of monitoring on our efforts; we were just left to get on with things. This meant some people were productive and did their work because that’s what they were paid to do, and others abused the system and did a bare minimum. Then one day my Test Manager came up with this idea that everyone needs to run 10 Test Cases a day in order for the team to be productive.

How long is a test case though? If each one took 40 minutes to run, then 10 would keep you busy for the day. But some can take that long, and others can take only a minute – so the metric is rather meaningless. Also, some tests often found bugs because they tested brittle areas of the system, whereas others never uncovered bugs. Some tests were fine to run with a few clicks, whereas others depended on certain configurations being set up.

The most annoying configurations relied on third-parties, so sometimes you would have to log a ticket with the Environments Team, then they would contact the third party and wait for a response. This could delay you for days.

So with a demand of “you need to run 10 tests a day”, how do people respond? Well, most people then started to cherry pick the simple tests. Tests that rely on third parties got pushed to one side, as did the tests that often find bugs (logging a bug means you need to spend time investigating, filling out the bug reports, then chasing up the appropriate developer). After speeding through 10 easy tests, people just spend the entire day chilling out. Some people ran 20-30 tests, then tried to boast to the mangers saying “look how good I am”.

People like me that actually cared about getting the release out on time would pick up the important tests. I’d be logging tickets with the Environments team, ensuring we had the correct configuration. I would be running the brittle tests, logging bugs and liasing with the developers to get the fixes. I was the one getting called into meetings, asked on why I was only running 5 tests and failing to meet my targets.

The closer to the deadline you leave things, the more chance the release will have to be delayed. Plus it’s not great telling a developer there is a bug, but they only have a day to get it sorted. It’s not great telling the Environments team they have to drop what they are doing to set up a Test Environment because you left an important test to the last minute only to find the Third-Party dependency isn’t working.

It’s almost like people forget what it is like being a Tester when they progress to management level. As my Lead Developer always says: “you get what you measure”.