Possible reorg to put QA testers in Dev groups

After years of being in a separate QA team, there is a plan to move all of us to be a part of Development teams. We have been working on specific projects, but often straddle different teams for testing integrated systems or perform deployment tests. My concern is that although the message is that we are moving testing to the left, there still seems to be an emphasis on QA being responsible for all quality, to the point where Developers don’t really create efficient tests. I am wondering if I will be burdened with more work.

Another concern is that I haven’t been asked if I want to participate in the reorganization. It seems like it will just happen, and the person I really like to report to will no longer be above me.

My questions are:

  1. Have you been through a reorganization like this?
  2. Do you have any tips or advice to how to make sure we are part of the team and not doing all of the work?
  3. Should I ask for a job description since my job will be changing?

Yes I have been through this and multiple variations of this.

Mostly positive results particularly in terms of team ownership of quality and quality assurance rather than a separate group.

Some people argue independent test is better, in my experience that’s meh, testers on the team just need think independently at times to get the same result.

I recommend maintaining an autonomous test guild which is about learning, knowledge sharing and craftmanship. Testing is a deep skill area and still needs developing rather than a generalist role.

Shift automation ownership to team with developers taking the lead was one of the most positive steps of combining the teams, testers available to assist but it was not an afterthought.

Rethink what testing is all about, with joint team ownership you can test ideas and designs at the start of the project, propose A/B test hypothises that allow team experimentation, encourage better testability, push for better analytics features to be built in etc etc. The key things are that these are all team things that when the testers are separate its almost futile to drive improvement.

Consider increasing the developers testing skills and perhaps transition the testers over time into more of a coaching role, this helps with the team ownership of quality.

Similarly its a great opportunity to pair with developers building more technical skills. You may also find that your good automators can transition into product coders who can also automate which is ideal.

Because its one team, any blame game crap should also diminish.

Okay so most of the above is maybe best case scenario, so of these transitions just go haywire.

Testers seen as owned by dev lead who gives them work that nobody else wants, i.e they lose their authority.

Good exploratory testers forced to do average automation in the name of team utilisation.

The team tries to maintain the status quo but under a new structure so nothing improves apart from a reduced sense of value.

One other side effect I have seen was that the need for as many testers as we had reduced, that can be scary but it was fairly natural in my view. Tended to end up in the long run with fewer but more capable testers with some coaching skills.


Some of the positives for me I mention above may be worth flagging as goals before the change is made, at least that way you will get discussion on the benefits of the change which is often glossed over with these changes.


Not going to lie, but it might. There is nothing more annoying than a developer who doesn’t care about quality. On the other side you might actually have a chance to show them why testing is important and show them from a closer perspective why testing is important and why quality is the job of the entire team and not just the tester.

Yup, the devs didn’t think testing was necessary until we were split into teams and then they realized, hey it’s actually quite nice + they received faster feedback, which made them program better code since most bugs were already found in the analysis phase.

Delegate :stuck_out_tongue:
Could you elaborate a bit with “not doing all of the work”?

Part of the team as a tester is sometimes a struggle and sometimes heaven, it depends on the mentality & maturity of the team. You could always bake them a cake, I personally did this and it does help! :stuck_out_tongue:

I would ask them what they expect you to do in the team. Then they might just answer with click some buttons and then you can elaborate your testing skills & management skills on how things are really done. Since most organizations & dev-teams have no clue about how te sting works.


Your Resistance is flagging.

Hi Jeanne welcome back to the MOT, I would not worry, here is why.

  1. Yep, I’ve not been a tester for that long, when I started most companies had only just started rotating towards having testers embed into teams, because quality is a team effort after all. Agile had told us all that testing is everyone’s job, or rather it had told us that quality is a mindset, not a single step in a process. My second tester job was in a company that was still stuck in the QA team model, and at some point we too moved to having QA as a thing that happened in the dev teams, it was great. Those were my best years as a tester, being close to the coalface has advantages for quality. So in my current job when we decided to go back to putting all QA in one “team” I had a nice chat with our engineering manager. I told him why I did not like it - I also told him I would support the move as an experiment. I suggest you have that exact same kind of conversation. Ask about how we plan to measure the effects of this and which metrics we already have that can show us this will approach has worked.
  2. Do support the decision, but always view it as an experiment and observe the effect it ends up having. In practice it will mean that developers will start to throw code over the fence. That will in turn create release cadence issues which will force a left-shift where developers will soon be forced to write their own component/integration/system tests because the test team are getting overloaded by huge late drops of features. This might cause other bottleneck type problems for the OPS team… since the OPS team are often very closely sharing resources with QA team. Your exact outcome may differ, however in my situation it worked brilliantly for one reason. The new QA team did push back on product features that had low testability, in fact the lack of test hooks in code happened the instant they dropped all testers into one team. We had to raise a lot of “testability” bugs. This forced devs to write some of their own tests, and now everyone gets along very well. I hope this happens for you. Oh, and the new QA team, well , surprise! Part of our job is now to drive the Integration OPS environments. So for me this has worked.
  3. Yes, however be sure to remember that job descriptions are just pieces of paper unless you work in a 1000+ employee company they are not useful in anything outside of pay grade negotiations, so I would advise you ask for a “review date” to be pencilled in so that people can have time to write a proper accurate job description instead of just rushing something out now. As a tester, you should always seek to be writing your own job description if you can.
  1. Yes, several.
  2. Talk with the person you report to. They may have insight into what is happening, and how to look after your interests.
  3. See #2 above.

