Is software testing really a service?

I’ve always subscribed to the concept that the testing we offer is essentially a service to the business. The business engage with the test team for our services. I hear this phrase mentioned a lot mainly around how we can improve our service, or how best to manage this service and how we can maintain our independent service. We, the test team, maintain our impartiality and cast our critical eye on the software. We are a service. Or so I thought.


It sounds good in theory and I’ve previously worked in a service environment first hand. But I’ve come to realise recently that the service mentality is not helpful. It creates a mental divide that often creates a very real divide between the rest of the team and the testers. It re-enforces the dreaded wall concept and it somehow marks testing out as being special, different, aloof. And the divide, in my opinion, is not a healthy way of looking at testing.


I feel we need to take a step back and look at the picture from a higher level. If we do this, we see the whole development team, including testing, as the service? As the service to our business?  To our customers?


As development teams consist of programmers and testers (and other roles such as PM etc) the notion of the test team being a separate service seems fundamentally flawed. At a basic level each and everyone one of us are in some form of service agreement with other people. Our friends, family and colleagues for example. And there is no refuting that at all. That is everyday human transactions. But I genuinely believe that describing “testing” as a service is misleading people and creating a barrier that isn’t positive.


No matter what methodology is being used, it makes more sense to think of the project team as a whole? As a whole unit delivering value? As a group of people brought together for their skills and ability to deliver good software?


Are we really bringing together each service (BA, PM, programming, testing, support, documentation etc) to create bespoke project teams made up of individual service agreements? Maybe this is why some teams get so hung up with documentation, sign offs, gates and criteria. And yet in all my time working I’ve never heard any other department refer to themselves as a service. (no doubt some people have..let me know). So why must testing?


I can see why I used to believe software testing was a service. It’s because testing was hung on the back of the project, something that happened during a certain time period, something that required a special build to be handed over and then thrown back, something that was troublesome, independent and impartial, something that happened as a phase and not as a principle. And it makes sense in that environment. But is is helpful?


As more testers are being involved at the start of the project, maybe the service concept will give way to the team concept. Maybe people are realising that the testers are no more important than the programmers. Or that the support team have just as equal input to the project as testing or project management.


I’ve seen the dangers that testing as a service can bring; the late delivery to test, the lack of test input throughout the project, the poor quality release, the throwing over the wall, the communicating through the medium of defects, the blame culture, the metric wars and the late deadlines and poor quality releases.


I’ve seen the masses of documentation, the quality police mentality, the gated entry and exit barriers and the general lack of communication between departments. I’ve seen months wasted on up front design only to find the pesky testers destroy it through late in the process static analysis. But most importantly I’ve seen the thousands of forum threads from irate testers berating the project team for all of the above. I’ve met them. I was once one of them.


And before my critics complain I’m about to go on extolling the virtues of agile methodologies, this has nothing to do with agile, wagile, waterfall, fragile, lean, mean, bream or any other methodology we can name. But it has everything to do with people. More importantly, how these people integrate in to a team. Sometimes the blame lies with management for building silos, sometimes with testers for enforcing them and sometimes for all of the team simply conforming to testing norms.


But anything we can do, as testers, to break down the barriers between groups within the team should be done. Right? We want to be involved, we want to be asked for our opinion, we want to be delivering good software, we want to be part of a great team, we want to be respected and trusted. Can we truly achieve these things by being a service to the rest of the team? By marking ourselves out as special, different, distant, contracted in?


I’m not saying we should conform, be walked over, pushed aside and devalued. We can still be impartial, critical, questioning, creative and communicative. These very traits are why we’ve been selected to be part of the team aren’t they?


And yes, agile does try to re-enforce this team mentality where quality is shared, testing is done first and team collaboration is key, but it doesn’t mean to say this is not possible in other methodologies. I’ve seen waterfall teams pull together, utilise testers right at the start, build a team including testers and ensure communication and team moral stay high. And they have succeeded.


But if we look at the testers from afar we can begin to see how we are just part of the team. Nothing more. Nothing less. We posses a skill that the team needs. A skill that compliments the rest of the team. A skill that is testing.


The customer and business want a service that delivers great software; and that service is the team, of which testing is just one part.


