Once the QA Engineer enters the room, everyone expects that quality issues will be magically solved.
Throughout my career in software testing, I’ve noticed dilemmas that affect the overall team’s dynamics and product outcomes. Believe it or not, these are the patterns that are quite common for every development team I worked with. These very patterns easily block the team’s goal, e.g. to develop an amazing cutting-edge product that could help humanity… As a result, this amazing product exists only in the requirements or in the dreams of the product owner. The team builds something else instead.
Some teams praise visibility over value, forget about quality in hectic sprints and approach testing without a clear strategy. Sounds familiar? Welcome to the reality of a QA’s job.
Visibility over value?
In many teams, louder members get praised, even though their impact might be equal to that of more silent members. To find the typical example, just observe an average stand-up meeting. The ones who talk more get all the attention.
In her article, software engineer Priyanka Jain tells the story of two colleagues assigned the same task. One posted updates, asked questions, and collaborated loudly. The other stayed silent and shipped clean code. Both delivered. Yet only one was praised as a “great team player.”
In many work cultures, we mix visibility with value. If you talk often, people assume you’re contributing. If you’re quiet, they assume you’re not. That is why extroverted personalities get promoted more often than introverted ones.
If you are the only QA person on board, you need to be visible and vocal. Otherwise, your contribution goes unnoticed, the major bugs get ignored, and nobody cares about the product’s quality. Some may even wonder what you are doing there because you don’t ship code.
If you are an introvert by nature and you don’t like to exhibit your opinion or updates on every corner, it may be a challenge for you. However, this is a reality of “fast-paced” environments: the more vocal and visible you are, the better it is for the team.
Quality is the oracle, but is it really?
Quality is meant to be the oracle for a product team; it is something that the product team should strive for and manage accordingly. Otherwise, are you sure your customers would tolerate all those bugs and inconsistencies they run into? No team wants to see their product abandoned by the users. Yet, is quality really an oracle?
Once, I had a debate with a developer about a feature. He argued that he would definitely make a toggle button instead of a drop-down menu because “it looked more fancy”. I asked him to visualise both versions in the prototype tool so we could test each option. In the context of our specific use case, the dropdown menu still looked like an appropriate choice.
After a brief testing session that we had done together, the developer gave up and agreed. We saved time on the potential rework. (Back then, AI wasn’t so powerful yet. Right now, I would use an AI-driven tool to visualise both cases for the development team. So, we could also save time on a debate.) Anyhow, everyone was happy, including the customers who got a polished version of the product promptly.
Here, the quality mindset is something that could be learned on the way. The role of a QA person is also to promote this mindset, so team members become aware of it. When realising the priority of quality, the development team will do more to prevent bugs in production. Afterall, quality is a team sport.
Do we need a testing strategy?
Before I joined a team, let’s call it X, it had no testing workflow, and the team wasn’t confident enough to go through the release cycle. There was a usual panic one day before the planned release. The team wasn’t yet conscious about quality. The overall feeling was like: “Testing? We just don’t have time for it. Aren’t you QA? You should figure out something!”
The whole situation reminded me of the logic of Hattifatteners from Tove Yansson’s book, who were always on the move and wanted to reach the horizon at any price. Here, the price was quality.
In a month, I brought the team to the point where we had a hard talk about the current product quality and what we can do to release better. The team established a QA workflow that consisted of multiple testing techniques at various levels of the product (End-to-End, API, Unit). Agile Testing Quadrants, a tool first introduced by Janet Gregory and Lisa Crispin, were our framework for selecting testing techniques that matched team X’s needs. The overall product quality improved a lot then.
Before a team starts building a quality assurance system for a product, it is smart to brainstorm on how quality assurance should function. It is important to define how the quality will be measured: which testing techniques will be applied to the product, and how overall testing coverage will be achieved.
It is vital to discuss the current testing status and how the team could prevent defects (which tests to use and at which level). After brainstorming sessions, the QA flow can be outlined by the team. Consequently, there will be less chaos and more peace of mind once the team ships the product.
If you are struggling with similar dilemmas, there is always a solution for each. In an agile team, get more vocal and communicate the issues clearly. If the team forgets about quality in the reality of speedy sprints, remind them about it and involve team members in testing sessions. And finally, if testing efforts look messy, talk to your team about the testing strategy and create it together. Afterall, aren’t you the one who can figure it out? 🙂
You may check my LinkedIn page if you feel like connecting with me or are curious about my background. As a QA Engineer with over 7 years of commercial experience in the industry, I’m ready to communicate with teams looking for guidance and help in enhancing product quality and testing. At this very moment, I’m looking for a new role as a QA Analyst, QA Engineer or QA Lead.
Illustrations: by me (Apple Pencil, iPad, and no AI 🙂)
Resources:
- Priyanka Jain, Not All Great Work is Loud: https://code.likeagirl.io/not-all-great-work-is-loud-77874c554276
- Aletheia Delivre, Making product quality a team sport: https://uxdesign.cc/making-product-quality-a-team-sport-35d94fc0a2cf
- Janet Gregory and Lisa Crispin, Agile Testing Condensed: https://leanpub.com/agiletesting-condensed or https://www.amazon.de/gp/product/199922051X
Test smart: how to solve dilemmas as QA? was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.