I think the answers to these questions really show the difference between the QA / test mindset and the developer mindset . . . devs would just shrug and say, "However you want to define them is fine." Testers, on the other hand, want to have the RIGHT answer!
–
Ethel EvansMay 6 '11 at 23:14

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.

+1 Agreed, a very good overview of the terms.
–
MichaelFMay 24 '11 at 12:59

3

I agree with this answer & I'd go even further with the testing being a subset of QA idea - As Michael Bolton puts it, as a Tester, you are not responsible for project budgets, staffing levels, deadlines etc - all of which have an impact on quality. As I see it, Testers provide information to the people who make the decisions on the state of the software
–
DuncNOct 21 '11 at 19:56

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 title a company uses for a particular role can be a good indicator of how the company views that role. For example if you feel there are major differences between a Tester and QA and a company is hiring for a QA person they may not be a good fit. Of course the only way to know that is to talk with them. You might be able to change that view.
–
Chris KenstApr 19 '12 at 18:00

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.

"Banging on the product until it breaks". I'm a little underwhelmed by this description.
–
testerab♦May 5 '11 at 22:31

@testerab: I could use 20,000 words to describe testing, including functional, UI, dataflow and integrity, hard algo, performance, scalibilty etc. I promise you'll hear all about testing from me as the site grows. For this particular sentence, that was what I came up with. I apologise for any hurt feeling of whelmness.
–
CarmiMay 6 '11 at 11:10

4

I guess I figure that as a profession, we really don't do ourselves any favours when we suggest that testing is a mindless task.
–
testerab♦May 6 '11 at 16:59

@testerab: I agree completely. You're absolutely spot on. We still get to make fun of ourselves though. I do see why you think that might confuse people as to our professionalism.
–
CarmiMay 6 '11 at 18:47

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.

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.

Textbook Answer

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.

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.

A random tangent: When it comes to titles you can pretty much call yourself whatever you want like QA Analyst or QC Analyst or Bug Bounty Hunter (my favorite). A fun game to play is telling someone who has no experience with software what your title is. See which one people understand better: Quality Assurance or Software Tester. =)
–
Chris KenstOct 20 '11 at 18:35

3

To be fair, there is a difference between "Assuring" quality and "Guaranteeing" quality. No one sends a build for release testing saying "There are zero bugs in this build", but instead "Our testing has has revealed no bugs in the build." It's about building confidence in the build. As far as quality control, I think it IS quality control. You do testing, you find significant problems, you prevent the build from going further: you control the flow of the build.
–
corsiKa♦Oct 20 '11 at 21:46

3

As a further note, quality is not necessarily free of defect: rather quality is that which produces customer satisfaction. As a tester, you put yourself in the shoes of the customer to determine if they would be satisfied (even with the bug) with the product. If you feel that as a customer you would not be satisfied, due to a bug, a missing critical feature, an incredibly awkward key combination or menu structure, or anything else, you deny the build from continuing.
–
corsiKa♦Oct 20 '11 at 21:48

2

It's good to generate confidence in the build but how do you have that confidence? Do you look at your test cases and go "everything passed, so we're good. I'm done!"? That assurance isn't real because you have no clue how well your tests have covered the code or the quality. Besides most people don't know how to define quality.
–
Chris KenstOct 20 '11 at 22:01

2

As far as customer interaction is concerned, as I stated, quality is already defined: what gives customer satisfaction. So a customer doesn't not need to be a judge of the product, but rather a judge of whether they like the product. As far as assurance not being real, this is where we get into the difference between assurance and guarantee. You don't put a stamp on that says "100% Free of defect". You put a stamp on that says "Probably good enough to go live". As far as between me and a dev, I actually am a dev, and we have to grab our ankles for our testers.
–
corsiKa♦Oct 20 '11 at 22:10

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 like the one sentence breakdowns. I would question the relevance of "final" in there. I would hope that QA would have a say in the readiness of the application for alpha, private beta, and public beta releases as well.
–
corsiKa♦May 5 '11 at 18:24

This is a terribly narrow definition of testing. What do you mean by "usually refers to"?
–
testerab♦May 9 '11 at 23:45

So you are saying testing is only checking (or simply testing = checking)? I thought testing and checking were different?
–
Chris KenstMar 24 '12 at 16:05

"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.

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 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 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).