Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
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.
Thanks,
Steve.
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.
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 :-).
