- June 24, 2009
- Posted by: admin
- Categories: Agile Applications, Agile Project Management, Agile Quality Assurance, Blog, Business Dynamics
Reference: http://www.technewsworld.com/story/Is-It-Quality-Assurance-or-Quality-Control-67397.html
Is there a difference between quality control and quality assurance? Just night and day. Unfortunately, many companies believe they are the same, when in reality the differences are overwhelming.
Quality control, or black box testing, is chartered to ensure that the product is going to meet the user’s needs — not just to demonstrate that the program runs. A program can run and still not meet the user’s needs. The involvement of QC begins with the project specification. How can a tester test without knowing the client’s expectations?
There should be ongoing processes or standards to help differentiate what the client needs and what the client wants or expects. Clients normally want everything, but are not always willing to pay the price. The quality control people have to understand in great detail how the client will use the product in its environment. “It works on my machine” is not acceptable. Will it work on the client’s machine? This is the key to the success of the project.
QC will also have to test whenever there are changes to the product. Changes such as enhancements and fixes for bugs — perceived or otherwise — have to be tested. Often, there is no project manager involved during these processes; project management is not always available or assigned to the product after it has been released and comes back for maintenance.
Quality assurance, on the other hand, is concerned less about whether the product works than how it came together. Were proper processes followed? When it comes time for maintenance, will there be notes and references to fall back on? Have the test scripts and test cases been saved? Were there any lessons learned during and after the project? Quality Assurance owns the product from cradle to grave. Project managers may come and go, but responsibility for ensuring the product is maintainable and reliable during its lifetime rests with QA and QC.
Start With Quality Control
Let’s say that a tester has uncovered a problem. The first thing the QC people will do is document the problem. Failure to do this could mean the problem disappears, and no one knows how it was discovered. The tester documents the problem in the form of a problem report, referencing the specific requirement that failed, what the program should have done, what it did do, and why it doesn’t match the specific requirement.
The tester will also include any test scripts and test cases used to uncover the problem. Over 90 percent of test cases should come from the requirements. This is why the requirements-gathering process is so important. Then the tester will submit the problem report and go on to the next test.
All test scripts and test cases need to be saved, as they will be necessary to do regression testing during enhancements and bug fixes. If the cause of the problem is not identified and addressed, the problem will reappear later on — and again and again. Money will be saved by uncovering problems and documenting them as the project goes along, rather than waiting until the very end. Lessons learned is an ongoing process, not just one to be done at the end of the project.
One of the biggest complaints from testers is the lack of sufficient time to test. If they don’t have time to test, where will they find the time to work on lessons learned? They are too busy testing. However, it is not the quantity of testing that is done, but the quality of the testing efforts that matters the most. This is why it is so important for testing to be involved early in the process.
Enter Quality Assurance
Quality assurance enters the picture to uncover why a problem occurred and determine how it can be prevented in the future. After the problem is resolved, the tester will again retest the module or program to ensure it is fixed. Then it will be necessary to retest all of the modules that might be affected by the fix. This can be an overwhelming task if the tester and programmer do not have access to a “traceability matrix.”
A traceability matrix is a matrix that cross-references each program and test case to a specific requirement. Any time a change is made to a particular requirement, the traceability matrix will be able to identify what other programs could be affected by the change. There is never enough time to retest everything; thus, the traceability matrix will ensure that only those programs that might be affected will be retested.
The regression testing will reuse those scripts and test cases that have been previously stored, so it will not be necessary to rewrite them. This process is also necessary whenever an enhancement or fix is implemented into an existing product.
It is the responsibility of the tester to store test scripts and test cases in a folder that is external to the project. If the company is looking for repeatability and reusability, it will need to have access to these folders on every project. Don’t store them in the test plan.
Since most QC testers are intimately involved in the operation of the product and ensuring it will meet the client’s needs, who will do the administrative portion of the processes? Again, this is where QA comes in. The QA group must interface with everyone involved in the project. Nothing in the project should be modified without interfacing with the QA group. QA is concerned with standards, repeatability, and lowering costs. The QA group doesn’t know how to do many of the things that occur day to day in the processes, but it is chartered to ensure that these processes will remain the same, and everyone will use them.
Feedback Is Crucial
If you give the same requirement to 10 programmers, you will probably end up with 10 different versions of how to achieve it. QA’s job is to extract the best one, document it, and make it a standard. QA has to work with other people in each department and solicit input on how things should be done. Then, the QA group takes all of these inputs and goes through them and decides on the best one. The best one is then submitted back to the department for final review. When approved, it becomes the standard for the group and the company. The process may have to be repeated a few times to ensure that all participants give feedback.
Soliciting feedback is crucial to the success of companies. People come and go, but products remain out there in the field for years to come. Look at Y2K. How much money was spent on undocumented processes that were not in danger of failing? How much money could have been saved if standards were in existence, and QC and QA did the right job?
Both quality control and quality assurance are full-time jobs and are very time-consuming. They require different skills and resources. Both of these groups work together on the product from cradle to grave. “QA tester” is a misnomer. It is very difficult, if not impossible, for one person to do both jobs EFFECTIVELY. People who have both responsibilities almost invariably admit that they are unable to do both, yet they are assigned that responsibility. So, if they can’t do both, which one will get the higher priority?
That is obvious. Testing is more important. Yet is it really? If we never improve how things are done, will we ever do better? “Working smarter not harder” is a very realistic expectation — but how can we work smarter if we haven’t learned from our previous mistakes? Ongoing documentation on how processes were done is a QA responsibility. It will save time and money in the long run, and the company will become more efficient and profitable.
17 Comments
Comments are closed.
Answers (17)
Geoff Feldman is your connection (1st degree)
Geoff Feldman
“Hands-on” Software Architect and Senior Developer
see all my answers
Best Answers in: Web Development (11)… see more, Computers and Software (9), Software Development (8), Enterprise Software (6), Information Storage (5), Wireless (5), Offshoring and Outsourcing (3), Telecommunications (3), Starting Up (2), Blogging (2), Information Security (2), Occupational Training (1), Graphic Design (1), Search Marketing (1), Planning (1), Biotech (1), E-Commerce (1), Computer Networking (1), Using LinkedIn (1) see less
Actually in common use here in the US, I’d say the two phrases are used almost interchangeably with Quality Assurance being the more common one.
What you describe as Quality Assurance, I think of as Release Engineering. Release engineering is about repeatable builds and releases of the software.
Some of what you describe as Quality Control, I think of as developer testing. Unit tests principally. Integration testing, load testing, deployment testing is always done by a group apart from the developers.
The organizations capacity and funding for testing is usually limited. In these cases, a “religious fervor” is actually not helpful because it creates a focus on one area to the exclusion of another. It is helpful then to have quality goals and to test the goals are achieved. Microsoft is a great example of this philosophy. They know about many of the bugs that are “discovered” but choose to let them go in the interest of schedule and cost while ones with the greater impact are given the utmost attention. This is based on cold hearted selection of where to focus.
As always in development, it is about the plan. Decide what to do, how to do it, adjust for reality and execute.
QC activities include general methods such as accuracy checks on data acquisition and
Calculations and the use of approved standardized procedures for emission calculations,
Measurements, estimating uncertainties, archiving information and reporting. Higher tier QC
activities include technical reviews of source categories, activity and emission factor data, and
methods.
Quality Assurance (QA) activities include a planned system of review procedures conducted by
personnel not directly involved in the inventory compilation/development process. Reviews,
preferably by independent third parties, should be performed upon a finalized inventory following
the implementation of QC procedures. Reviews verify that data quality objectives were met,
ensure that the inventory represents the best possible estimates of emissions and sinks given the
current state of scientific knowledge and data available, and support the effectiveness of the QC
programme.
Records of QA/QC procedures are important information to enable continuous improvement to inventory estimates.
Manoj K. Garg, CEO
http://www.netcreativemind.com
| Web Software Development | SEO | Call Center | Data Management |
There are some confusions between those 2 terms, so ask people what they mean.
Quality Control ( usually called testing in software), is the activity of checking that the product answers the specifications defined either by the customer or by various technical standards valid locally or internationally for this specific product, i.e. safety, security, etc.
Quality Assurance includes :
a) The definition of the process of production of the product as well as the management of the production ( or the project) required to produce a product, like how to plan the work, how to staff the team, to make sure that the resources are there ( including the Quality Control processes).
b) Verification that the processes are followed and documented as required. Examples of standards in this area are ISO 9000 or CMMI .
I hope it makes the terms clearer
Adrian has detailed the difference between the terms very well. In my simple way of understand, QA is the process of ensuring quality through the understanding what is needed, defining how you will achieve it, who will be involved, steps to validate and the entire validation and reporting process for ensuring quality in a product or service. Quality Control is one step in the QA process which is the validation process defined above.
But both these terms are used for one another is every day use.
Software QA or QC, has to follow processes and correct business requirements. They should follow a certain documentation about the product, and if there are changes, make sure that the changes are approved and is documented by the products, or the Business analyst. it is not the QA’s role to document suggestions from other people but its sole role is to make sure Quality is at hand for the software to be presented and is bug free. Any changes on the software or enhancements on the software should be considered carefully by the QA, and Regression test comes. It is not the QA’s responsibility to research on some certain areas on how the product will get money on the net, rather it has to be an R&D’s role to provide research and the products team would approve the proposed ideas and research of this R&D person.
Links:
* http://www.developer.com/mgmt/article.php/3515426
Hello Ali,
In my experience, Quality Assurance does a great deal more than just overseeing the creation, implementation, and control of corporate procedures.
Quality Assurance does as it’s name suggests, in that it assures there are processes in place [and followed] to ensure the quality of services performed, or products produced/manufactured.
This entails involvement from the being of the process with Marketing and customer research to discover the needs of the customer and verify those needs are properly documented, through the development process with involvement in audits often as moderator of code reviews, they verify the correct version and code compilation for turnover to Quality Control testing, they oversee the Quality Control process [test setup, test procedures, milestone tracking, defect tracking], they verify installation procedures are in place for deployment, and they verify customer support documents, processes, and procedures are in place for deployment.
Quality Assurance follows and audits the complete product process, verifying the release of the “desired” product to the customer market; whereas Quality Control focuses on verifying the product functions as specified.
Best Regards, Theresa
My understanding of quality control and quality assurance can be illustrated in the following example:
You have a company that manufactures widgets. An order is placed for 500 widgets. Quality control would be employed to insure that all 500 widgets were of the same specifications needed to fill the order. It’s an examination of the finished product or service to meet the needs of the customer.
Quality assurance would be reviewing the process of creating the widgets. It’s documentation of the process of creating a widget from the ingredients used to create the widget to the dimensions needed to fill the order to make sure what is documented fits the process itself.
Hope that helps.
Hi Ali,
I see you are confused. But the answer is simple and based on words assurance and control, as quality is common in both phrases:
QA is one of many company’s processes – not operational, but supporting ones – which should be undertaken throughout lifecycle of your product or of your all operating processes. So it is much wider than just control.
QC is one of many QA processes, usually placed at some milestone point of your product lifecycle to check, if at the certain stage the product (or operational process) meets the criteria.
Other QA activities (undertaken in different or similar phases to QC) could be i.e. Review of Changes (to operational processes) Suggested by Employees, Q System Improvement etc., Review of Clients’ Feedback(depending on phase in the lifecycle).
Going back in time all quality activities started from simple QC of end-products in production industry, like i.e. checking if diameter lenght of holes in some metal part of a car is within certain range, but people realized that if they start quality checks sooner (not when product is already produced), their operational process can be more effective with less loses, i.e. it is worth to check if temperature in production hall is not too high, as it might cause too high diameter variation. And all those many checks are QA.
Later in time all QA activities (checks) became so numberous and related to each other that people started to integrate them all together and consider them as Quality System (QS).
After that, people integrated many different systems supporting operational processes into one big Integrated System, i.e. QS + Environmental S + Security S. Thay all are big value added to main processes.
ISO breaks down all processes very well, so studying that would be helpful to you.
In software world I would suggest sudying ISACA guidances regarding COBIT, CISA, as well as ITIL, CMMI models. They all interchange somehow, but I find COBIT as the most comprehensive.
Wish you luck!
Links:
http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Eisaca%2Eorg%2FTemplate%2Ecfm%3FSection%3DCOBIT6%26Template%3D%2FTaggedPage%2FTaggedPageDisplay%2Ecfm%26TPLID%3D55%26ContentID%3D7981&urlhash=Cxj7
http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Eisaca%2Eorg%2FTemplate%2Ecfm%3FSection%3DCISA_Certification%26Template%3D%2FTaggedPage%2FTaggedPageDisplay%2Ecfm%26TPLID%3D16%26ContentID%3D4526&urlhash=-v6_
Ali,
As I was reading through the first 6 responses, I was becoming increasingly concerned. These folks seem to be blurring the concepts of quality control (QC) and quality assurance (QA) due to a lack of understanding or based upon organizational titles at their respective companies.
Then I read Donna’s response and thought, ok, someone is getting close. Phyllis’ was even closer, and augments Donna’s statements nicely.
Here’s how I usually put it in layman’s terms:
Quality Control is making sure you did a certain thing right.
(i.e., built to specs, within tolerance, runs, defect-free, etc. – QC is an inspection activity performed against a specific deliverable or process step)
Quality Assurance is making sure you did the right thing.
(asking the questions – does the product fulfill the customer’s need?, is the build process repeatable?, are the build and delivery processes efficient / lean?, etc., and finally, how can we continuously improve?)
Best Regards,
Greg
Links:
* http://www.appliedqualitysolutions.com/
Coming from the engineering world, and specifically software engineering within the Defence/Aerospace industry, I like the following descriptions of the roles and activities of Quality Control and Quality Assurance.
At the risk of oversimplifying, quality control is involved in inspection and test. Inspect incoming and outgoing product to verify that what is being shipped matches the description on the shipping label: if the shipping label states that 100 bolts are being shipped, count the actual number of bolts in the batch. Set aside the mismatched batches for further analysis or correction of the problem; notify the required authorities of the problem. Count the number of inspections executed; record the number (and types) of failures.
Test to verify that the product exactly matches specifications: if the specifications state that a certain bolt must meet certain dimensions and fail at some particular stress level, any bolt measured that does not meet those requirements fails. Set aside the failures for further analysis or correction of the problem; notify the required authorities of the problem. Count the number of bolts tested out of the whole batch of bolts produced; record the number of bolts that failed and the types of failures.
Quality assurance is involved in ensuring that a product that meets the customer’s expectations (the definition of a “quality product”) has been developed and delivered to the customer. Based upon the principle that there is a methodical process for doing any extended activity (such as developing a product) and the principle that a regular, repeatable process (or habit) is much more easily analyzed for kinks that may introduce problems, QA helps to establish development and management standards and processes. QA periodically takes a formal, detailed inspection of — audits — work practices to determine if they are being completed in accordance with standards and processes. Using the failure data generated by QC and the audit findings, QA attempts to determine what the cause of the problem may be and then introduces resolutions that attempt to fix the problem by preventing it from re-occurring. These documented procedures may be informal and proprietary, or they may be required by development or quality management standards or regulations.
QA is all-encompassing and must be independent of both the development and project management functions to be truly effective; QA must have the authority to report to senior management that problems are occurring — problems that may very well affect the quality of the product being developed and delivered to the customer — and the authority to stop delivery if necessary. QC may be a sub-function of QA, but QA should not be a sub-function of QC.
These descriptions of QC and QA may be extended to the IT software development industry. QC would be the group that performs software testing; QA would be the high-level function that manages and validates the complete software development life cycle, from project planning through to delivery of the final product. The software test group does not prevent problems from occurring; it merely determines if any problems have been introduced into the product.
Ali,
I must confess, I am in agreement with observations of Mr. Zimmermann.
QA and QC can be seen as Proactive and Reactive measures. QC is more Post fact. QA is essentially before fact. Let me explain.
I spend $300K in gathering requirements and another $600K in coding. My QC team will be present right from reqiurements stage, as they need to understand what specifications they should test. When developers code, QC team develops test scenarios, test cases and test data. Once code is released to QC team, they start testing. Surprise, Surprise….The code is NOT doing what it is supposed to do,as my architects have botched up. I now need another 200K to add the missing functionality, retrofit the new code to the current mature code and retest. My schedule is behind by 30% and my scorecard looks like a Coca Cola classic can- full of red color.
This is a pure QC play. Good news is, I caught the bug before going live. The bad news is, I caught it-post fact- After the producing the code, which is always expensive. Let me add another dimension. Complete test coverage is a myth and expensive. So, I know I cannot completely test and hence dont know how many defects I am passing to production. That unnerves me, as I cannot assure the quality of my product. I dont know how much I should plan for warranty, post production support, lost customer value and possible litigation. I also know that catching things early in the game is less expensive and healthy to my Cost/Schedule. This essentially begs the question, Is there anything I do, so I can prevent than fix? ..ha..now you are talking Quality Assurance.
The mid 20th century was ruled by QC and tools such as SQC- Statistical Quality Control. Deming changed the game altogether. His focus was TQM, Total Quality Management. Quality everywhere-right from hiring ‘Quality people’ ‘Quality Raw material’ ‘Quality Engineering’. The philosophy was, if you have Quality from beginning, the Cost of Quality(Cost of inspection, bug fix, rework..etc) will come down and increase ‘Releability’. the second half of 20th century was ruled by QA, with Japanese ruling the roost. Toyota pioneered Quality Assurance to new heights. To this date, Toyota is the only company that is not CMMi levl 5 company, ISO certified, Siz Sigma Certified, yet highly respected for its relieable products and World Class manufacturing practices. For Toyota’s methods were focussed on preventing errors before they happened. Any Quality framework aims for the same. ‘Hey, here. Take this process. Do it as it says. I can garantee you that it will generate only 5 defects per million parts..”. So , if I follow “True” QA processes, I would have figured out that my architects had botched up much earlier than in a later stage like testing. As it happens, every organization starts a QA department with right intent, somewhere the ‘QA’-ness is lost or downsized, what remains is QC and leads to the common confusion-QA is ‘the’ testing department. Its ironical that the QA discipline whose holy purpose to prevent errors, gets erroneously identified with QC 🙂
Hope this helps.
Ram
Hello Ali,
Best answers, as always, depend on the definitions of the terms used. Since we are all mostly business/technology oriented, I think most of us would agree that the definitions most agreed to are those in Wikipedia. (Hope you got through the logic of that sentence. 🙂 ) Accordingly:
Quality assurance
From Wikipedia, the free encyclopedia
Quality assurance, or QA for short, refers to planned and systematic production processes that provide confidence in a product’s suitability for its intended purpose. Refer to the definition by Merriam-Webster for further information [1]. It is a set of activities intended to ensure that products (goods and/or services) satisfy customer requirements in a systematic, reliable fashion. QA cannot absolutely guarantee the production of quality products, unfortunately, but makes this more likely. Two key principles characterise QA: “fit for purpose” (the product should be suitable for the intended purpose) and “right first time” (mistakes should be eliminated). QA includes regulation of the quality of raw materials, assemblies, products and components; services related to production; and management, production and inspection processes.
It is important to realize also that quality is determined by the intended users, clients or customers, not by society in general: it is not the same as ‘expensive’ or ‘high quality’. Even goods with low prices can be considered quality items if they meet a market need.
Quality control
From Wikipedia, the free encyclopedia
For other uses, see Quality control (disambiguation).
In engineering and manufacturing, quality control and quality engineering are used in developing systems to ensure products or services are designed and produced to meet or exceed customer requirements.
Quality control is the branch of engineering and manufacturing which deals with assurance and failure testing in design and production of products or services, to meet or exceed customer requirements.
Stated “elegantly”, QC is the execution of processes that make sure the product is delivered to specifications; QA is the specification of QC processes and the audit of the execution of those QC processes.
Links:
* http://en.wikipedia.org/wiki/Quality_assurance
* http://en.wikipedia.org/wiki/Quality_control
Well – I know that many assume these are interchangeable but there’s actually a pretty big difference. Quality Control is – as has been pointed out – the method of placing controls into the process to insure that quality is rolled in. Quality Assurance – is just that – it provides assurance that quality standards are adhered to…. which semantically has a big difference.
So – keep in mind I can provide assurance processes to you that quality is baked in, or I can control that quality is baked in. See the difference?
Which would you prefer?
Hello Ali
Interesting reading. Here is what I was able to dig up on the distinction/difference between QA, QC and testing (according to ANSI/IEEE standards and a variety of other sources):
* Testing: The process of executing a system with the intent of finding defects including test planning prior to the execution of the test cases.
* Quality Control: A set of activities designed to evaluate a developed working product.
* Quality Assurance: A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.
The key difference to remember is that QA is interested in the process whereas testing and quality control are interested in the product. Having a testing component in your development process demonstrates a higher degree of quality (as in QA).
Many people and organizations are confused about the difference between quality assurance (QA), quality control (QC), and testing. They are closely related, but they are different concepts. Since all three are necessary to effectively manage the risks of developing and maintaining software, it is important for software managers to understand the differences. They are defined below:
* Quality Assurance: A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.
* Quality Control: A set of activities designed to evaluate a developed work product.
* Testing: The process of executing a system with the intent of finding defects. (Note that the “process of executing a system” includes test planning prior to the execution of the test cases.)
QA activities ensure that the process is defined and appropriate. Methodology and standards development are examples of QA activities. A QA review would focus on the process elements of a project – e.g., are requirements being defined at the proper level of detail. In contrast, QC activities focus on finding defects in specific deliverables – e.g., are the defined requirements the right requirements. Testing is one example of a QC activity, but there are others such as inspections. Both QA and QC activities are generally required for successful software development.
Controversy can arise around who should be responsible for QA and QC activities — i.e., whether a group external to the project management structure should have responsibility for either QA or QC. The correct answer will vary depending on the situation, but experience suggests that:
* While line management should have the primary responsibility for implementing the appropriate QA, QC and testing activities on a project, an external QA function can provide valuable expertise and perspective.
* The amount of external QA/QC should be a function of the project risk and the process maturity of an organization. As organizations mature, management and staff will implement the proper QA and QC approaches as a matter of habit. When this happens only minimal external guidance and review are needed.
Kind regards
Chris
It is quite easy to confuse these, but I see them quite clearly different.
QA is what you promise your customer, end service user, internal staff stakeholders etc etc about your product, service, processes.
QC is one aspect of enabling QA, there may be a number of QC activities you conduct, for example, compliance monitoring, testing, mystery shopping, performance sampling, stake holder feedback analysis.
Hope this helps.
According to:
http://justetc.net/knowledge/displayArticle.php?table=Articles&articleID=650
Quality management has three aspects:
1. Quality planning – plan
2. Quality Executing – quality assurance – execute
3. Quality controlling – monitor and control
Quality planning – plan
Identify quality specifications and requirements for the project. Plan hos the quality specifications will be met.
Output:
Quality management plan
Quality metrics
Quality checklists
Process improvement plans
Quality baseline
Tools:
Cost benefit analysis
Benchmarking
Cost of quality
Quality assurance
Remember it is not quality control, it is just executing the development in such a way so that the quality requirements are met
Output:
Requested changes
Requested corrective actions
Modifications to Project management plan
Input
Quality management plan
Quality metrics
Quality control measurements
Quality Control
Quality Control checks if the quality requirements are met or not. It is done throughout the process/development/production life cycle. Quality Control uses statistical sampling
Tools for Quality Control:
Cause and effect diagram: Shows how different factors relate together and affect the quality
Control Charts: Uses statistical sampling and known as statistical process control.
Example: take quality mesurements of different samples. Find the avergae quality. Draw a line with the average quality. Plot all the samples’s quality. Draw the line for upper quality limit. Draw the line for lower quality limit. If all/most points are in between the process may be in control. If seven consecutive samples fall on one side of the avergae line the samples must be inspected.
Flowcharting: Shows how different components relate and determine where quality problems may occur. Example: Cause and effect diagram
Histogram:
Pareto chart: Histogram-shows defects ranked from greatest to least.
Pareto law: 80% problems come from 20% problems. Pareto chart is used to find the root causes of the problems.
Run Chart: Displays quality over time. Example: Time/month on X axis, defects per thousand on y axis.
Scatter Diagram: Plot all data and try to find the trends Statistical Sampling: Take a sample randomly and measure quality
Inspection:
Defect repair review
Some Terms Total Quality Management: Everyone in the company is responsible for the quality and can influence the quality of the outcome
ISO 9000: Ensures that companies document what they do and do what they document
Statistical Independence: Two samples are not dependent on each other
Mutually Exclusive: One choice excludes the other
Standard Deviation: Calculate the mean. Then find difference between each data point and the mean. Square each of the differences. std dev = SQRT((sum of the squired differences)/(count data points – 1)). The higher your standard deviation the more diverse the data points.
Six Sigma: six sigma standard deviations (99.99966% of the data points) meet customer’s quality limits.
Prevention vs inspection:
Attribute sampling: conforms quality or not. binary
variable sampling: How well something conforms to quality
Special causes: Unusual and preventable
Common Causes:normal
Tolerance:quality limis for product acceptance Control Limits: Three standard deviation above and below the mean.
Quality control works on behalf of the manufacturer to make sure the product is created according to specifications; Quality assurance works make sure it performs as promised for the client or buyer.