Let me give you all a brief description:

So we have a client which has left the company. They refused to renew their project. The primary reason was that during the course of time, the client was with the company the overall quality metrics were always red (below expectations). There were lots of defects in production. And even after a second re-implementation from scratch, the quality metrics were not up to what the client required.

Since the client was a major source of revenue (one of the big four corporate houses in their field), there was a lot of noise among the leadership as to where and why did this client quality metrics went so wrong.

So while brainstorming, about what went wrong, one of the team members suggested this point: That over the years, the QA/Testing team dedicated to the client was never stable. Team members came and went and this client became infamous as a dumping ground for somebody who is either out of work (on bench) or who has failed to meet the performance expectations (though it was not the case always).

So this brings a question to my mind: Does the stability of team members affect the overall quality achieved?

I know that this is an opinion based question and we kinda hate those types, but I am looking for some view points on this matter.

  • 2
    Of course stability of the team and skills of contributors matter. How it could not? You get what you pay for. What else is new? Looking forward for any war stories in the answers. Commented Oct 27, 2015 at 16:44

5 Answers 5


The importance of stability in QA

I have seen this over and over again. My current company has a rather high turnover (I am actually leaving it in 3 weeks). The turnover has primarily been on the development side with some on the QA side.

Turnover on the development side is tough but with strong knowledgeable QA it can make it easier. A strong QA will understand the development side and be able to bring new developers up to speed quickly. Turnover on the QA side is a bit harder in my opinion. Often times Developers do not understand the QA side, honestly everyone outside of the QA usually doesn't understand it. Usually when a person leaves, they are leaving with intimate domain knowledge that would be extremely difficult to transfer with them.

This type of knowledge not only increases the risk of an issue slipping through QA but it can also hinder hitting deadlines because a more experienced QA would know the exact impacts. By lacking the domain knowledge, this puts the new QA in an extreme disadvantage and essentially in a trust relationship with the developers to understand what the impact of a change is. This can be extremely bad.

The benefits to stable QA

  1. QA processes are more efficient and streamlined
  2. Requirements are more thoroughly checked and verified
  3. Less defects in production
  4. Easier to on-board new employees
  5. Overall lowered cost of development

Would stable QA have prevented your situation

Probably, no promises. Stable unskilled/motivated QA is just as bad as unstable QA. It all just depends. Judging by your statement, this seems like a low priority for the company so chances are it was doomed from the start.


In all honesty, it sounds like the client was actually partly to blame for this - although your company should have seen the churn in the QA department and at least asked some questions.

If both your company and the client had entered into more discussions on quality (managing expectations etc) then maybe this wouldn't be a problem.

The underlying story here sounds like a company with very poor communications, both internal and external - people being dead-ended onto a project which apparently was one of the company's main revenue streams??

And "noise in management" sounds very much like management are not open, honest and approachable too.

I think you need to look a little further afield than just the QA department - I'd be looking for a job elsewhere, I think. That company sounds like it's on a downward, management-sponsored spiral.


If there are defects in production, that's not the fault of QA. The defects were created by developers. While I think it's true that a high performing QA team can help find defects that might go unnoticed by a lesser team, at the end of the day it's the development team that is the one screwing up.

I've been a developer most of my career, and if my company ships defects that impact the customer, I've never once thought to blame QA.

That being said, if you work in an agile environment, it is the team as a whole that is to blame, not just one part of the team.


In my experience team stability can be achieved in different level.

Zero level - Define test team core Values, Mission, Goal.

Basic level - Hiring right skilled person or Hiring right fresh university students who eager to learn.

High level - Having a Right team lead and or Test manager.

Test Team lead play key role - Technical / Business, Soft spoken, Helping nature, Motivator team lead can bring more fruitfully results.

Internal hiring 40% - 60% -- Companies need to find Internal gems and give next level promotion, so people stay long in team.

Listing more to testers issues - Many companies & management never listen internal problems what test team is facing.

Continues knowledge sharing & updating - Senior people must be mentor for new people to grow others in team.

  • The question here is not how to improve the process, but to discuss how the stability of QA team is important. I don't believe your answer points in that direction in any way. Commented Nov 2, 2015 at 3:29

I think that stability - which I'm reading as longevity - can work both ways. Although more knowledgeable team members who have learned the domain are valuable... there is also the chance that they get set in their ways and don't look for new problems and new solutions.

So I would focus on things that both help address turnover of knowledge and information and in promoting best practices for all to follow so that at end end on the day the focus is still on quality itself.

This can require detailed, hands-on management to promote such practices.

I'd look to the following

  • document everything but don't write books about it
  • mentor and inspire junior members
  • create and maintain great on-boarding documentation
  • meet regularly with team members to encourage involvement
  • pay well
  • provide a space for and listen to feedback
  • use tools to track work, features, bugs and tasks
  • stay educated with course and conferences

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.