When two worlds collide — defect-oriented vs quality-oriented approach
I remember my first day as a QA engineer, it was 12 years ago. I can still feel the amazement and excitement from that day. I was able to finally find the job that I’d been looking for. And of a sudden, I’ve started to hear that QAs are only pointing out others’ mistakes and focusing on what’s wrong. It was a shock for me. I’m a team player and I always wanted to contribute to all the efforts made to reach the goals. It took me a long time to understand… So who’s right and who’s wrong?
In 2012 I attended an ISTQB Foundation Level course led by Radoslaw Smilgin. During one of the coffee breaks, he started to explain how you can approach testing with a different mindset. He did something that I was surprised to get. He planted this seed in my head which has grown over the years in my head and watered this idea with a simple distinction between focusing on defects and focusing on quality. After almost 11 years from that moment, I’ve developed my own understanding of his words which I would like to share with you.
Back to the basics
Before I even start to talk about different mindsets and approaches to testing, let’s pause for a moment to reflect on the most fundamental definition: the purpose of testing. It is often believed that testing is solely about finding defects, but it’s way more than that. If you take a look into ISTQB FL, you will discover that testing has multiple objectives beyond finding bugs. On top of that, testing also verifies requirements, validates user expectations, builds trust in the quality of the delivered product, minimizes risks, and provides the necessary information to stakeholders to help them in the decision-making process. That’s quite a lot under one word — “testing”.
Defect-oriented vs quality-oriented approach
The entire idea itself is easy to explain and understand. As Radek explained to me, a defect-oriented approach focuses on finding bugs, while a quality-oriented approach aims to establish a high-quality level build in your product. Simple, isn’t it? So where’s the entire fun? It always comes to how this will apply to your daily tasks.
In a defect-oriented approach, you are focusing on breaking the app or product in all possible ways. You want to find bugs and prove that whatever you are testing is poor quality, right? Not necessarily! While the primary focus is on bugs, there’s a deeper context to consider. Sometimes companies simply want to identify the flaws in their app or product. It is so popular that it has become a model itself — pay-per-bug. Crowdsourcing and crowd-testing companies are often engaged to rapidly identify as many bugs as possible. Some companies even have open pay-per-bug programs allowing anyone to report an issue and get paid for it, this concept is known as bug bounty. Today it’s used by companies like Apple, Intel, Snapchat, and Facebook.
However, there is something to keep in mind with this approach. Yes, we’re focusing on finding bugs, it’s crucial to remember that it’s not about pointing fingers. Testing is never about assigning blame and shame. Despite being regarded as a potentially destructive activity, testing is always constructive. It uncovers what would otherwise remain hidden. Thus, with a defects-oriented approach, you can still bring a lot of positive value to the Software Development Life Cycle.
The quality-oriented approach is about proving a high-quality level of our product or app and bugs are only a side effect of this process because bugs will happen anyway. As QA Specialists, our role is to cover what is important to fulfill the testing objectives mentioned earlier. It’s not just about covering only happy paths or brightest day scenarios but; it’s about thoroughly testing software without placing blame and driving towards reporting as many issues as possible, even if they are not necessarily an issue. Seems easy and positive, doesn’t it?
However, there is something that I must warn you about. The fact that you acknowledge the existence of the defects, and you know that they will occur, does not mean that we agree with or ignore them. Otherwise, you will sit in the middle of a burning house, sipping coffee out of your mug and telling “This is fine” to yourself (not literally, but you get the point).
Dark side and light side?
So which approach is better? Which one should you take? I would say none and both at the same time. It all depends on situations, context, specific companies, products, planetary conjunction… There is no single solution or mindset which can be applied to every situation, project, or company. The most important thing is to know different approaches and know when and how to use them to bring value to what we do. This has grown in my mind from a simple sentence planted in my mind. Thank you, Radek!
If this article has been interesting to you, we encourage you to explore career opportunities at SwingDev.
