In the software industry, most job titles are perfectly aligned to the work performed. A “Project Manager, manages projects. A “Software Developer”, develops software. A “Business Analyst”, analyzes business processes. A “Software Architect”, architects software. But does a “Quality Assurance Analyst” assure quality? Absolutely not! They test software and detect defects. They are testers! The entire software development team is responsible for assuring the quality of software – not just QA analysts.
QA vs. QC vs. Test
The discipline of software quality grew out of the principles of manufacturing quality in the 1960s and 1970s. Fundamentals of building ‘widgets’ as a product were applied to building software as a product. In the early 1980s, the Quality Assurance Institute (QAI) defined the body of knowledge for software quality, similar to the body of knowledge of project management (PMBOK) from the Project Management Institute (PMI) or other professions. In the software quality body of knowledge there is a clear distinction between quality assurance (QA) and quality control (QC). It states:
“Quality Assurance (QA) is the processes, tools and people focused on defining and implementing the processes to prevent defects”. Six Sigma black belts, Lean and Kanban experts, and Agile coaches are all examples of today’s QA professionals, as well as anyone else who is driving process improvement or transformation within organizations.
“Quality Control (QC) is the processes, tools, and people focused on detecting defects”. Testers perform the QC role as well as all team members involved in finding defects through reviews, inspections, checkpoints, demos, testing, etc. And of course, the current trend of ‘shift left’ to find defects early in the software lifecycle is better than finding defects a week before ‘go live’ or ship date.
So why are testers and testing organizations often called QA? Some companies call their testing organizations – “QC”, thus recognizing their defect detection role. I am not sure why and how testing became QA in the 1990s. But I am an advocate of calling people who test software – testers and put the responsibility for assuring quality into the hands of the entire project team. Oftentimes, when a defect slips into production, the question is asked, “Why didn’t QA catch it?”. A production defect is not a testing issue. The entire project team (responsible for assuring quality) must address why the processes to build the software and the processes to check the software failed.
Shift Testing Left for Quality Assurance
Today true QA (prevention of defects) is embedded in the ‘shift left’ principles for software testing. Agile practices enable testing to shift left within the SDLC by bringing the tester to the table with the product owner, developer and business analyst in discussions of user stories and acceptance criteria at the initial kickoff of product development. The tester can identify what-if scenarios, exceptions, gaps in user stories, and acceptance criteria that are not testable, thus preventing defects that would have been discovered late in a traditional Waterfall project. Tester and developer collaboration shifts testing earlier through unit tests for increased code coverage, integrating unit tests for functional tests, and then incorporating functional tests into end-to-end business flow tests and regression tests. Detection of defects during sprints provides near real-time feedback to developers on the software’s quality so corrections can be made not only to the code but also to the development processes to prevent additional defects.
QA and testing should not be interchangeable words. The new definition of QA should revert back to the original definition of QA in the 1980s. QA transforms or continuously improves the processes and methods that are used for software delivery. QA’s focus is on preventing defects and thus assuring the quality of the software product. QA is every project team member’s responsibility; it’s not a role within the project team.