Soft audit Checklist・ No4: Quality Assurance Process (1/2)
The fourth part of the development process checklist is quality assurance
In this article, we will introduce each item of the audit checklist used for software development audit . The audit checklist is divided into ( 1) development process, ( 2) requirements management, (3) testing, and (4) design and implementation. In this article, (1 ) individual items of quality assurance in the development process are introduced. (The checklist itself can be found in the article on Software Audit Practice / Checklist Part 1: Development Process (Requirements Management) , so please refer to that.)
Quality Assurance here means Process Quality Assurance
Quality Assurance consists of 12 items with QA- at the beginning of the item number in the process checklist. QA is Quality Assuarnce and SQA that appears in the checklist is Software Quality Assuarnce, so when translated directly into Japanese, it is Quality Assurance and Software Quality Assurance .
However, articles of audit practice process (First) Since the QA or SQA here I wrote any definition you are using the CMMI, quality assurance here is soft itself quality assurance of product quality things are It means quality assurance of process quality when developing software without it .
To avoid confusion, Father Gutara calls it a process quality assurance activity. Therefore, in this checklist as well, we will continue to confirm activities that guarantee the quality of the software development process . In addition, SQA, which often appears in checklists, refers to personnel and teams who have the role of verifying (= guaranteeing) that the software development process is being carried out correctly.
Let’s look at each item one by one.
[Item number: QA-01]
First of all , check whether there is an activity in the organization to guarantee process quality (this is called SQA by CMMI) in the first place, and if so, what kind of activity is being carried out. If the audited organization has a CMMI, it’s easy to use the term SQA, but if you don’t have a CMMI, you need to explain the definition of SQA first .
In order to make good quality software, it is necessary for a good quality development process to proceed with the development work, so we need a mechanism to monitor the implementation of such a good development process . The explanation is that people and organizations that carry out such activities are called SQA. Since it is difficult to understand with a very abstract explanation, SQA asks if there is an SQA person or organization that monitors the implementation status of basic software development process planning , review implementation , test planning, etc. Check for activity.
[Item number: QA-02]
Once the SQA representative or SQA team has reviewed the implementation of the development process, they report the results to the actual development team . This is called a soft engine group, for example, revisions that require a plan have been delayed, design reviews have been carried out only half as planned, and there are problems in the development process. If this happens, report it to the development team and the person responsible for that team and encourage them to take action. Check this check item to see if such feedback to the development team is being carried out properly.
[Item number: QA-03]
Process quality assurance activities by SQA staff are the same as bug finding work by testing. Pointing out the problems is not the final goal, but the goal is to eliminate the problems found by the development team and others . Therefore, it is important that the work of recording the problems found and tracking the problems until the countermeasures are completed is steadily carried out, so check that point.
[Item number: QA-04]
From here, items to be confirmed from the aspect of the development process are lined up for testing, which is the product quality assurance work itself . The question is whether there is a mechanism to properly manage the process of testing, so the first thing to check is the test plan . Is there a document that specifies what items are needed and how to make a test plan, such as whether it is necessary to make a test plan, who makes the test plan at what time, what items to write in the test plan, etc. Make sure that the test plan is made according to the document.
[Item number: QA-05]
This doesn’t need any explanation. All the bugs found in the test must be recorded and dealt with. There is no point in testing a bug that you find if you forget to trace it and leak it to the market without fixing it. Of course, not all problems found in the test are bugs.
Some items may not be bugs, such as the test itself being wrong or the gray behavior being unclear as to whether it is a specification. Also, although it is a bug, there will be bugs that will be decided to be fixed in the next version without incorporating the fix in this release. In order to make such a judgment, it is important to record and track all bugs, so check that point.