Beyond Bugs: Cultivating a Quality Assurance Mindset In Your Company

Yesterday, we met with a client interested in creating a digital solution for his business. We aimed to present a compelling proposal. Such proposals are based not just on innovative ideas and features, but also on a careful balance between our capabilities and the projected costs. We deliberated on the expenses for both implementation and ongoing maintenance. When the topic of the QA budget came up, our Customer Success Manager quickly said, “We’ll proceed as usual.” This suggests that the QA costs would be approximately 15% of the development expenses. I’m not a fan of this approach; I believe QA costs should be determined independently. Additionally, I felt this project might require a heightened focus on quality. Thus, I advocated for a more generous QA budget. The response I received was the typical, “Why?”. I explained that a good QA system is about more than just testing; it has many aspects to it. I explained that there are many ways to improve a product’s quality, and they all fall under the responsibility of quality assurance. The client understood what I meant and acknowledged its importance. However, post-meeting, my colleagues approached me, praising the “novel” perspective on QA I’d presented. Initially, I was disheartened. After all, I’ve advocated for this perspective for years, but there are still some colleagues in my company who don’t prioritize quality enough. Many professionals have a limited understanding of quality assurance, equating it just to testing and often missing its broader implications.

In this blog post, I’ll highlight the essential areas that you, as a QA manager, should emphasize to embed a QA mindset within your organization. Additionally, I’ll touch upon how QA experts can shift views on software quality assurance and the key considerations when enhancing software development quality.

Shift From ‘Bug-Finding’ To a ‘Quality-Building’

Many professionals I’ve encountered who haven’t worked with a QA engineer often misunderstand the role. They commonly label them as “software testers,” a term I’m not a big fan of. While being a tester is a valid job in itself, the role of a QA engineer is broader. If you’re looking to delve deeper into the QA world, it’s essential to recognize the variety of tasks they handle. When interviewing candidates, I often ask what they enjoy about the role. Typical responses include “I like finding bugs” or “It’s satisfying to spot errors in a system.” I have a different perspective: I don’t enjoy finding bugs! It’s frustrating. I need to discuss it with the developer, they have to rectify it, and then I have to retest. The best tasks or features to test are those without errors. Some might find this viewpoint surprising, thinking that if everything’s perfect, my role becomes redundant. But with my extensive experience, I can assertively say that without a QA individual, things tend to deteriorate. Or to put it another way, without a focus on quality, standards drop quickly. The ultimate goal should be a flawless process with clear steps and well-defined requirements. However, the objective shouldn’t be to find numerous bugs and take pride in that. The aim should be to set up a company system that prevents mistakes from the start.

Regular Meetings Elevate Quality Assurance

So, how do you create this ideal system and foster a culture focused on quality? Start by involving a QA expert at every stage of the project. Begin with a discussion with the client. Find out what “quality” means to them. Ask about their expectations for the final product, what’s vital to them, and how they’ll judge its quality. Then, discuss with the product owner how to reach this quality level and what resources (people, budget, technology, etc.) are needed. Once everything’s clear, the design phase can commence. Your next step? Meet with the design team to discuss potential risks and challenges in designing the product. Designers approach application building differently. Hence, it’s crucial to involve both developers and QA experts when reviewing designs. Perhaps the most vital discussion is with the developers. Understand their system and gauge their expertise. What technology will they employ? Are they proficient with the chosen tech stack? Do they have established merge and release policies? How do they conduct code reviews? Will they be writing unit tests, and if so, how? Skipping these discussions can lead to regrets. The outcome? A slew of bug reports and numerous debates.

So, communicate with your team and demonstrate the essence of committing to quality. Each employee has their area of expertise, and as a QA, your role is to guide and show others how to elevate their work quality, ultimately enhancing the final product.

If You Do Static Testing, Do It Right!

At my previous company, instead of just one person reviewing the requirements for a new feature, we had an entire review panel. Given that we produced medical devices, the idea was to include the head of every department that might be impacted by the feature. The process seemed straightforward: draft the design document with all the requirements, then send a Slack message or email to the panel members, kindly asking for their review. However, the responses varied. Some would quickly reply with “Review done” or “No comments,” while others wouldn’t review until days later, often only after I presented them with a physical copy. This review process could stretch on for days, and ironically, despite all the input, we’d still find errors. And guess who usually spotted them? Another QA member on the panel.

