what gets testers invested in the releases they test?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

OTHER INFO / ODDS & ENDS

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.

Answer 4

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

Answer 5

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.