Did management say why they plan to reorganize, what their goals are, etc.? If that’s clear, the staff can help realize the goals for a successful reorganization. Either way, you will learn new ways of working in a different management structure.

There’s an old saw that groups organized by projects do the right thing the wrong way, and groups organized by functions (development/test) do the wrong thing the right way. Like most adages, there may be some truth in it, but not always.

Sometimes when management starts a new development program, they recognize there are unknowns they can’t anticipate. If that’s the case, organizing by project (not by function) may offer flexibility to “do the right thing” regardless of training and labels.

Or maybe it’s another reason entirely. See #2 above.



@jkilliankk I hope everything sorts out. As many points out, it goes back and forth what goes where.

If you focus to be part of a delivery team, be that. If you prefer to coach & enable, there’s a place for that too.
It’s one of the lessons from the Team topologies framework / book, for those interested.


Thank you to all who responded this is really helpful.

1 Like

Curiously I’ve worked in 2 companies that has undergone this change but for both of them I was in different roles at the time (design & dev). However I have worked in both environments and am currently the tester in development teams for a few years now. I think that it can be much better when you are in the development team. It helps break down the “us and them” style walls that can exist and I felt more involved in the process.

Quality does need to be a whole team effort. Perhaps that is something to raise with your manager? When you are in the team then there are things that you can do. Ask and challenge about unit test & dev test coverage. If you have retrospectives and things aren’t going well, flag it up.

Are you implementing a methodolgy like Scrum or Kanban? If that is the case then your team should be looking at the flow of work and if there is too much on your plate, they ought to be picking up the testing. Since my current company changes its ways of working, I’ve definitely seen developers pick up more and more testing (including when I was a dev, which is what reminded me that testing is great!)

I don’t think that I’ve encountered developers getting lazier or sloppier as a result of having me work closer with them. If anything the opposite because we get on better than we would have in separate teams plus the devs have learnt from working closer with me. They would rather be moving onto the next work item rather than fixing bugs so the test.

Ensure that when your team is planning work, it is as a team with you present. If that isn’t happening, bring it up with your (new) manager or at retrospectives. Your voice will become valuable as you’ll be able to identify risks, flag up testability and get the team thinking about quality before a line of code is present.

I’ve also ran a few “brown bag” sessions to try and help guide the devs in being better testers of their own work, plus when testing other people’s work.

That sucks. I’ve been moving between teams a lot over the past 2 years and have also had manager changes as a result. My previous manager was the best I’ve had so it was pretty disappointing to change. However another way to look at is that you’ve got a great ally in another team.

I wouldn’t expect that this will be necessary. Perhaps you could chat to your manager to see if they have a new standard spec for recruiting that you can look over.

So to wrap up, this could be a real positive - especially if you are able to successfully become “one of the team” rather then merely “the QA”.


Entirely depends on how the appraisal system works. If it’s at all goal or task-oriented, yes. If the company has a more holistic way of performing staff appraisals (reactions from colleagues as well as line managers), you may not need a new JD.

1 Like

Do you have any tips or advice to how to make sure we are part of the team and not doing all of the work?
Should I ask for a job description since my job will be changing?

Probably be a good idea to find out what the new development/work process will be within the teams after this reorganization. You might be able to gauge how things might be if you are familiar with the developers and the dev teams.

  1. Have you been through a reorganization like this?

Yes, it worked out ok, and I got closer collaboration with the developers in testing new features and having them fix bugs within the same development/sprint cycle. Also collaborated with the developers for automation support in code for things you can’t easily do with Selenium without adding in some extra backend support (i.e. 3D-ish graphics manipulation).

However, would like to point out the reorganization I experienced was interesting as well, not all of QA was split up. Part of QA split to be with devs for testing new features that will go into products, while some QA was preserved and later expanded for handling release/regression testing of existing features + any new features that are added into release for testing as a whole. After the split, the dev teams would hire or replace their QAs that were in their team as needed depending on resourcing.

I think having QAs as part of dev team is good, but you probably want a separate (small) QA team still to handle the regression & overall release testing, same way as their is usually release management dev team for handling the builds and deployment of releases.