Four ways to reduce software testing cost without sacrificing quality
By: Matt Heusser
Tip one: Manage by walking around and listening
First, let's walk around and actually look at the testers. Are they at the keyboard, actually working, running the software, installing it, making plans and updating them, or are they doing ... something else?
The something else is the killer.
It might be supporting some other application, troubleshooting the current production version, waiting for a build, waiting for a server, waiting for a decision maker to decide what the "right" thing was for the software to do. This tends to manifest in lots of time in email, or hanging out at the coffee pot, water cooler or someone else's cubicle, or plenty of web-surfing.
The point is that the tester is blocked.
These blockages don't just slow down the project; they turn the tester into a very expensive paperweight.
So I want to get into the ranks and find out what is really going on.
Some of the time, the problem is systemic. The organization doesn't even realize that many of its people are sitting around, waiting for work. When it happens, people often feel they need to hide these moments. After all, they are embarrassing and, to the hatchet man, being not busy indicates redundancy, and that can lead to layoffs.
As a manager, I want to find the systemic blockage and fix it. I will work with the tester to figure out either how to knock down the obstacle or to bring the problem to the organizationís attention so it is not mislabeled a test cost. Another option may be to redirect the tester to work on something more actionable.
One of the biggest conclusions I came to when researching the book was this idea that "three strikes and you are not out!" There is always something a good tester can do to influence the outcome of the project. Even if system forces are keeping the testers down, it is usually possible to make some progress with a strong, can-do culture.
The second aspect of culture is that some folks might not be blocked, but just don't want to work that hard. If you do management by walking around, say, two trips around the office every day, and see the same people not working ever, and find out they are not blocked, you've just identified your low performers. You can take any traditional corrective action, but if it were me, I'd start with the managers. How did this situation happen?
Tip two: Identify and remove barriers to high performance
Once it's possible for our testers to actually make progress, we'll take a look at how that time breaks down. Are they actually doing testing, running experiments to see if the software will work, or are they doing other things? Going to meetings, writing documentation, setting up test environments, loading databases with test data so the tests can execute, these things are incidental. They are not essential to the task at hand.
If possible, I'd like the testers to write down how they spend their time for a week or two, to break the work down into major categories. Examples include testing, setup, documentation, meetings and administrative tasks.
If the testers are spending a great deal of time in documentation, one thing they are doing is not testing. This is also true for setup and meetings.
It might not be a good idea to eliminate meetings, documentation, and setup -- but it is not uncommon to find a team spending 80% of its time doing other things besides testing. Get that down to 60% -- just take a small chunk out of it -- and you could double productivity without having to "adopt" a methodology, buy a tool or send anyone to training.
The trick is to see those things as waste and eliminate them. That may take some willpower, some decisiveness and some ingenuity.
I said you could do it. I never said it would be easy.
Step three: Speed the test process
Step four: Eliminate excess work-in-progress inventory
... to read more articles, visit http://sqa.fyicenter.com/art/