Following on somewhat from my post âWhat's Your Dev - Tester Ratio?â, I was wondering how you manage a situation where your team does not want to learn more about testing and they donât want to have shared ownership of the quality of the work thatâs being released?
What are the steps you would try in this situation? Or perhaps a better question is: where would you start?
Try to understand what makes them think/feel that it would not be a benefit, then use an old sales technique I was taught AIR.
Acknowledge - I can understand why you would think that
Isolate - Is that the only thing (in that area) that concerns you
Resolve - Heres why that isnât actually a problem
I think the first step is to have an agreement with management and leads that it something the company wants. Having that, a common message will arrive at the teams that Quality is a Team responsibility. If the message comes only from testers and then different messages are shared with team members from other senior roles, I think is almost impossible to achieve the goal of having shared ownership of quality.
Not everyoneâs opinion on quality matters. And not everyone is speaking about the same âqualityâ.
Examples from the post above: âZero defects is high quality., User-friendliness is high quality., Low development cost is high quality.â
Two types of quality based on ownership:
quality of your own work;
quality of a project/product;
You could have one without the other. Rarely youâre in charge of both.
The quality of oneâs work is the responsibility of that person. The quality of oneâs work can impact the quality of the product. Quality of a product release is not the responsibility of the person that developed it.
Testers or developers are usually only in charge of the quality of their own work.
Developers build - to the best of their knowledge/abilities and considering the constraints.
Tester finds quality gaps, risks, threats, and report/inform managers about them.
That doesnât make them in charge of the product quality about the product to be released.
The managers and stakeholders are leading the direction and taking all the decisions on quality.
Sometimes development team members will make decisions without approval, or on behalf of someone else.
This is a risky thing, as you could either get yourself in trouble or you put someone else in a tough spot when having to motivate the budget, resources spent on some decision that they havenât made.
To put on the development team the responsibility for product or project quality I think itâs a big mistake.
The development team most often is disconnected from stakeholders, department managers, clients, direction and roadmaps for a product, financial stuff, budgets, logistics of the project, etcâŚ
Release management:
The work of the development team, including testerâs are getting to the release manager/s.
I also feel like the development team shouldnât be the release managers either. Or if they are, to do it in collaboration and in agreement with the product manager/s and have the product manager own the task/decisions.
The release managers make an informed decision to release or continue to work on things. They analyze: what there is, what they would have liked to have, what gaps/problems there are, what risks and impact the release would make, etcâŚ
What would I do if I feel the quality of a product is bad:
Iâd have more often discussions with the release manager, product owner, and increase the bug advocacy.
What would I do if I feel the quality of a developerâs work is bad:
Most probably nothing, or have a raise of awareness either to the person, to the colleagues, or to the manager if all else fails.
I could also propose things that could motivate the developer, or help him on a personal level, or make some suggestions to have the developer work on something he likes or heâs strong at.
At one level software quality is a lot like marketing division spending. Both deliver business value over time, while both have a very short sell-by date for their efforts. The value they bring is intangible to some, and since, they both go to war in the real outside world, they are key to supporting the business.
The difference is that the tester knows that itâs easier to loose a customer, than to make a new one. Marketing have that job, which in reality makes them far more expensive.
Give people skin in the game - if engineers have to answer support questions, deal with outages of their service, etc, it can lead to some significant leveling up, as well as folks realizing that quality means a lot of different things.
@beardedtester - on a lighter note, what if the team uses AIR against me when I try to use AIR on them ? I wonder if Iâll end up letting them work in the old ways.