An often overshadowed aspect of building great products is ensuring these products are reliable and perform as expected. Similar to physical products, the quality of a digital product has a large impact on the customer/user experience. Typically a quality assurance (QA) or testing team leads this effort. But, what is the difference between QA and testing, and does it matter? We believe so, and so should you.

The debate on QA versus testing is not new. In fact, it has been bantered about for more than a decade. At Dev bridge, we recently had our own internal debate on the difference between QA and testers. As our company grows and evolves, we wanted to align our titles to reflect what we actually do. Having partnered with numerous engineering teams on client projects, many may be having similar conversations. 

Some professionals are offended when called QA as it is impossible to assure quality of software with the activities they do. However, others do not like being called testers as they feel that they do more than testing (i.e., working closely with the team to prevent defects). Some may believe that the terms can be used interchangeably, yet QA and testing are completely different. To understand the roots of this debate, it is worth understanding what each term means. 

QA and testing came from industrial companies and were adopted to software engineering. QA is sometimes confused with Quality Control (QC), hence we outline the differences between the two as follows:

• QA is process oriented: Ensuring the processes used to manage and create deliverables work to prevent defects. QA uses audits and metrics as tools to monitor these processes.
• QC is product oriented: The processes, tools, and people focused on detecting defects. QC determines whether the end result matches expectations. 

QA in industrial countries might be associated with the process police, while QC sometimes might be considered as the end of production line activity or gate keeping, though it's not entirely true. 

Keeping the above definitions in mind, testing is actually part of QC activities. It is the process of executing a system with the intent of finding defects. If you consider the 'shift left' philosophy, which is embedded in agile principles, testing should be done as early as possible and in every stage of the software engineering process. A tester identifies what-if scenarios, exceptions, gaps in user stories, and acceptance criteria that are not testable, thus preventing defects instead of finding them at the end.

In summary, QA is a process, while testing is an activity embedded within QC. While the goal of QA and QC is to have a quality product at the end, both use different approaches and tools. Other activities that contribute to quality in addition to testing include groomings, plannings, and code reviews. All of these and more are part of the QA process. 

So... are we quality assurance or testers?

If we evaluate based on the above definitions, we believe it is the latter.

• We work in our teams from sprint 0 to find defects as early as possible
• We create testing strategies (formal or informal) and involve the entire team in the process
• We take an active role in groomings and plannings, reviewing user stories from testing perspective, identifying possible risks, gaps, discrepancies, etc. 
• We plan testing activities, carry out testing itself and interpret testing results
• We suggest and promote possible tools or activities that might improve our product quality.

Quality assurance should be everyone's responsibility. One cannot assure software quality by carrying out one or even several QC activities. Teams embed quality from the start by working together, listening to each other, helping each other, choosing the right tools and supporting process. Quality is about being responsible about one's work from the first thought to the last minute of service in production.