Quality Assurance VS Quality Control and Why it Matters

March 8, 2016

ALM, ALM: Quality Assurance Best Practice, Performance Testing

Quality Assurance vs. Quality Control and Why It Matters

By Matt Angerer

For more than a decade, you’ve likely heard IT executives and CIOs say that they’re trying to be more proactive in the way they approach their IT departments. Maybe they’re training teams on the latest software, or streamlining internally with clear policies and procedures for hand-offs in decentralized teams, or they might be defining an operational RACI (Responsibility, Accountability, Consulted, Informed) model. Proactive measures like these are akin to preventative maintenance on a vehicle. Changing the oil, flushing the fluids, washing off road salt, and using premium gasoline can help you avoid problems down the line. This isn’t to say that problems won’t occur. As we know, we all live in an imperfect world and Murphy’s Law can rear its ugly head at any moment. However, making proactive steps in an organization can certainly help avoid problems down the line.

On the other side of the coin, we have the “reactive” way of doing things. The word itself is drenched in negative connotations. Nobody even likes to say the word, but most of us are living it on a day-to-day basis without realizing it. Often times, IT leaders neglect to address an obvious problem “head on” due to the ripple effect it may have on existing business operations. In effect, they live in a state of continuous denial until the problem cannot be ignored any longer. It’s similar to Uncle Bob’s addiction to sugar and flour. His doctor continues to tell him that his blood sugar is on the rise and he’s borderline diabetic, but Uncle Bob continues to shrug it off as if he’s above diseases like Type II diabetes. He lives in a state of constant denial because he feels that it’s easier to “react” when something goes wrong than it is to take the proactive measures to avoid Type II Diabetes altogether. Uncle Bob knows that being proactive would require a drastic lifestyle change in terms of exercise, food choices, and sleeping patterns. To him, the juice isn’t worth the squeeze – leaving him stuck in a state of denial and reactivity.

So, why in the world would any Information Technology (IT) article start off by talking about maintaining your vehicle and Uncle Bob’s problems with flour and sugar? If you’re a QA Leader in your organization, you can learn a lot from Uncle Bob. He wants results, but he doesn’t want to wait – nor, does he want to face the reality that change has a cost and takes time. Therefore, he does nothing and ignores the dire warnings of his doctor, family, and best friends. He continues to live the lifestyle he is accustomed to and makes the same decisions like eating his favorite Krispy Kremes every Saturday morning. He also continues to complain to his family and friends about how “tired he always is” without taking the time to truly reflect on the root cause of the problem.

Now before you take offense and stick up for Uncle Bob, let us just say that we like Uncle Bob and it’s nothing personal. In fact, social psychology experiments have proven that human nature tends to be more reactive than proactive. There are a lot of Uncle Bobs running around out there that just want to take a little pill and call it a day. Similarly, most business leaders want your QA team to give them an automated testing framework that catches every defect without any process-related change. Everyone just “wants it to work” without really understanding and appreciating what goes into the QA process. In this article, we want to shed a little light on the Yin and Yang of QA and QC.

Herein lies the differences between Quality Assurance (QA) and Quality Control (QC):

Uncle Bob has been educated on what changes he would need to make to his diet, lifestyle, and overall habits to avoid Type II diabetes. After all, he’s only 45 years old and his blood sugar is border line diabetic. With a few changes to how he manages his lifestyle, his blood sugar would be back in the normal range. But, he doesn’t do it.
This is akin to how your Quality Assurance team operates on a day-to-day basis. You instinctively know how important it is to clearly define your requirements management process. Even more is that you already know why it’s so important to do an ambiguity check on all your requirements. Without an ambiguity check, you’re left guessing what should or shouldn’t be tested. Perhaps you even know why it’s important to establish traceability between all types of requirements (e.g., Functional, Technical, and Security) and how not doing so may lead to lack of effective change impact analysis down the line. But, you don’t do it – or you don’t get the necessary support and resources to carry out Quality Assurance principles that will ultimately prevent defects down the line.

QA is a set of activities that ensures quality in the everyday processes by which your software is developed. Processes like ambiguity checks, traceability links, code reviews, etc. Whereas, QC is a set of activities that focuses on ensuring quality in the software produced — also known as software testing. QA is what you should be doing to make Quality Control (QC) easier. Both are needed and equally important, but failure to execute upon Quality Assurance practices can put your Quality Control team in a difficult position. Similar to how Uncle Bob’s failure to follow the prevention guidelines will ultimately lead to Type II Diabetes and all the complications that arise from it. Sometimes business leaders place too much value on Quality Control to trap defects, rather than investing more time and money into Quality Assurance (QA) to proactively prevent defects.

QC is where the rubber hits the road and you’re kicking the tires (testing) on the software you just built. It’s the culmination of the requirements definition, design, and build. You’re now identifying defects in the product and raising them up to get fixed. When completed, you re-test the defect and then regress back over the existing functionality to ensure other defects were not reintroduced into the process. You can see how difficult Quality Control becomes if your team overlooks the importance of Quality Assurance practices.

The bottom line is that proactive teams will embrace Quality Assurance and understand the importance in “getting ahead” of how software is built. It’s not enough to just talk about it though. It’s one thing to say in a staff meeting that “we must be proactive” vs. actually following through on the day-to-day grind of being proactive with your Quality Assurance practices. Don’t ignore the obvious warning signs. If your customers (both internal and external) are providing negative feedback, listen to them and respond accordingly. The end result is a pleasant User Acceptance Testing (UAT) experience and a satisfied customer. The cost of quality continues to rise with the proliferation of software platforms.

ResultsPositive, a Platinum HPE Partner, provides the tools, training, and expertise necessary to balance both Quality Assurance and Quality Control. We have worked with hundreds of clients to define Quality Assurance roadmaps that leverage world-class tools like HPE Application Lifecycle Management (ALM) and Quality Center. What’s more is that we have implemented and used the “Quality Control” tools internally for our own Software-as-a-Service (SaaS) tools. We practice what we preach. Some of these additional tools include HPE Agile Manager, HPE Performance Center, HPE LoadRunner, HPE Unified Functional Test (UFT), and HPE Sprinter. We understand the importance of both QA and QC and have the HPE ExpertOne certified experts and SCRUM Masters on-board to help your organization navigate the changing waters of DevOps, Hybrid Agile, and Traditional (Waterfall) methodologies. Contact us today for a complimentary 1-hour demo and evaluation of your existing landscape.