I've been tasked with changing the focus of my team from a "can do everything" team into one that is more service orientated, i.e. we can provide the framework for your testing rather than being there to perform the actual testing. This change in focus is to support internal delivery teams.

What I'm asking is has anyone been in this situation before and could they pass on any advice or links to articles to give me a pointer in the right direction.



  • Is the transition from manual to automated? Or is it from your team to separated amongst the other teams? If it's the former, I hope they don't expect automated testing to completely replace manual testing!
    – corsiKa
    Commented Oct 18, 2011 at 16:27
  • The transition is from a "can do everything" test team to a "only do what you really should be doing" test team. Currently we don't use automation due to the diverse number of applications we support. Almost forgot, we will be staying together but may be working on multiple projects at the same time.
    – devonps
    Commented Oct 20, 2011 at 15:24

2 Answers 2


I think staging your removal from the actual performing of testing will be important. You will want to make sure that the standard of testing doesn't drop with the removal of your team.

It will take time to hand over the test execution process and pass on experience. You might want to gradually remove your team one by one and monitor the level of testing. You will get a feel for when you are ready to remove more team members from both the team(s) that you are handing over to and the feedback for your team members.

Remember that you are going to be removing experience from the test executing process and that will take time for whoever will be preforming your testing to get that experience.

  • A good answer there Stuartf - thanks. Reading into your answer I see a period of coaching, mentoring and education happening with our delivery teams.
    – devonps
    Commented Oct 18, 2011 at 15:40

I have worked on teams as a tester and worked on teams as a tool developer. Stuart talked about the transition so I won't talk more about that, but I think I can add some helpful information on what to expect and what you can focus on in your new role.

You are going to be a development team producing products with real customers. The sooner you wrap your head around that and start acting like a real product team, the easier this will be for your customers. Make sure that you treat your tools as products, create a schedule for fixing and deploying those tools, create high quality documentation for those tools, if you haven't already - decide how you will handle support. Do not underestimate support costs and time spent in bug fixes, even with a handful of customers it can end up eating away a lot of your time, especially if you have no process surrounding it. If you have multiple team members, you may even consider having one of them "on point" or tier 1 for support for a week at a time to try to avoid randomizing people and allowing them to do their normal work. One helpful thing is to have an archive of questions and answers, whether that is a forum or a searchable DL, etc, it is very important to have this so that you are not answering the same questions over and over again.

Be prepared to say no and to justify your priorities. Now that you have multiple customers, they are going to have their own agendas and will push to get their high impacting issues fixed. A good way to help with this is to get representatives from each of your customer teams to meet periodically and be involved in the planning process, give you feedback and bring info from your team back to their respective teams. This will allow them to get consensus on which bugs and features your team should focus on. Keep in mind though that fixes to infrastructure that may have small impact on your customers but a large impact on your team still need to have priority and you need to be the advocate for those changes and back them up with data around why they are important and why they should take precedence over whatever other features your customers may want.

Lastly, it's easy to fall into a mode where you create tools for everything your customers would ever want and before you know it you're suffering from feature bloat. You've got a bunch of disconnected tools that do "everything" but they are confusing, hard to find, hard to figure out, etc. Your team needs to be adamant about quality. The same as in a real product team, it is better for your team to create and maintain a few very effective elegantly written and maintained tools than to have a bunch of poorly written and maintained "quick fix" tools.

Hopefully this is useful information. Good luck :-).

  • I'm not sure if you've misunderstood my original post or if I wasn't clear enough...but my team will not be moving towards a development team producing products with real customers. As a dedicated test team that delivers on a daily basis we are now being asked to look at the larger delivery lifecycle and see where can make a difference, especially upstream - hence the phrasing of my question. Additionally the nature of our environment and desktop estate means we cannot solely rely on using tools to deliver our testing.
    – devonps
    Commented Oct 20, 2011 at 14:21
  • Perhaps I did misunderstand. It sounded to me like your team was changing roles into a team that supported other teams, but did not necessarily test the products yourself anymore. I assumed that by "support internal delivery teams" you meant that you would be creating tools and processes for them to use and follow.
    – Sam Woods
    Commented Oct 20, 2011 at 20:02
  • lol - seems my translation engine is having a total misfire this week, Sam you were correct as that's exactly what we are attempting to do, sorry for any confusion I've caused.
    – devonps
    Commented Oct 21, 2011 at 8:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.