For a lot of roles in a development team it is pretty obvious how these roles are invested in the quality of releases of their software. Developers who accidentally write bugs know that when the call comes they'll have to postpone what they are working on and get to fixing and quickly deploying something. Manager-types see their planning go down the drain and risk having to do damage control on escalated calls from angry customers. Because of this these people have some serious motivation in making sure the software is as problem-free as can be, aside from their general professionalism and attitude.

There is one category where I cannot easily come up with ways they are vested in the releases and that is the testers. There are examples of companies where code quality and bugfree releases suddenly became very important to developers when they themselves started to be on-call for nighttime and weekend support. I won't say they became more professional developers, but their attitude surely shifted because they started having a more vested interest.

But how are testers, aside from attitude towards their work, vested in the releases they test?

I'm not looking for a way to place blame on testers or developers and yes, I do realize that a professional attitude goes a long way but it is not THE way. Let's look at this another way: when somebody feels like throwing up, you can quickly grab a bag for them, or can just let them throw up on the floor and clean up afterwards. I'm pretty sure that everybody would go for a bag because it's just easier to not have to clean up. But when it's not you doing the cleaning, why should you care what happens?

  • possible duplicate of Who is responsible for defects found during development?
    – gnat
    Apr 30, 2015 at 14:55
  • It does not seem the same to me imho. From decades of personal development and qa experience I see them as related but distinct questions. Apr 30, 2015 at 15:34
  • Your question is mostly related to: organizational behavior, cultures and values, motivation theory, reinforcement theory, observational learning, and so on. Part of it may be pandemic to corporate environments (not limited to software development), and might be suitable to ask on Workplace.SE. Quote: "The Workplace Stack Exchange is a question and answer site about the workplace and other career-related topics. It is for members of the workforce to get answers on topics such as ... (omitted) ... professionalism within the Workplace."
    – rwong
    Apr 30, 2015 at 18:44
  • @rwong as currently written, it would likely be closed as "seeking advice on company-specific regulations, agreements, or policies" over there
    – gnat
    Apr 30, 2015 at 19:37

5 Answers 5


You mean, aside from the whole "giant production bugs leads to QA people getting fired" invested?

At least in some companies I've worked, QA served as second tier technical support. They would get called alongside (or before) developers if an issue appeared in the field, since they often had a better grasp on the quirks of the shipped product than developers. This happens quite a bit when you have a bunch of old versions of the product in the field - developers tend to be very focused on the current state of the product.

Still, QA knows that (right or wrong) they're the ones people look to if a bug makes it to production - nobody else.

  • I'm a developer and when I break something, managers come to me for an explanation of what went wrong, not QA.
    – Brandon
    Apr 30, 2015 at 17:50
  • @Brandon - yes, some places work like that. Developers can explain to managers what went wrong, but tend to be not great at explaining to end users what went wrong (and how to fix it).
    – Telastyn
    Apr 30, 2015 at 17:56
  • 'Not getting fired' would get them interested, and although I find that a bit harsh it is a very valid way to get them vested in the releases. The fact that QA gets the first call is a very good point, but in the end the pressure to fix it still goes to the developers. Once QA figures out it is a bug in the release (which is often done alongside the developers) they are off the hook.
    – JDT
    May 1, 2015 at 11:22

But how are testers, aside from attitude towards their work, vested in the releases they test?

So your developers only care because they might be oncall for night/weekends?

If this is the case you are in a very rough situation. Because that team is much less vested in their work than you realize. If they only thing holding them accountable is a fear of working outside work this is not a good situation. It is providing considerably less motivation than you realize.

It's not a good situation because you want your employees to care, not about a fear of consequences, but in the workmanship of their craft. This is true whether you write code, test software, or make pizzas - better employees take pride in their work, whatever it is.

Finding bugs can be a source of pride for test teams, amongst other things.. do they get recognized for their role in quality software releases? In identifying bugs/problems?

Most workplaces with unvested, disillusioned or disengaged employees have bad management, lack of recognition, or are overworked.

  • I'm not saying developers would only care then, but there are examples out there of companies where this approach made a big difference. You can't argue with that...
    – JDT
    May 1, 2015 at 11:23

You want to eliminate "professionalism and attitude" from the equation which is the only thing that will stand the test of time. It doesn't matter what job you do, if you treat your job as a profession you will always be looking to improve, which naturally makes one vested. Those who treat their job as a job, tend to just do what is necessary and may or may not actually become vested in the outcome. So you eliminated the key means of getting your testers vested. Hire for attitude in addition to skill.

You can get short term upticks by offering bonuses or threatening to punish but the effectiveness of these approaches wane over time.

Another thing to work with is to make sure RESPONSIBILITIES are clearly assigned and known. Most managers simply hold their people accountable for not meeting their responsibilities. But that isn't enough to instill the proper motivation. To quote Office Space - "Bob, that will only make someone work just hard enough not to get fired". The part that is usually missed and is the most important part of assigning responsibilities is to MAKE SURE PEOPLE HAVE THE AUTHORITY TO ENFORCE THEIR RESPONSIBILITIES ON THE PROGRAM. If you blame people for not performing their responsibilities but they believe they didn't meet the responsibilities because their ideas were rejected, thus not meeting the responsibility was something out of their control, definitely leads to lack of ownership/vested interest. Whereas, if the person pushed to get their ideas incorporated, they will certainly have a vested interest in making sure they succeed.


