Quality assurance (QA) refers to the planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled. It is the systematic measurement, comparison with a standard, monitoring of processes and an associated feedback loop that confers error prevention. This can be contrasted with Quality "Control". which is focused on process outputs.
Quality Assurance Is Not Quality Control
The difference is that QA (Quality Assurance) is process oriented and QC (Quality Control) is product oriented.
And Testing, therefore is product oriented and thus is in the QC domain. Testing for quality isn't assuring quality, it's controlling it. Moreover, Testing is 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.)
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 Assurance Is Not Quality Control
The difference is that QA (Quality Assurance) is process oriented and QC (Quality Control) is product oriented.
And Testing, therefore is product oriented and thus is in the QC domain. Testing for quality isn't assuring quality, it's controlling it. Moreover, Testing is 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.)
- Quality Assurance makes sure you are doing the right things, the right way.
- Quality Control makes sure the results of what you've done are what you expected.
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.
The QA team's job is to see that standards, processes, and policies (or other governing/guiding "writ") are in place and carried out; to recommend and implement improvements to them, and to ensure that the people that need to know about them know about them. QA "audits" or "reviews" are intended to determine the efficacy of these "writs."
It's often easier to understand QA by an example: In one place (a large company with large projects), a QA's role supposedly to help project managers plan their projects - so that the projects follow certain organizational procedures; so that they include the required artifacts, events, and milestones; and so that the projects know what is expected of them and when in terms of reports, reviews, and documentation. As the project progressed, QA would conduct "checkpoints" along the way to see where the project may be developing risks, for example either by progressing beyond where they've got authorization to go, or where they may have need to escalate issues to management.
A Quality Assurance 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.
Why would "assurance" mean process-related and "control" mean product-related?
Because "assurance" means that you know you did everything needed to make something that works right, while "control" means that you have no idea whether any or all of your batch o'junk is worth anything until you examine each item.
The need to test ("control") is a function of the circumstance of the existence of bugs or lack of confidence. Whereas 'assurance' is a passive term with a more universal connotation. The need to "assure" is a function of building confidence regardless of the existence of bugs and isn't just about bugs, but of the entire effort.
The difference between QA and QC is largely one of power and control. QC is usually as service provided to development (i.e. under the control of development) and is responsible for providing that service. QA expects development to provide services to it (control development) and is not responsible for any result.
The above statement is a symptom of one of the biggest problems in the entire software industry. People don't know what "QA" is supposed to do (as defined in this page). As a result many that do QA, do it wrongly, and many that work with those doing QA incorrectly wind up hating QA because of the lousy experience they had with it.
QA, when done effectively in a project, should not even cross paths with developers except perhaps at the highest levels of management. Or to teach new developers the organizational processes, or teach existing developers about changes to existing organizational processes. And then later QA may interact with development to figure out whether the processes work and what needs to happen to make sure they work better. QA should not be causing developers to do any more work than they need to be doing to develop the work.
Quality assurance makes sure the project will be completed based on the previously agreed specifications, standards and functionality required without defects and possible problems. It monitors and tries to improve the development process from the beginning of the project to ensure this. QA is involved in the project from the beginning. This helps the teams communicate and understand the problems and concerns, also gives time to set up the testing environment and configuration. On the other hand, actual testing starts after the test plans are written, reviewed and approved based on the design documentation.
Testing methods based on The box approach:
Black Box Testing
Black-box testing is a method of software testing that tests the functionality of an application as opposed to its internal structures or workings. Specific knowledge of the application's code/internal structure and programming knowledge in general is not required. The tester is only aware of what the software is supposed to do, but not how i.e. when he enters a certain input, he gets a certain output; without being aware of how the output was produced in the first place. Test cases are built around specifications and requirements, i.e., what the application is supposed to do. It uses external descriptions of the software, including specifications, requirements, and designs to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the test object's internal structure. This method of test can be applied to all levels of software testing: unit, integration, system and acceptance. It typically comprises most if not all testing at higher levels, but can also dominate unit testing as well.
White Box Testing
White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing). In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements.
The need to test ("control") is a function of the circumstance of the existence of bugs or lack of confidence. Whereas 'assurance' is a passive term with a more universal connotation. The need to "assure" is a function of building confidence regardless of the existence of bugs and isn't just about bugs, but of the entire effort.
The difference between QA and QC is largely one of power and control. QC is usually as service provided to development (i.e. under the control of development) and is responsible for providing that service. QA expects development to provide services to it (control development) and is not responsible for any result.
The above statement is a symptom of one of the biggest problems in the entire software industry. People don't know what "QA" is supposed to do (as defined in this page). As a result many that do QA, do it wrongly, and many that work with those doing QA incorrectly wind up hating QA because of the lousy experience they had with it.
QA, when done effectively in a project, should not even cross paths with developers except perhaps at the highest levels of management. Or to teach new developers the organizational processes, or teach existing developers about changes to existing organizational processes. And then later QA may interact with development to figure out whether the processes work and what needs to happen to make sure they work better. QA should not be causing developers to do any more work than they need to be doing to develop the work.
Quality assurance makes sure the project will be completed based on the previously agreed specifications, standards and functionality required without defects and possible problems. It monitors and tries to improve the development process from the beginning of the project to ensure this. QA is involved in the project from the beginning. This helps the teams communicate and understand the problems and concerns, also gives time to set up the testing environment and configuration. On the other hand, actual testing starts after the test plans are written, reviewed and approved based on the design documentation.
Testing methods based on The box approach:
Black Box Testing
Black-box testing is a method of software testing that tests the functionality of an application as opposed to its internal structures or workings. Specific knowledge of the application's code/internal structure and programming knowledge in general is not required. The tester is only aware of what the software is supposed to do, but not how i.e. when he enters a certain input, he gets a certain output; without being aware of how the output was produced in the first place. Test cases are built around specifications and requirements, i.e., what the application is supposed to do. It uses external descriptions of the software, including specifications, requirements, and designs to derive test cases. These tests can be functional or non-functional, though usually functional. The test designer selects valid and invalid inputs and determines the correct output. There is no knowledge of the test object's internal structure. This method of test can be applied to all levels of software testing: unit, integration, system and acceptance. It typically comprises most if not all testing at higher levels, but can also dominate unit testing as well.
White Box Testing
White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality (i.e. black-box testing). In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements.
Next table shows the differences between them.
QA
|
vs.
|
QC
|
|
| Definition from ASQ.org Assurance: The act of giving confidence, the state of being certain or the act of making certain. QA: The planned and systematic activities implemented in a quality system so that quality requirements for a product or service will be fulfilled. Other definition QA is a failure prevention system that predicts almost everything about product safety, quality standards and legality that could possibly go wrong, and then takes steps to control and prevent flawed products or services from reaching the advanced stages of the supply chain. |
Definition from ASQ.org Control: An evaluation to indicate needed corrective responses; the act of guiding a process in which variability is attributable to a constant system of chance causes. QC: The observation techniques and activities used to fulfill requirements for quality. Other definition QC is a failure detection system that uses a testing technique to identify errors or flaws in products and tests the end products at specified intervals, to ensure that the products or services meet the requirements as defined during the earlier process for QA. |
||
As some process parameters cannot be controlled, QC department checks the
products or services for defects that happen due to these parameters,
trying to achieve the overall QC objective of providing a defect-free
product or service to the customers.
|
|||
* For this reason, one person cannot perform both activities (QA and QC) because will result in a conflict of interest.
|
|||
Examples
-
A QA audit would focus on the process elements of a project. e.g.: Are
requirements being defined at the proper level of detail? - Process documentation - Establishing standards - Developing checklists - Conducting internal audits |
Examples
- A QC review will focus on product elements. e.g.: Are the defined requirements the right requirements?- Performing inspections - Preforming testing |
||
Example
-
QC detected a recurrent problem with the quality of the products. QC
provides feedback to QA personnel that there is a problem in the process
or system that is causing product quality problems. QA determines the
root cause of the problem and then brings changes to the process to
ensure that there are no quality issues in future. |
|||
I've also found some articles they wrote the comparison between QA and QC as follows:
Quality Assurance:
1. Quality assurance meant for developing, organizing the best quality process
2. QA is process related
3. QA focuses on building in quality and hence preventing defects
4. QA: Deals with process
5. QA: for entire life cycle
6. Quality Assurance makes sure you are doing the right things, the right way.
7. QA is preventive process.
Quality Control:
1. Quality control meant for implementing the process developed by former team
2. QC is the actual testing of the software
3. QC focuses on testing for quality and hence detecting defects
4. QC: Deals with product
5. QC: for testing part in SDLC
6. Quality Control makes sure the results of what you've done are what you expected
7. QC is corrective process.
As conclusion:
Both departments are essential to maintain good quality of the deliverables.
And keep in mind no matter how you define QA and QC, the goal is: to delivery good quality.
its looking nice information sharing blog keep it up
ReplyDeleteFacility Management Software in UAE
Best Facility Management software in Abu Dhabi
Facility Management software company in UAE
Best FM software company in UAE
Top FM software company in Abu Dhabi
Nice Blog, When I was read this blog, I learnt new things & it’s truly have well stuff related to developing technology, Thank you for sharing this blog. Need to learn software testing companies, please share. It is very useful who is looking for
ReplyDeletesmart test automation platform
Mobile Testing Services
QA Services
Your post is so interesting to read. Good Luck for the upcoming update. ISO 22301 Certification in Saudi Arabia
ReplyDelete