I know some people like the wall. They like bragging about finding 100’s of defects in the first week. They like seeing the rest of the project team squirming around trying to explain why it’s all gone pair shaped with 3 weeks to release. I’ve worked with these people. They live and breathe negativity. They strive in a blame culture. That’s what gets them out of bed in a morning.


But for me, it simply doesn’t cut it. The failure of a project is a reflection on the team behind it. And that absolutely includes the testers.


A team is a team. And on the face of it, it needn’t be more complicated than that.


This is why I see the testing as a service to be flawed. It assumes we are outsiders and separate and that just feels wrong. We do have specialist skills and thinking, but we are not outsiders, impartial or distant. We are part of the team.


And if we must keep using the term service to describe our role in the team, then we need to fully understand that many of the problems we spend hours griping about come directly from this view of ourselves….


Disagree? Agree? Not bothered either way? Let me know why in the comments. I’m open to fine tuning this view, building on it. Let me know.



14 thoughts on “Is software testing really a service?

  1. Completely and 100% agree – the “us & them” mentality is about the most corrosive thing possible. The best testers are ones who find next to no bugs, since that means they’ve worked in a well functioning team that has strived for quality throughout the entire process (of which the testers will have been a critical component).The traditional model of a bunch of coders who throw their product “over the wall” to the test team, who then delight in proving how crappy the code is is close to laughable. The only reason it’s not laughable is because it’s precisely how so many software companies function. The sooner the focus shifts to one of a single team who are all pulling towards the one goal (to delight and give value to the customer), the better.

  2. Steve,Absolutely is how so many companies operate and it’s quite scary. It seems the testing community do sometimes look at testing and not the bigger picture.Thanks for commenting.Rob..

  3. Nice post Rob.Spot-on – the “them and us” mentality is back in the bronze age of testing… nothing to do with any methodology.I’m intrigued to hear more about the bream methodology (I laughed at myself as I googled for it 😉 – just in case…)Cheers,/S

  4. Simon,Nice – I wondered whether anyone would look up the bream methodology.Problem is, the Bronze age of testing is so incredibly ingrained in some people and some teams.Thanks for the comments.Rob..

  5. Good post Rob. Seeing everyone involved in delivering the product throughout its lifetime as part of one team allows us to improve processes and work together efficiently and with the same message. It means that we can achieve quality throughout and give our customers a great, coherent, experience with our products.

  6. Stephen,Absolutely. It’s the customers that matter. Not the way we see ourselves as a service.Thanks for the commentRob..

  7. I DISAGREE.There, it had to be said. In my opinion a tester joining a development team (note the wording here) is there to deliver a service. Some tasks can be review of documentation, requirements, creating test plans, writing test scrips, exploratory testing, highlighting issues found, etc. All of these activities to me are a service. Imagine the tester is not permanently employed but a Consultant. Wouldn’t you say this Consultant isn’t there to deliver a service, ie all of the above?Now, let’s have a look at another group of people in the development team. Let’s say a Consultant is asked to come in and advise on the architecture and design a GUI for a new application, then start coding it. Is that a service? In my eyes there’s nothing different between these (service) tasks and the (service) tasks a tester does.The only difference that I can see is that historically there was (is) a divide between programmers and testers where testers seem to come from the outside (like auditors) providing a service for the company but maybe not for “THE team”, ie programmers+PM+BA+etc. Hopefully testers are now part of THE team. And still continue to provide a service…

  8. Pretty much agree with your premise and statements. But this is nothing new. I’ve been doing this for 20 years at the companies and the projects I’ve worked on. I have always taken the slant that Testing is a “partner” in the process/project along with all the others. And this has been in situations where Testing was part of the R&D group and as a seperate service (in IT, but not under general control of R&D). Testing is the other side of the coin from development, we are complimentary to each other. Not adversarial.Now the hard part is getting other people to see that and buy-in to it, and work with it. That is where the “Us vs. Them” can be put in place. Break that habit and you are on your way. The principle of “team” is what is needed. Each team member has their role, but they all need to have equal say/weight in the process. When one group/person dominates then things get whacky. It is about balance and shared accountability/responsibility.So you are right, it is about people. Get that dynamic right and then the rest will fall into place.

  9. Thomas,Good point and one I considered when writing it. What about the consultants and contractors? I do see these people providing a service. Absolutely. But is it ok to speak of them as seperate? My experience of hiring, working with and being a contractor is that I’ve seen it work best when that person is integrated to the team. not plonked on a desk as an outsider. Even getting specialists in requires them at some point to join the team, unless they truly can do their task without ever having to talk or work with anyone else. Making them feel welcome, letting them sit with the rest of the team, including them in social events – this is far more valuable at making them feel like part of a team. That’s my experience anyway. In logical terms, they absolutely are being hired in as a service, but a service that sits within the team. Not someone seperate. As a specialist brought in you still need to integrate with the team, find out how things work and be valued as a team member. Right? I guess you could assume that the post is written for people who work in an integrated test team. As that sounds more relevant, but I do fear that if specialists are contracted in and not included as part of the team, then that team is missing a trick :)Rob..

  10. Jim,Thanks for the comment. I’m glad it’s not new. I would be horrified if it really was a new concept and I’m glad there are more people out there balancing the views and have been for some time. I posted the blog in reaction to the many forum posts I still keep seeing stating testers should maintain their independence, even in an agile environment. It just feels wrong. We can still do that and be part of the main team. The goal is a team who deliver good software. I like the phrase “Testing is the other side of the coin from development, we are complimentary to each other. Not adversarial.”That sounds like a good way to look at this. I like your approach. It sounds like you harmonise the team and align views. Always good in my book.Thanks for commentingRob..

  11. “At a basic level each and everyone one of us are in some form of service agreement with other people.”I agree with this entirely. I don’t believe, though, that it necessarily follows that there’s a divide, or that service relationships diminish one side of the service or another. The divide can certainly be there if you choose it to be, but to me, it need not, should not, be there at all. I can serve someone without erecting a wall. In fact, a wall would get in the way of my ability to serve them. I can serve a “them”, but I can serve an “us” just as easily; more easily, even. Moreover,as I’m providing services to the team, I hope that others are providing service to me, too.I do see people who take a divisive perspective, but I’d suggest that such people usually don’t see testing as a service. Instead, they seem to see their roles as security guards or police forces. Often these people are frustrated, because they aspire to an authority that they can’t achieve unless or until they’re product owners. The frustration often comes out in their discourse, and in their descriptions of themselves and others on the team. Such people’s rhetorics tends to sound angry or indignant. They’re “evil”; their goal is to “expose incompetence”, to “reject unacceptable work”, to prove that others on the team are screwing up. Rather than providing information, they “fight” for quality, when, at best, what they’re fighting for is their perception of quality—a fight that they’re bound to lose when business priorities trump their own. Often they call themselves “the advocates of quality”, which is a tacit dismissal of all the other people on the team who are also advocates of quality.Apropos of that, there is a heuristic that I often use, the “a” vs. “the” heuristic. It goes like this: When you hear someone (including yourself) using the word “the”, translate it mentally into “a” (or “an”), and see what happens for you. For me, this affords the opportunity to see things from a variety of perspectives. “The” problem, at that point is a problem, which implies that there might be other (more important) problems, or that a problem for me might not be a problem for others.All the best,—Michael B.

  12. Michael,Superbly put, as usual. I like the idea that a service cannot be offered with walls of divide. I guess I’m rejecting the use of the word ‘service’ to mean all of the bad things you have mentioned. I’m rejecting it because people are hijacking it to mean different, aloof, separate and distant.For me, it’s more useful and helpful to look at a team as a whole, including contractors, consultants and specialists. i.e the team as the service.I like the heuristic. I’ll give that a go next week and see how it works out for me. I think (know) you are right :). The environments in which people are “fighting for [is] their perception of quality” are the same environments where I “believe” testing as a service exists. It could be that I see ‘services’ rather than ‘people fighting for their own perception of quality’. It could be that I lump these people in with the testing as a service theory.But I guess I want to see the service description used with care. Some people do not realise that testing is a collaborative event because of this word. Instead I see them using the service description as a means to put up the wall, to defend quality and take on the role of the Enforcer. And somehow this is the impression most people have of testing.Always insightful to see your replies Michael. Thanks for enlightening me to another way of seeing the ‘wall’.ThanksRob..

Comments are closed.