In software projects, many technicians often use the two terms QA (Quality Assurance) and QC (Quality Control) mixedly; even some professional companies that implement training (Baidu and Oristand) also confuse these two concepts . This kind of conceptual confusion is not conducive to the introduction of CMMI (Software Capability Maturity Model) or ISO9000; furthermore, it is not conducive to improving the level of software project management.
In fact, the nature of these two jobs is obviously different, and their quality requirements for practitioners are also very different. Simply put, QA (Quality Assurance) is a management method for the project implementation process, and QC (Quality Control) is a technical method for project products.
QA supervision work
QA is committed to doing the right thing in the right way and at the right time: in terms of the way of doing things, follow the established process to ensure product quality, control the development work instead of solving specific bugs. More precisely, QA is not "quality assurance" but "process management" (Process Management) to ensure that the project is carried out and implemented with a set of mature and efficient ways of doing things. Relying on the development process under the control of QA, it can guarantee the development of good products from a forward-looking system. Therefore, companies with good QA management can easily gain more trust from customers.
In the CMMI system, QA personnel are independent of the project team (not under the jurisdiction of the project manager), and he can report the QA defects that the project manager does not admit to CCB (a configuration management committee with a higher status than PM) or senior managers for ruling.
During the implementation of IT projects in some large enterprises, it is often necessary to set up a joint project team where Party A and Party B work together. In this case, the project members of Party A should not only test the product quality (QC) of Party B, but also supervise the way of doing things (QA) during the development process of Party B.
Generally speaking, the QA personnel of the project should check whether the project development process has formulated and implemented formal requirements such as management standards, processes (Process), strategies, etc., and should put forward suggestions for improvement, point out whether the process is effective, how to make the process more effective, and Evaluate the efficiency and effectiveness of these requirements.
QA personnel also ensure that project team members understand these requirements. He does not intervene directly in the work of developers, but works at the highest level of project management, except for training new employees to understand the organizational process, or training old employees to understand the changed organizational process. He has to deal with the project manager and CCB, configuration manager, QC personnel.
How do you know the QA job is correct? It is also result-oriented: through the continuous improvement of organizational processes, the products that users need can be manufactured faster and at lower cost.
For example, in a large project, QA personnel can help the project manager to formulate the project plan, so that the project can be advanced according to the organized procedures; Work. As the project progresses, QA personnel can timely import "checkpoints" to see where new risks will occur. For example, the project is engaged in work outside the predetermined scope, or the project needs to be strengthened. These checkpoints are an opportunity to make sure the right people are there at the right time.
Judging from the current unsatisfactory situation in China, QA work is often replaced by "intentional and vague" corporate culture. I think it is too indirect and uncertain to rely entirely on this corporate culture to create a reasonable and mature work routine. . Because in the software industry with rapid personnel changes, it takes an obvious lag time for new employees to understand and identify with the corporate culture and accurately map it to specific jobs. This disadvantage is not obvious in small enterprises, but it will be more prominent in large enterprises. Therefore, it is necessary to establish a set of common QA work standard templates, and assign special personnel to act as QA personnel in important large projects. QA personnel need to track, understand, monitor, and evaluate various events (phenomena) in the project in real time whether they conform to the standardized process? Are existing processes efficient? Are inefficiencies not covered by the process or a process defect? That is to say, QA personnel must have the abstract analysis and summary ability of "seeing the essence through phenomena". Every "disconnected" phenomenon of coordination errors in the project will trigger his thinking and put forward suggestions for improvement.
After such efforts, QA personnel can continuously extract effective and universal process optimization experience and suggestions from a series of personalized projects. After they are confirmed by the project management office (PMO), they will be continuously precipitated and incorporated into ( Archive) into the process assets of the enterprise, and become the general work guidance for the project management of the enterprise in the future. In this way, another "IBM" with a mature and operable corporate culture and continuous improvement will be born, and the enterprise will be able to make more projects into a "portfolio".
QC is the last hurdle
QC work means that testers check whether the developer's product meets the expected quality requirements, and give suggestions for improvement. QC serves the development work and is under the control of the development work. More precisely, QC is not directly "quality control", but "requirement validation" (Requirement Validation) or product testing.
Since QC is a process of "evaluating developers' ideal ideas with realistic application scenarios", project managers must pay attention to this QC work that relies on creativity and imagination, and invest enough resources to ensure QC work. This is the final hurdle for product release.
QC work is to temper the "pure technical ideal" of programmers into an application system with excellent robustness. Testers need to stand between software technology and user application scenarios, repeatedly and comprehensively check and verify the mapping relationship between the two, and also analyze the causes of "bugs are getting more and more corrected" and persuade and help developers to clarify and comply with the product version. Bottom line on quality. Testers have to "hunt" programmers' negligence comprehensively and meticulously, often under tight time pressure, with sober exploration and reverse critical thinking. This requires him to understand user needs and software architecture faster and more accurately than programmers; and when accepting new projects, his mind quickly switches to different user application scenarios. That is, he must have a stronger ability to learn across industries. This ability is often difficult for programmers to possess.
Ideal testers should also have the ability to "think concurrently" in order to catch sharing conflicts that are extremely prone to occur between multiple programmers in multitasking scenarios. He should also be familiar with database modeling and SQL in order to troubleshoot and determine the cause of potentially dangerous garbage data that is difficult for programmers and users to detect.
It can be seen from this that it is wrong to underestimate the view that "people who are not good at programming can only do testing" for testers. There is a lot of room for improving the professional quality of testers, and their value should also be promoted and improved in the long run.
QA and QC are different important jobs, which require people with different qualities to undertake them. It should not be assumed that "QA and QC can be merged", nor should either one be ignored.