Mathias Rosenthal - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Is centralized testing key to enterprise software testing?

Is there a place for a centralized test team in enterprise software testing at a company that has adopted Agile methodologies? Read Agile expert Matt Heusser's answer.

I just got back from the 2014 Agile Conference, and you are not the only person wondering about the question posed above. My short answer is that it's very hard to be effective with this setup, but some enterprise software testing might be done with a central test team as a transitional step in an Agile adoption. Some functions, like performance and security, might be tested by an outside group.

Now it's time for the long answer.

Testers on the team, not in a testing department

Keeping testing off the team creates a handoff between teams and forces the central test team to provide services to multiple customers. All that restricts flow, making testing the bottleneck, while at the same time limiting the expertise about the product that testers would acquire if they were dedicated to one team. Having a separate team also can create an us vs. them mentality, which hurts teamwork.

All those scenarios explain why a separate team is a bad idea for enterprise software testing, but the thing that keeps the development team from being Agile is that the team can no longer develop the software end-to-end themselves.

Keeping testing off the team creates a handoff between teams and forces the central test team to provide services to multiple customers.

The principles behind the Agile manifesto include the following: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily through the project … The most efficient and effective method of conveying information is face-to-face-conversation."

Doing development in Poland, Iceland or the United States, then uploading your code to a test server and notifying someone elsewhere on the planet that the code is ready to be tested -- that just doesn't sound like Agile.

In fact, it is likely that the people in Poland, Iceland or wherever have developed their own internal test team. They also likely have lobbied the business stakeholders to ignore you and skip enterprise software testing.

A few exceptions

Most of the discussion above is about functional testing. I am generally opposed to strictly enforced handoffs and in favor of including testers as a collaborative part of each development team. It is, however, possible that your company is structured into very small teams, say, three to four people, and that those teams might not have the background to do the security, performance or other specialized testing you need. Likewise, some older organizations have complex integration pieces that need to be coordinated just before release. I can see how some of these highly specialized roles might remain independent while providing services to other teams, but hopefully those services would include an educational component designed to help the teams take over the work themselves.

There is also an interesting question of how wide the Agile team should be. Keeping testers out is probably too narrow, but most Agile software teams keep sales and human resources management (HR) out of the team. In many cases, sales and HR use traditional, non-Agile business processes.

The bottom line is that once an organization adopts Agile methods, IT teams should continue to keep them growing.

Next Steps

How test managers measure test team effectiveness

Managing a software testing team while cultivating talent

Use test charters to enhance test team efficiency

How do cloud tools reduce enterprise software development costs?

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Have you been a part of a centralized enterprise software testing team? What do you think of such central teams?
I've had both ends of the spectrum, being part of a large team of testers earlier in my career, and then later in a video game company that hired a variety of testers for projects, and I've also worked as a lone gun for much of my career, dedicated to a project or a team. the centralized team claims to have the benefits of a series of specialists, but those specialists often work poorly together, or work in isolation from each other, so the benefits of their expertise is leveraged in a very narrow fashion. By contrast, the lone tester who tries to be a jack of all trades tends to be limited to a thin slice of each areas that they work in, even if those areas are pretty strong (let's face it, no one is an expert at everything). I've seen some companies that come close to finding that middle ground (I work for one right now that does a pretty good job in that regard).
I run a centralized Test Team, small in number, whose members are also fully fledged members of Sprints and can also act as Scrum Master if need be. I do this to ensure there are a thorough testing input to Sprints and any change lifecycle (CLc). Our Test strategy makes use of System SME's to be involved in the testing of changes so that we have good Usability involvement as early as possible and therefore I don't need to have an expensive army of testers to manage/pay for. My Testers are involved in both hands on and be a testing SME on a change to ensure Testing needs are not an afterthought across the E2E lifecycle. I'm cautious of testing only within Sprints becoming too isolated in their own Sprint world'. The Testers need to keep abreast of changes in the testing profession, make use of lessons learned from other Sprints/CLc's and be reminded of their duty to protect the organisation (Risk Analysis) so are not just there to validate a change. A centralized Test Team approach provides corporate safeguard through standardization but does need to be flexible (Agile) to confidently test a change via the different CL's. Not every change is Sprint driven!