How testing/QA Org should be positioned?

Question

I've worked with companies which had positioned SDET/QA org in different ways in the company. Some companies let Dev and Testers work together as part of Engineering team. Unless the goal of automation is not diluted, I had seen this model working. Internet companies generally work this way.

Some companies would create a centralized QA structure and have them working with developers. Enterprise companies which work on non-saas based releases generally work this way.

I recently heard from a friend that the company he works have placed QE as part of customer engineering and techops team. While feedbacks are important from this team - does this model ever work? Have anyone ever worked in such a scenario? He works on a product which is on the process of moving to SaaS based offering from on premise based offering.

The disadvantage I see with this model is - Customer engineering and tech ops team usually work on short term solutions and most of their day to day work may go in fire fighting when a customer escalation comes up. A mind leading QE, which had lead these teams might end up defining metrics that may not work for a long term success for the org.

How would any one see as the right way of positioning a QA org?

Answer 1

I was confused at first because at first I thought the bold intro said don't debate about separate team but then a lot of the body takes about embedding in teams. My take right now is that this is more about the separate role than the separate department.

Also "Any thoughts" is not good for our site. I would suggest rewording that and scoping down the currently very open ended question.

To answer what I see as my take on the question (which in itself shows what an issue we have):

You have this paragraph:

I recently heard from a friend that the Org he works have placed QE as part of customer engineering and techops team. While feedbacks are important from this team - does this model ever work? Have anyone every worked in such a scenario? He works on a product which is on the process of moving to SaaS based offering from on premise based offering.

"ever work?" Yes this is the standard model in the last 5 companies that I have worked in. It seems clear from these comments that you have not had this experience. In companies doing true agile development this is the norm from my experience.

Separarately (you have several questions here): The disadvantage I see with this model is - Customer engineering and tech ops team usually work on short term solutions and most of their day to day work may go in fire fighting when a customer escalation comes up. A mind leading QE, which had lead these teams might end up defining metrics that may not work for a long term success for the org.

The issue here is balancing development and production support, NOT how to balance development and testing in my opinion. If your development engineers have to spend a lot of time juggling production support and fire-fighting then you have different issues - and may also need more testing and testing involvement as firefighting is often a sign that you don't have enough - or the right kind - of tests.

metrics Using the right metric to measure success is also another broad topic.