The entire review process, often termed “static testing,” is only effective if individuals are genuinely committed to conducting thorough reviews and are knowledgeable about what they’re reviewing. I’m a strong advocate for reviews. I appreciate when someone double-checks my work because, after a point, it’s challenging to spot one’s own errors. It’s reminiscent of school days: you might read your essay multiple times during an exam, confident that it’s error-free. Yet, when the teacher reviews it, they find 20 mistakes!

This principle isn’t limited to document reviews; it applies to code reviews as well. I can’t count the number of times I’ve seen the comment “LGTM” (Looks Good To Me), only to later discover a bug that could have been identified during the code review. A code review isn’t just about spotting errors; it’s also about evaluating the code’s structure and overall quality. Provide feedback on what you appreciated and what could be improved. If you’re not in the mood or mindset for a code review, delegate it to someone else. However, the review should be approached with a genuine intent to identify issues, not merely to move the ticket from “Code Review” to “QA/testing”.

Remember To Focus On The User Experience

Every product is tailored for a specific user. Remembering this is crucial throughout the various stages of software development. It’s essential to understand who your user is and how you can enhance their experience. I’m often baffled by how little this is discussed. At one company I worked for, we created a bike-riding app and had to include specific accessibility features. While I strongly believe in adding more accessibility to all our apps, it seemed the product owner and the developer team mostly focused on just this aspect. We had already integrated the primary accessibility features, and they functioned well. However, the team wanted to enhance them further, questioning if the current level was adequate. The push for heightened accessibility came from the fact that our project received government sponsorship. It’s important to mention that since the app’s main purpose was centered around bike riding, one could argue that the emphasis on accessibility might not be as crucial.

Meanwhile, we were overlooking crucial features that would enhance the experience for our primary audience: bike riders. When I highlighted this oversight, it was a wake-up call for many, and our focus realigned. Ultimately, we produced a top-notch bike app that met all required accessibility standards. Even better, our users gave us high ratings in the app stores. Their positive feedback was a testament to the quality of our product. After all, a product’s quality is intrinsically tied to user satisfaction.

You Want To Be The Best Not the Fastest

Let’s delve into the topic of deadlines. Personally, I’m not their biggest advocate, and I might dedicate an entire blog post to this sentiment in the future. When trying to install a quality-centric culture in a company, deadlines can pose challenges. As the deadline comes closer, there’s often increased pressure from product owners and stakeholders to launch the application. This is when a QA is truly tested. Being in charge of testing, you’re often the only one with a comprehensive understanding of the product’s quality. If it’s not ready for release, it’s crucial to voice that.

I’ve frequently encountered dismissive responses like “It’s not that bad” or “No one will find that error”. In such cases, I find it effective to organize a meeting with various stakeholders and give a brief presentation on the product. Knowing the product’s flaws well lets you point them out clearly and quickly. Such meetings almost always lead to reconsidering the deadline. It’s essential to remind stakeholders that while deadlines are significant, the product’s quality holds greater importance. The goal is to offer the best product in the market, not just to be the fastest. Remember this the next time there’s a conversation emphasizing the deadline over quality.

Everyone Is a Tester

Finally, let’s discuss the role of the tester. Or better yet, who should be testing the product? The correct answer is… everyone! Every individual involved in the development process should not only think like a tester but also actively test now and then. Each person offers a unique perspective on the product, which can help uncover various flaws and errors. Encourage everyone to adopt this mindset and to take ownership of their contributions.

I’m also a proponent of “bug-bashing” sessions at specific intervals during the development phase. For those unfamiliar, a bug-bashing session is a dedicated meeting where all stakeholders (designers, developers, product owners etc.) come together to collectively test the software.

I usually kick things off with a brief exploratory phase, allowing everyone to freely test and familiarize themselves with the application. After that, I assign specific roles to participants to simulate various user experiences. For instance, some might be tasked to navigate the software as if they were elderly (focusing on accessibility), while others might approach it as tech novices or children. Depending on the product, roles can be more specific, like doctor, nurse, or patient for medical apps, or admin, restricted user, and basic user for platforms with varied access levels.

The goal is to spark creativity and allow team members to see the product from various perspectives. By doing this, we highlight the significance of user-focused design. This approach not only improves the product but also teaches the team, aiming to embed a quality assurance mindset in all.