The 3rd Myth of Software Testing - Testers are responsible for the quality of the delivered product
Updated: Sep 22, 2022
Notwithstanding that very few organisations ever internally define their expectations of quality, even in the brave new world of Agile and DevOps the 'Testers are responsible for quality' axiom seems to be a prevailing anti-pattern.
Even with the vast amount of available evidence and the oft-repeated but seldom implemented mantra of the ‘whole team is responsible for quality’ promoted by Agile adherents the world over this still appears to have taken root in a lot of organisational thinking.
The stark reality is that the QA function doesn't own the business, they don't manage a product, they don't control the resource, they don't set the budget and they don't set the timescale so why would they be held responsible for the quality?
Seems a bit unfair to me.
Because it's their job? Not really, according to Michael Bolton, the role of a QA is to find problems in the software that threaten the value of the product. I disagree with Michael in one respect here as I think that I think the role of a QA is to find the problems that lead to problems in the software in addition to finding problems in the software. As QA we like to talk about the relative cost of fixing defects though I'm not aware of any studies that show if this has changed due to Agile adoption versus Waterfall.
I don't really require a study to convince me that addressing issues earlier (be it in a sprint or the many iterations of the requirement definition phase) will result in a more valuable product.
I think that's a separate post though. There can be many reasons for this embedded way of thinking:
It may be that speed to production is paramount (we'll fix in prod)
It may be that the QA function has no champion beyond the QA role (I've got my own stuff to deal with)
It may be that QA themselves operate in a silo-ed mindset (I just write code / automated scripts)
It may be that developers are entrenched within a bygone development mindset (I'm paid to code)
It may be fear (I don't know what this quality thing means)
It may be ignorance (I just don't know what's expected of me)
It may be a perceived lack of interest (I just want to get this out the door, love island is on tv)
It may be pressure (I've got so much to get through)
It may be management pressure (I've got to deliver this)
It may be prevailing wisdom (I haven't failed yet)
It may be personal relationships (I don't like 'A's work)
It may be reticence (I'm not confident)
It may be isolation (I speak but no-one cares anyway)
It may be pride (I know what I'm doing)
So, how can this particular myth practically be debunked?
Education, education, education.
Advocacy, coaching and promotion of an approach to quality that involves the whole team right from the off.
Use each ceremony (Stand-ups, 3 Amigos, refinement, planning) as an opportunity for coaching.
Use humour (YMMV) to lighten moods.
Engage stakeholders, they are often seen as authority figures and can project high level concepts with a gravitas beyond a single team member.
Achieving buy-in throughout the process by the development team can result in a truly eye-opening experience, both for the team and the deliverable. When a team start to spontaneously suggest improvements to the quality process and look outside their domain in doing so it can be transformative.
Below are actions that have worked for me and hard-won lessons that haven't.
DO:
Define what quality means as a team.
Solicit opinions different from your own.
Monitor inter-team relationships.
Promote correct grammar and spelling.
Be 'that' person. Rationalise concerns. Stand your ground.
Develop self-awareness.
Empathise.
Compromise.
Talk about quality at every opportunity.
Challenge bias (confirmation or otherwise) Nurture a culture of safety.
Run lightning talks.
Run brown-bag sessions.
Run workshops. Run pair sessions.
Become adept at spotting ambiguity.
Sit with developers, listen and understand their perspective.
Emphasise the risk of unwanted behaviour escaping into production.
Emphasise the risk to reputation.
Emphasise the monetary aspects of unwarranted attention.
Emphasise the risk to livelihoods in the event of either/or.
Emphasise that it is a collaborative process.
Use metrics where there is value in doing so. Emphasise that you believe that the team want to do their best work every day.
DON'T:
Be dogmatic.
Be a doormat.
Point fingers.
Ignore concerns.
Give up.
Get discouraged. Be isolationist.
Be arrogant.
Stop learning.
No doubt this is a myth that will endure and will probably gain more traction as ML and AI become ever more embedded in the SDLC.
But until The Terminator becomes a documentary I'll fight the good fight.