top of page

QA, QC, and Quality Assistance: Clarify the Acronyms and Revolutionize Your Practices and Communication

QA expert assisting a team member

By Julie Papineau: Expert in software engineering and trainer at Zentelia

October 18th, 2024


There are countless acronyms in IT, enough to confuse even the most seasoned professionals. Let’s demystify some acronyms related to software quality together.

 

Having had the privilege of working with numerous teams in different companies, I frequently witness the confusion that can arise from differing perceptions of the same term. The experiences of each employee color our understanding of terms. Therefore, it is truly important to establish a common terminological foundation.


Let’s start with a simple acronym... QA for Quality Assurance. This term is used both to designate a specific role within the team (such as the QA of the team) and to refer to the general discipline of quality assurance. Unfortunately, when teams talk about QA, it is often associated with the team member who performs the testing. The ISTQB (International Software Testing Qualification Board) defines quality assurance (QA) as "activities aimed at providing confidence that quality requirements will be met." When we talk about quality assurance, we refer to a set of practices, methodologies, and processes put in place to ensure that the product meets both implicit and stated requirements and quality standards. QA is a process-focused preventive approach. Think of it as everything you can put in place to prevent defects from being discovered later in your delivery cycle (e.g., during testing). Quality policies, strategies, planning, monitoring and control, including metrics and dashboards, upstream documentation reviews... all activities that can be considered to prevent defects from being introduced into the code.

 

To make the rest of your reading easier, I will use the term “quality analyst” when referring to the team member, to avoid any confusion with the QA acronym. The quality analyst participates, among other things, in the execution of tests. This activity is part of QC, Quality Control. Defined by the ISTQB as "activities intended to evaluate the quality of a component or system," QC is a product-focused detection and correction approach. Testing, in all its forms, is certainly a central element, as is prototyping and simulation. Doing QC is therefore doing QA. Certainly! However, activities that merely "find" defects will slow down your delivery cycle and be perceived as a bottleneck. That’s why QA and the earlier mentioned activities are so important.


Global vision of QA related activities

What about you? Where do you stand between QA and QC in your projects? Many teams call on their quality analyst to perform tests once something is ready (QC). Others involve their quality analyst to review acceptance criteria (QA).


Today, society in general is more demanding and less patient. Everything moves faster, and at work, everything must be delivered quickly as well. In IT, agility has introduced the principle of quickly delivering value to customers. This allows us to readjust if things do not meet expectations. DevOps then emerged to address certain challenges between development and operations. The goal for many companies is to offer users new features in real-time. Although the pressure to accelerate delivery times has increased, activities related to product quality have not always evolved accordingly. It is still common to focus on quality at the end of a stage or project.


Let’s return to the acronym QA. This time, I propose “quality assistance” as a definition instead of “quality assurance.” A fine distinction you might argue. Absolutely! But a subtlety that clearly shows the change of guard that quality analysts and the entire delivery team must adopt. I discovered the term "quality assistance" from Atlassian, nine years ago, in this video.

 

In a high-speed delivery cycle, quality analysts and testers must absolutely evaluate the impact of their activities on delivery time. They can no longer afford to spend weeks and months ensuring that no issues disrupt the users.


"Quality is everyone's responsibility." This is a mantra you have likely heard before and may even use in your team. However, the past few decades have shown that only quality analysts are qualified to ensure the product is ready for use, unlike developers and other professionals in the field. This was true 20 years ago when projects were managed in a waterfall mode, delivering twice a year. Unfortunately, the belief that the tester is the only one to confirm this persists at all levels of management. The biggest challenge for quality analysts will be to break this belief.

 

The best position for quality analysts is to focus on providing help and support to the team that ensures quality. It is important to assist rather than assure because the latter term evokes more of a controller or police role. Quality analysts should act and be perceived like a Product Owner (PO), with the product being quality. They must ensure that the criteria for acceptance, verification, and validation of the product are also included in the stories. Think not only about the functional aspect but also about performance, security, and usability criteria. The main objective is to set everything up BEFORE development begins and to ensure that everyone shares a well-aligned vision of the work to be done. Thus, the analyst assists their team in preparing everything. The development team then has everything they need to deliver what is agreed upon... including the tests. Here too, quality analysts can assist their team by defining the testing strategy, expectations regarding test automation, datasets, and other items to provide with the code. The quality analyst must regularly question their team to identify their concerns about their role in verification and validation. They should act as a coach, training team members to strengthen their quality skills, so they can take on these responsibilities themselves rather than delegating them.


I can already hear some team members wondering what the role of the quality analyst will be if they no longer perform all the tests. In reality, among other responsibilities, the analyst will continue to support them by ensuring the quality of stories and documentation, writing test cases to reinforce the team's confidence, preparing datasets, exploring to reduce risks, finding implicit requirements that do not work properly, participating in incident management, and contributing to continuous improvement through metrics... And the list goes on!


It is time to move from the idea that "QA must test" to one where "QA helps the team have confidence in their tests." If you still use or hear this expression, I encourage you to review your team's lexicon and move from a quality assurance approach to a quality assistance approach.

 

Tap into our expertise and learn how you can elevate your quality assurance practices. Contact us today!

27 views0 comments

Recent Posts

See All

Comments