Sorry if I don't attribute some of these findings, but I sometimes copy and paste things like these for my own purposes without thinking to capture the source.

There was a 10 year survey of 200,000 managers and employees by the Jackson Organization that showed that companies that consistently recognize excellence generate a return on equity more than 3 times higher than those who don't.

I kind of question this study because I have been at companies where they tried to do this and it may well have helped motivate those receiving the recognition, it had the opposite affect on those who didn't receive the recognition that they felt they deserved.

Although, just a general feeling that one's efforts are appreciated, and not simply expected, does go a really long ways.

Rewards geared towards the employee's family have the potential of being significantly more beneficial than something directed at the employee. For example, for a company in Florida, sending the employee and family on an all expense paid weekend to a Disney Resort Hotel and park entrance would probably cost the company less than $1,000 but will probably make the spouse and kids somewhat forget that the employee hasn't been around much over the last couple of months. Happy family, equals less stress at home, which means happier employee, which means more productive employee.

Whereas, a $1,000 bonus probably won't even be seen by the family, so all they think about is mom/dad works too much. Unhappy family, equals stressed out employee.

Studies have shown that when rewards are on the line, people tend to be less helpful.


Involve them in every step of the process.

  • Have them attend future design meetings.
  • Have them present during pre-grooming and grooming if doing agile
  • Emphasize the importance of always asking question "So, how will we test this?" during grooming.
  • Have them present during daily scrum if you have one
  • Have them work on test plans with developers - before the code is written!
  • Have them work with devops on deployments
  • Give them real say on when something meets the definition of done
  • Make sure that the definition of done includes input from QA for testing
  • Don't use time estimates from developers without including the same from QA
  • find ways to show how they are helping developer but being a roadblock for features
  • define their role as Quality Engineer, not "testers"
  • empower them by providing support and training so they can learn technical and development task
  • give them a source of ideas for testing using test heuristics - http://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf
  • send them to conferences about the profession of QA and testing, e.g. devops, velocity
  • Have them work closely with the customers and customer support so that they can understand and then be able to present things from a customer viewpoint
  • teach them about how to provide high quality bug reports with stuff like screenshots, steps to reproduce, initial variables to know about. This will make it easier and more enjoyable for developers to work with them. It will halp reduce the "but what were you doing when you get that" scenarios.
  • provide them with a reasonable tester to dev ratio (say from 0.5 - 3 developers) so they can get into details. If the ratio is more like 1 tester to 10-20 devs, they will be more likely to be doing rote tasks that are not really testing the product in useful ways that continue to add value over time.
  • keep a log of stuff they have found and present it to larger groups and iterate on it
  • make sure testers have the full power to add a bug to the bug tracking system and that it is easy for them to do so. Of course it should be reviewed (groomed) before being worked on by devs.
  • make sure that they have good tools and processes to do their work. If they don't, for example there isn't a UI automation framework, make setting it up a task that developers pair on with them.
  • emphasize to them that they are saving the customer and the company from bad things happening and thus they are a key part of the company.

Change "throwing the code over the wall for qa", to pairing with QE throughout the process

  • Really? Do I really need all of this to be an effective tester? Apr 30, 2015 at 15:23
  • No not all. These are ideas. I will stand by them all though and in my current job as a Quality Engineer they've all been important points. ymmv and imho of course. Apr 30, 2015 at 15:50
  • Also some of these are potential culture changers as in many organizations testers are considered "2nd class citizens". This is very common in our industry. To actually change that - change is hard - using the points I've listed may help. Apr 30, 2015 at 15:51
  • Also I am trying to answer the question "what gets testers invested", but not "what makes a tester be effective" which are different but related questions (hence me thinking not a dupe). Apr 30, 2015 at 15:54
  • @Robert-The specific examples might not all need to be there but if you look at all the items on the list they can be summarized to "Clear set of responsibilities", "Authority to impose your responsibilities on the program" and "Provide the tools/information necessary to perform the responsibilities". So I'd say, to be an effective QA, you need some variation of "all of this". Also, I think Michael is thinking of a QA person versus a Test Person, which share a lot of the same responsibilities but aren't quite the same.
    – Dunk
    Apr 30, 2015 at 17:37

If a defect is found it's the developer's fault, if a defect isn't found it's the tester's fault, and when anything happens it's management's fault.

Developers are motivated to make bug-free code, testers are motivated to find the bug-filled code, managers are motivated to find bug-filled employees.

  • You simply defined the desired outcomes/goals to be fulfilled from the roles. I think the question is asking how to actually get the tester to be "motivated" to do a really good job of fulfilling their role.
    – Dunk
    Apr 30, 2015 at 16:45
  • Good point. "aside from attitude towards their work", I don't really know. My guess is the desire to not get in trouble falls in this as does a bonus for smooth release. Telastyn's point about being a line of support is a pretty good point I think, probably the best thing apart from internal attitude and generic rewards/punishments. Apr 30, 2015 at 17:36

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