QA is a much-maligned acronym which is routinely shorthand for “Quality Assurance” (whatever the hell that actually means – you don’t assure quality by discovering and sharing information about the software), it’s variously “nicked” to stand for Quality Analysis, Question Asking, Quality Activism… but the one which I think is the neatest translation of these two letters into something we actually want to be doing for our teams is “Quality Advocacy”.
Advocating for Quality is, for me, a great way to encapsulate the role of the tester/QA in a good team. Advocacy and its associated soft skills are often undervalued competencies, yet they are frequently visible in successful quality-minded professionals. As a term, it broadly covers “using the code” (aka testing), executing checks and tests to both ensure the system behaves as expected but also letting the team know stuff they didn’t realise about their solution. However beyond that, it covers some of the soft skills required of a strong tester/QA/Test Manager/Quality Professional:
Let’s start with a, one hopes, fairly obvious one. If you’re interested in a career in Quality, you’re going to need exceptional communication skills. That doesn’t mean you need to be able to write a novel, but you do need to be able to tell a good story. What’s the problem? What is the implication of this problem? How did you uncover this problem? These are all elements of a good bug report, but they’re also components of a good conversation about quality.
If you’re having difficulty in getting traction with a(ny) stakeholder around quality, try taking them on a journey. Show them how frustrating the problem may be. Show them the hidden costs they’re gambling on when accepting risk. Show them the pain of failing to “do it once, properly” vs “quick and dirty” and the associated technical debt.
Quality is about more than just bugs in software – it’s about inefficient process, it’s about weak or brittle solutions to business problems. It’s about relationships which foster stronger code, stronger interdisciplinary understanding, stronger communication. If a team is communicating well (and by team I include all “external” stakeholders, including the customer), the problems so often experienced in software development can often be mitigated or avoided altogether. Collaboration, partnership, a shared culture of quality cannot be achieved in silos. It requires communication.
In addition to the above, there’s often going to be situations where values, drivers and motives conflict. A classic example is the PO who wants a feature “out” so the customer gets off their back, and so they can tackle their roadmap items (until the next customer sets on fire…), vs the Tester/QA who wants to keep their finger in the damn until the change is thoroughly tested, bugs have been addressed, and things are “as good as they can be”.
It’s clear these views both come from a place of wanting to do a good job – the PO wants to provide value to the customer and keep them satisfied (or better still delighted) with the software. The tester/QA wants to “do a good job” and keep bugs out of the software. It would be unfair or incomplete to characterise these views as short-term vs long-term thinking: after all, the PO will take a hit on capacity if their dev team has to take on massive refactoring, tech debt or bugfixing activities rather than features – similarly, they may have awareness of a longer-term business objective around a specific feature or customer than someone in the dev team (and may not), and the tester may care more about hitting a great release after a bad one than actually thinking about the long-term impact of buggy software making it “into the wild”; however there is a certain truth that the job roles described do sometimes have different timelines in view for their work.
These competing values don’t have to result in conflict. An important part of being able to advocate for any value or decision is strong negotiation skills. This includes being able (and, importantly, willing) to build an understanding of the person we’re negotiating with. Strong communication will help here, but influencing, mindful language, getting a picture of what’s driving the counterpart’s decisions, working out what can be gained for both sides in compromise and, again, telling that compelling story of the above are all vital to successful advocacy.
How much cheaper, and how much more collaborative is it to convince someone of a risk ahead of time, than to see that risk realised? Sure, there are times when you may feel like storming out of the meeting, but part of successfully navigating these conflicts is to spend the time required to get everyone onto the same page.
Another aspect of these closely-linked skills include the ability to facilitate communication and negotiation within a team. This isn’t limited to processes, ceremonies and written comms, it’s about getting the right people talking. Some of this is obvious – if you see a silo, find a way to break it – but other techniques really are a little greyer, true “dark arts”, at least in the fairly straightforward world of software:
- Layman’s Terms – If I notice someone in the room doesn’t seem to be understanding something in the conversation, I’ll ask for clarification on their behalf: “Sorry, I’m not as technical as you, please can you break that one down for me?” (yeah, I did understand really, but the guy over there didn’t, he was just too proud to admit it…)
- Teach Me (ahem, You) – If I need someone to understand the implications of their decisions in software (or, I guess, anything) a great technique for asking them to review these is to ask them to walk you through it, as a training/education piece. It’s interesting how often things change as a consequence of these walk-throughs.
- Test the Conversation/Design/Idea – As testers we have a lot of great heuristics for learning about software, what it can do, what it shouldn’t do. Some (many) of those same heuristics can be applied throughout the process, thinking for example if a design can really be shown to satisfy the AC, considering what the opposite of a statement looks like, making the boundaries of an idea explicit to all in the conversation and “diffing” opinions by making them explicit to see if understanding is shared.
There are tons more tips and tricks to be offered here, but perhaps I’ll save these for a future article. You can see, I hope, that there’s more to facilitation than simply setting up a conversation – there’s ways to take an average or dysfunctional conversation and make it meaningful for all involved.
To advocate for something effectively, I believe you need a solid, authentic belief in it. Sure, you can fake it, sometimes get by. But to be convincing in what you’re saying, and, crucially, to go home feeling like the job’s been well done, you need to believe in what you’re selling. Quality Advocates are selling quality – quality software, sure, but quality interactions, quality team dynamics, quality relationships. And, to do it well, they need to be fully bought-in to the ideas they’re selling.
Tenacity is a quality I associate with gritted teeth, white knuckles hanging on to the rail, the rope, as waves crash overhead and sea-spray, desert sand or some variety of soot blows in your face. It’s a bit… much. But frankly, whatever analogy you want to use is fine – you need to be prepared to defend, to be strong, not to give up. To stand up to the attitudes you’re faced with, to be the Twelfth Angry Man and speak up for what you believe in.
These two go hand-in-hand, as without one you’re unlikely to supply the other. Both are important to meaningfully and successfully advocate for quality: if you don’t believe in the reasons for it, why would you care if it wasn’t present?
And, finally, speaking of those reasons… the main reason we need to build quality in the ways we work and the things we build, is compassion. Not empathy, where we “understand where someone else is coming from”. Not altruism, where we want things to be some (necessarily subjective) for of “better” because it makes the world a better place. We are compassionate because we care about how it feels to be in our team, to follow our process, and to use our product. We are compassionate because we understand that every team member, stakeholder and user is unique. We are compassionate because we believe in the value of our work and the things we do day-to-day.
Compassion is vital in quality for a number of reasons. Have you ever made something, maybe something you’ve cooked, a picture you’ve drawn, a poem you’ve written, a wall you’ve built, only for someone to come along and criticise it? How did that make you feel? Have you ever been in a situation where you’ve felt your opinion wasn’t being heard, or valued? How did that make you feel? Have you ever been in a work environment where you felt you didn’t understand why you were doing something, but did it anyway out of fear of speaking up? How did that make you feel?
Conversely, have you ever built or made something, and had someone tell you how amazing it is? Have you ever been in a relationship which made you feel valued and like your opinion mattered? Have you ever changed something at work to the benefit of those around you? How did that make you feel?
Compassion is holding onto those feelings in our interactions, understanding the negativity of one and the positivity of another on not just individuals, but teams and the work they produce. Compassion is everything in quality, with its focus on “finding and fixing bugs”, reappraising processes and fostering better communication.
I hope those give you some sense of what I mean when I talk about quality advocacy. It’s a set of soft skills which allow good testers, good QAs, to become great ones. They’re good skills for any team member to have, and those who have them and practice using them often find themselves in the centre of more and more conversations, more and more processes. They’re undervalued which makes them rare. But, if you have them or can build them, they will take you further than many conventional skills in the quality space.
One more thought here, quality is a contextual thing. It’s an agreement between the business and the dev team, between what the organisation considers “releasable” and the customer’s expectation. Quality is not a fixed measure and is a contextual continuum – this is evident in the differing standards applied to, say, a hotfix, and a long-running epic. One necessarily has less time spent on “assuring” (heh) quality – and the negative connotations or consequences of that may be acceptable in the immediate situation of a functionality-breaking bug in production. As such, a quality advocate needs to get a fix on the required level of quality from the situation, and negotiate with business and team accordingly.
There’s no point in applying red lines or one-size-fits-all ultimatums to a fluid, evolving business situation. The role of the QA in all this is to make sure everyone is aware of the quality (and risk) implications of the choices being made, and check all stakeholders are comfortable to proceed on that basis.
What dark arts do you use as a tester? What skills which are less well-known let you succeed in driving quality? Let me know in the comments!