Is there a difference between
"quality assurance"? If so, what are the main goals of each process? What are the critical differences?
Is there a difference between
There is a useful blog post explaining the historical distinctions between Quality Assurance and Quality Control. I would suggest the latter is an appropriate alias for what we would term "testing"
In essence, the author summarizes that:
Quality Assurance - Prevention of faults by inspecting & testing the process
Quality Control - Detection of faults by inspecting & testing the product
I would say it's best described that testing is a subset of QA.
Your goal of testing is to ensure the functional requirements and metrics are met. This could be computational performance, clicks-per-action, user throughput, feature-completeness, defect rate, etc.
Quality-Assurance is a broader-reaching goal that simply asks "Is the customer going to be happy with this?" Obviously, you need to meet the metrics and requirements detailed in testing in order to achieve this. But there's a certain emotional aspect that testing can't cover. Is it pretty? Is it innovative? Does it get the job done? (It can meet every requirement and still not get the job done!)
Disclaimer: This is simply my interpretation of these two concepts. It may differ from those in the SQA community, and may differ from the majority opinion.
Edit: I bolded three words/phrases per as a tl;dr
There's no such thing as Quality Assurance or Control in Software. (Unfortunately most tester's don't seem to get this.)
Quality Assurance and Quality Control both come from manufacturing where you can physically assure customers won't receive bad products (or rather reduce the chance they will) by withholding defective ones or fixing the process. This can be done through lean manufacturing, Six Sigma, etc. - Forgive me, I'm not up to date on process and manufacturing improvement!
This can't usually be done in software. Software development is far more like design which is more intuitive and unique and less like manufacturing where you are producing the same piece over and over again. Testers have no way to assert control or assure quality. Instead of asserting control all we can do is point out the problems we find and work with developers, technical leads, etc. to fix them. Usually we can't force them to fix all of the problems, just one's deemed high enough by consensus of the team (hopefully).
Since we can't control quality (we usually don't fix bugs), how do we assure quality? We don't! We never know how many defects are left or how severe they may be. So why use titles that don't convey true meaning?
Software Testing means we learn and explore the system while applying our knowlege, experiences, judgements to find problems.
Here's a good link.
Generally, at least in my end of the professional puddle, testing refers to the activities of banging on the product until it breaks. This is the part of QA that most people find intuitive and easy to grasp.
Quality assurance is the entire process of finding issues (testing), documenting them, verifying their fixes, and most importantly, improving the development and testing processes so that less bugs occur in the future.
For example, QA would include making sure that merging the code from one version to another is done to certain standards, which straight testing wouldn't include.
Basically, QA should be about improving the process, not just the results.
If you are trying to determine what jobs to apply to based on title, I think the best current practice is to pay less attention to the terms used and more attention to the company culture and the specifics of the job description. If you are trying to communicate with testers or QA folks, I think the best current practice is to use other words if you want to convey a specific meaning that you associate with one of those phrases, and use either phrase when you want to refer to testing or QA in general.
One answer (given above) is that one is about process, and the other is about verifying functionality. In practice, I don't think any skilled tester is going to claim that their job involves nothing but verifying functionality, and this definition has the sad effect of turning "tester" into a derogatory term. I've also seen that testing is about "checking" and QA is about a more organic approach that includes exploratory or ad-hoc testing. This has a similar problem. I find that what QA / testers do as far as process vs. functional verification or using a variety of approaches has more to do with seniority than with job title.
I strongly suspect regional biases are really the major difference between the terms. "Tester" has a positive vibe in the Pacific NW, IME, but "QA" often implies that the company doesn't really get tech. Yet this seems to be almost the opposite of what most people get from the terms "tester" and "QA". This local phenomenon might be the influence of Microsoft and Amazon, with their "SDET" position (Software Development Engineer in Test). It also might be a result of the more casual NW tech culture, where wearing a tie to an interview could very likely reduce your chances of getting hired at any major tech company. "Quality Assurance" just sounds too "business-like" and stodgy to my ears. When I see that, I think the entire company is run by bureaucrats. "Tester", on the other hand, is easier to say, less formal, and doesn't blur in with the rest of the acronyms being used.
The analogy I like to use, to explain the difference between quality control (aka testing) and quality assurance is an assembly line analogy. Quality control is when you check what comes off the assembly line, to verify that it meets the specs. Quality assurance is when you check what goes into the assembly line. To further explain the analogy, consider an assembly line where 100% of the products produced are defective: any failure in quality control means defective products escape to your customers. Alternatively, consider an assembly line where 100% of the products produced are "good": any failure in quality control means you fail products that are actually good. Quality control is the gatekeeper at the end of the assembly line - it doesn't check the assembly line - just what comes out.
The point of quality assurance is to ensure that the assembly line is itself working. Like a thermostat, the ideal is to verify that the assembly line can produce good products.
Today, almost every organization has a QA department that is responsible for “testing” software applications to discover and eliminate bugs. However, there is a fundamental flaw in this definition of the role of QA in an organization. Most executives that I have talked to, fail to understand the difference between Quality Assurance and Testing, and oftentimes use these terms alternatively.
So, what is the difference between QA and testing, or rather QA and Quality Control (QC)? Before we talk about QA vs testing, let’s try to understand what exactly quality control is and why I brought it up!
Quality control is a set of “activities” that need to be performed in order to detect problems during production and before the product goes live. These activities ensure that final deliverable meets the specifications and quality standards set by the organization. QC often includes peer reviews, “testing”, code reviews etc.
In theory, quality control can be achieved with minimal testing. For example, a thorough review of source code and checks for known previously problems can reduce the possibility of defects and might be enough to meet the quality standards set by the organization. However still, in most cases, testing is the most important activity for quality control, but it is not the ‘only’ activity. Quality control is extremely important for ensuring that applications are bug free and meet the specifications and requirements, but QC might not always be the most efficient ways of ensuring quality. This is where Quality Assurance plays its role. But it is a concept that is often misunderstood by even the most experienced professions.
To put it in simple words, Quality assurance is about engineering “processes“that assure quality. Now let’s try to understand it better!
The keyword to pay attention to is “processes”. QA extends far beyond what we call the ‘software testing team’. The goal is to develop high quality products in the most efficient way, and it cannot be achieved by testing alone. Defects occur because something somewhere did not happen the way it needed to. Testing might help in detecting those defects, but not in avoiding them. A defect once fixed cannot ensure that it won’t occur again, even if the root cause is found. The process or the system that allowed that defect to occur is what needs to be re-engineered, and this is what we call quality assurance.
Everyone who is involved in the end to end development process, including analysts, developers, testers, managers etc., is an important player in assuring quality. In fact, QA might not involve testing at all. It might go against the typical notion that many professionals have about QA. But imagine this: If a company wanted to bring down its defects per million ratios, would testing alone be able to help achieve this goal? The answer is no, because in practice, not every defect can be found and fixed. However, if the processes that go into developing a product were reviewed and best practices were implemented, the load on testing team is likely to reduce. It is for this reason a lot of auditors focus on the processes were followed rather than focusing on the amount of testing an organization does.
To summarize, Quality assurance is a set of processes that help “avoid” defects and assure quality. While Quality Control is a set of activities that help detect defects and quality issues before the products reach the hands of end customers. Testing is one of the ways of detecting those defects. In order to deliver high quality products, organizations should focus on QA rather than merely scaling up their quality control efforts.
I think that there are two answers to this question, the textbook answer and the "in reality" answer.
Common usage answer
Personally, I think that most people tend to use these terms interchangeably to both mean the same thing. I think the sort of people who commonly do this who work with IT, but aren't part of IT itself, like business users.
According to Wikipedia
Quality assurance is the systematic monitoring and evaluation of the various aspects of a project, service or facility to maximize the probability that minimum standards of quality are being attained by the production process.
So to me, that implies assuring that you are operating in compliance with a Quality Assurance Standard, say you are a shipwright and you meet "ISO/DIS 30005 Information control for hazardous materials in the manufacturing chain of shipbuilding and ship operations" is pure QA.
Software testing is the process of verifying and validating that a software program works as expected.
Where it becomes fuzzy is that there is an ISO standard for sofware delivery, so I sould suggest that if you are testing for compliance of a standard then you are performing both Testing and QA.
QA and Testing both are responsible to make software better, but QA enhances the quality via improving the development process, ensure good customer experience & become pro-active throughout the product lifecycle but Testing enhance it via finding bugs, become active after coding, examine the code as per end user.
"Quality Assurance" is not a real thing. You can't ever assure quality. Users are always going to find bugs that were missed in testing, because they'll try your product in ways you never imagined (huge data sets, weird file types, large scale, legacy hardware, etc.). All you can do is reduce risk by trying to improve test coverage and frequency.
In manufacturing, quality assurance is a systemic, business-wide process (or a collection of processes, if you prefer) for improving quality, and quality control is a manufacturing process that attempts to measure quality by testing random samples of the product.
Software is not a manufacturing process, and a manufacturing-oriented notion of quality control is nonsensical for software. (Software media may be manufactured, and one might apply quality control to software media, but of course those measures would not impact the quality of the software itself.)
In that sense, all software testing is a kind quality assurance.
For me, quality is whatever the customer wants or desires; Through the various and many verification and validation techniques we employ throughout the delivery lifecycle we try to ensure the product being delivered meets those customer wants or desires.
Software testing is but a means to an end, it allows us to state that for those bugs/defects that have been observed a resolution has been agreed and delivered. However Software testing cannot answer for the many un-observed bugs/defects that have not been observed.
In a regulated environment (e.g., medical devices regulated by FDA), "quality assurance" really doesn't have a lot to do with software testing. The Quality Assurance organization oversees all aspects of product development (hardware, software, chemistry) and ensures that nothing is released which doesn't adhere to the company's quality system. In a regulated environment, software testing is more typically referred as "software validation" (job title of "software validation engineer" is common).
QA efforts should be involved from planning to deployment and even post-release bug review. QA engineers should be product experts who can plan before a Dev even touches the keyboard, assist Devs in delivering the right functionality, and give timely feedback by testing the code developed.
It is a mistake to keep the tester or QA engineer's involvement at the end of the line. Everything costs more the further down the line.
Testing activities are involved as soon as the code is deployed to an environment, unless you can lead off with some automation ahead of project code completion. A tester is a role to be filled during a window of the development process.