Software Quality Assurance (SQA) and Structured Software Testing (SST) are completely different fields. Every single book on the topic (textbooks, course materials, you name it) make this clear. In fact, most emphasize how important it is that these fields be completely separate. Consider:
- Quality Assurance is responsible for auditing and ensuring all aspects of work meet agreed upon quality standards.
- Therefore, if QA is also responsible for Structured Software Testing, who is going to audit the testing team for compliance and quality of deliverables?
Quality assurance is the “cop” that makes sure we all do our job right. It has the authority to say “hold it, something’s not right.” Testing is the organization that performs regression analysis on a product to see if it works right. The skills required for these two disciplines are dramatically different — as much as business management and programming.
The value in a QA organization is that it is independent. It focuses entirely on ensuring quality across the organization. Would you want development, project management, requirements management, configuration management, verification & validation, customer service or any other project discipline to report to QA? Why should testing be any different? The bottom line is simply that if testing reports to quality assurance its independence is compromised — the organization becomes vested in representing testing in the best possible light and, just possibly, taking shortcuts or letting a few things slide.
I realize that a large segment of the industry seems to use a different terminology, lumping testing under quality assurance. It’s unfortunate, because doing so handicaps both organizations. It’s important to realize the difference between the activities of ensuring quality in a project (largely focused on standards of process), and fault testing (activities that perform hands on fault detection and diagnosis).
The activities of quality assurance focus on things like quality assurance plans, project audits, requirement audits, checklists, enforcing standards and process, checking the results and deliveries of different teams, and discovering discrepancies between requirements, project artifacts, and functional goals. Quality assurance, as a general rule, spends more time looking at what the project teams are doing, performing audits on the work generated by each team, and figuring out what hasn’t been done according to agreed upon standards.
Testing, on the other hands, focuses on test planning and management, test case development, test execution, regression analysis, performance testing and defect diagnosis. These are “hands on the software” activities and much more akin to programming than auditing. Indeed, with today’s testing tools and complicated programming environments it can be a very “in the code” experience.
Keep your organization healthy and your teams focused on their competencies. Don’t disregard the value in centralizing authority for specific roles with specific teams — it lets them do their job well, without distractions and without muddying the water with conflicting interests.