Some of you ask me about the difference between Software Quality Assurance (SQA), Software Quality Control (SQC) and Software Testing. Basically, SQA focuses on issues related to the process that create the software product. SQC focuses on the issues related to the software products. Testing is the method of SQC to make sure that the product works as expected.
Sometime, people confuse SQA with Test and consider SQA as a testing organization which is NOT correct. The IEEE Standard. 12207-2008 stated that “The purpose of the Software Quality Assurance (SQA) is to provide assurance that work products and processes are complying with predefined plans.” The standard also stated that the SQA process should be coordinated with the related project activities such as verification, validation, review and audit processes to identify non-conformances. It means that SQA assures that products and processes comply with the project plans and organization’s standard. The standard requires SQA to assures that these processes are documented, followed and consistent with the company’s policies. The products are fully satisfy the requirements and are acceptable to the users. For example: SQA reviews project requirements, architect and designs to ensure that they are documented accordingly and project team members are following the organization’s process to develop software. SQC and Testing executes the software programs to make sure that it works and meets requirements.
The SQA process can be described as follows:
Define Quality Assurance Plans to identify what to do to ensure quality.
Support Project Manager to define standards, guidelines and other techniques for the projects
Ensure systematic quality control of processes and products such as reviews, inspections, audits as well as configuration management/control, production release, project control, supplier contracting and management, document control, operations and support, maintenance, backup and recovery, and security.
Maintain quality records to track issues.
Analyze and report on quality issues to management.
Maintain and improve quality of products.
Because SQA always checks for any non-compliance and some developers do not like to be monitored, there are often conflicts between them. Some developers consider SQA is like a “police” and do not show much respect to their works.
This is mostly caused by lack of quality training for developers and the fact that many SQA are also NOT well trained and do NOT have enough experiences to demand respect. I have seen many people who work as SQA only have limited software experiences. Many managers do NOT consider SQA as important and often assigned new people, who do not have a lot of experience into this jobs. Some managers even told me: “If they can NOT develop software well, we put them to work as SQA”. This is a very big mistake and that is why many SQA are not so successful in their jobs. That is why so many software have defects.
The most successful SQA usually come from Technical Lead group, who are experienced developers. These people often lead projects, solve technical problems, and provide training to new developers. They know software development well, know development process well, and they are respected by developers. These people are very proactive in guiding, training, and defining the process so by promoting them into SQA is a natural progressing in their career. Many managers argue that since they are very technical, they are needed to work in project but my argument is every project need someone to ensure quality and investment in SQA is essential for the successful of the project.
In my experience, instead of checking for non-compliance and demand corrective actions, the proactive SQA must establish an environment that promotes quality and covers the full life cycle of development from conception through completion. The SQA must communicate the important of process compliance to create quality products and train developers to follow the process accordingly. Rather than merely confirming compliance to plans, QA must ensure that developers understand all necessary steps to create an accurate, complete, and high quality products. Basically a proactive SQA is a teacher, a mentor, a coach, and a guide to help developers to deliver quality products and continually improve the way they develop software.
Some of you ask me about the difference between Software Quality Assurance (SQA), Software Quality Control (SQC) and Software Testing. Basically, SQA focuses on issues related to the process that create the software product. SQC focuses on the issues related to the software products. Testing is the method of SQC to make sure that the product works as expected.
Sometime, people confuse SQA with Test and consider SQA as a testing organization which is NOT correct. The IEEE Standard. 12207-2008 stated that “The purpose of the Software Quality Assurance (SQA) is to provide assurance that work products and processes are complying with predefined plans.” The standard also stated that the SQA process should be coordinated with the related project activities such as verification, validation, review and audit processes to identify non-conformances. It means that SQA assures that products and processes comply with the project plans and organization’s standard. The standard requires SQA to assures that these processes are documented, followed and consistent with the company’s policies. The products are fully satisfy the requirements and are acceptable to the users. For example: SQA reviews project requirements, architect and designs to ensure that they are documented accordingly and project team members are following the organization’s process to develop software. SQC and Testing executes the software programs to make sure that it works and meets requirements.
The SQA process can be described as follows:
Because SQA always checks for any non-compliance and some developers do not like to be monitored, there are often conflicts between them. Some developers consider SQA is like a “police” and do not show much respect to their works.
This is mostly caused by lack of quality training for developers and the fact that many SQA are also NOT well trained and do NOT have enough experiences to demand respect. I have seen many people who work as SQA only have limited software experiences. Many managers do NOT consider SQA as important and often assigned new people, who do not have a lot of experience into this jobs. Some managers even told me: “If they can NOT develop software well, we put them to work as SQA”. This is a very big mistake and that is why many SQA are not so successful in their jobs. That is why so many software have defects.
The most successful SQA usually come from Technical Lead group, who are experienced developers. These people often lead projects, solve technical problems, and provide training to new developers. They know software development well, know development process well, and they are respected by developers. These people are very proactive in guiding, training, and defining the process so by promoting them into SQA is a natural progressing in their career. Many managers argue that since they are very technical, they are needed to work in project but my argument is every project need someone to ensure quality and investment in SQA is essential for the successful of the project.
In my experience, instead of checking for non-compliance and demand corrective actions, the proactive SQA must establish an environment that promotes quality and covers the full life cycle of development from conception through completion. The SQA must communicate the important of process compliance to create quality products and train developers to follow the process accordingly. Rather than merely confirming compliance to plans, QA must ensure that developers understand all necessary steps to create an accurate, complete, and high quality products. Basically a proactive SQA is a teacher, a mentor, a coach, and a guide to help developers to deliver quality products and continually improve the way they develop software.
http://science-technology.vn/?p=2670