All too often the software test team can have a bad reputation in any given organisation. Over the years i have heard the same reasons as to why the test team are not appreciated in the same way as developers are within the delivery of a project. Here are a few that come to mind readily…
- Frequent defects detected in live, “why didn’t the test team catch them, what are they testing?”
- The software development teams often spend significant effort in tuning their processes, striving for perfection. – “If the development processes was perfect, testing wouldn’t be needed”.
- The need for a testing team is a constant reminder that the development team is not doing its job correctly. “we need to tune our processes and strive for perfection”.
- Testing consumes valuable resources, people, time, even desk space. However the product is unchanged (no features are added) by the test team, unlike the development team, so the perception is one of no value being added by testing.
- Test is invariably the bottleneck to delivery, more so when the product is new.
- Test can constrain the design (“how can we test that”) and where automation is used it can use up valuable development effort in lines of code that the organisation can not capitalise upon.
- Testing the same thing multiple times (unit testing, systems testing, UAT) in the process is a waste of time and resources, but there seems to be no easy way to avoid it.
- Testing teams continue to test, while collecting test data, but they do not use the data to improve the product once it is collected. The management of that data also consumes resources and time, and may require investment (test management tools).
- The test team often aspire to make the development teams work easier, but they often struggle to keep up with new technologies. “the testers cant code, they cant do automation”.
This isn’t just my opinion. Test teams really do get little no love, but why? Rex Black wrote in an article on eWeek.com –
I’ll start with how not to develop a test team. Many IT managers—especially those who have never seen professional testing—assume anyone can do it. They try to get the job done with junior programmers, users or business analysts. While these people have a role to play, by themselves they do a poor job of testing.
Rex touches on something that is important, test teams get a bad name because there is belief that testers just “play” with software until they “break” it, and because “anyone can do it”.
Andrew Faust has this to say on his blog about software testing at Microsoft:
In many companies they [the testers] are seen as the guys who couldn’t cut it as developers. They’re often second class citizens. They aren’t consulted on design, they are far outnumbered and they are seen as an added expense that constantly delays the release of a product.
Wow, “couldn’t cut it as developers” and yet we charge them with checking the developers work?
And when Ara Pulido was calling for testers to come forward can create an Ubuntu Test community she noted:
Software testing is generally seen as the poor cousin of programming. While the bad reputation of testers happens in all software environments, this is more common in free software communities…
Again “bad reputation of testers”. So what are we software testers doing so wrong?
Typically the software test team that works in an organisation where these views are shared by IT management will be employed in a go/no-go process. The test team will not have been engaged in way that will allow them to continuously sample and inform the quality of the work during the software delivery life cycle, and the first time they get to see the delivery, its too late.
What i have found interesting, is that in any organisation where the test team have a bad reputation, if I suggest that the test team down tools for a period of time, say for example “the whole test team will be out for a week to attend the EuroStar conference”, everyone throws their hands in the air. The mere suggestion that the test team walk off the project is viewed with utter contempt. So paradoxically while the software testing team gets a bad name, and is viewed as not adding any value, the same organisation doesn’t want to lose them, especially if there have been quality issues in the past; the very issues that fueled the bad reputation.
So what can we do about it? Unfortunately what i have found in the organisations where the software testing team has a bad reputation, the testing team are often perpetuating the problem through their actions and also their inaction.
So, if you work in an organisation where testing is getting a bad reputation, start by getting some things straight.
- Software testers do not break software. The software was already broken, that is, it was built and delivered with the defects already in it. What the testers actually did was find the defect. Yeah that’s right, you can’t break software, within the code, its behaving exactly as its written.
- Testing will not improve the quality of the software, it can’t. All that software testing will do is inform the business of how bad the delivered software is; its mostly a bad news story. Remember, you are calling someone’s baby ugly, so show a little tact.
- If the software testers only follow the scripts, they will only ever find the same defects. Think about it. If the test doesn’t find a defect, was it a good test?
- If the software test team only ever follow scripts, they are only checking the software, not testing it. Any click monkey can follow a terse script and make pass/fail assertions. Better yet, automate it; computers are cheaper than monkeys.
- The software test team doesn’t approve software to go live. The software test team should simply report the risk as they perceive it. In terms of impact and likelihood. It is up to the project sponsor to evaluate the risks as presented by the test team, and make the go/no-go call.
- If the test team finds defects and the business decided to ship the software anyway, then that is their decision. Support them in that.
This isn’t an exhaustive list by any means, this is really the low hanging fruit. By changing the behaviors and displays of the testing team, and sticking to it, the test team will begin to be viewed as being more professional.
Remember, Its all too easy to undermine the professionalism of testing by using throw away phrases like “yeah sure, I’ll have a play with it and see what breaks”. That doesn’t sound like a skilled professional at work does it?