16. Test Project Management 16.1 software test configuration Management 16.1.1 Software test Configuration management concept
Configuration management (MANAGEMENT,CM) is a series of measures to control and standardize the software product and its development process and life cycle. The goal of configuration management is to document the evolution of software products and to ensure that software developers have accurate product configurations at all stages of the software lifecycle. Software Test Configuration Management general application process method and system method to establish software test management system, that is, the software test management as a system, the formation of the system of the various processes to identify and manage, in order to achieve the set of system goals. At the same time, to make these processes synergistic and mutually promote, so that their overall role is greater than the sum of each process. The main goal of software test configuration management is to find and identify software defects as far as possible under the set conditions. Test configuration management is a subset of software configuration management that is used in various stages of testing. Its management objects include software test plans, test scenarios (use cases), test versions, test tools and environments, test results, and more.
16.1.2 related concepts in software configuration management
Software configuration management has the following related concepts:
16.1.2.1 software configuration items (software config Item,sci)
Software configuration items are viewed as a basic independent unit for the purpose of configuration management, or their aggregate, such as externally submitted software products, project deliverables (code, documents, and data), and support tools used within the project (such as document test case software tools). In most software configuration management systems, the most basic software configuration items are stored and managed in the form of disk files.
16.1.2.2 Baseline (Baseline)
has been formally reviewed and approved as the basis for next development and only configuration items that can be changed through formal change control procedures.
16.1.2.3 Software Configuration Control Board (software configuration controls BOARD,SCCB)
It is the Software configuration Control Committee
16.1.2.4 Configuration Management Library
It is divided into development libraries, test libraries, baseline libraries (controlled libraries) and product libraries.
(1) Development Library
A library of configuration items and related information related to the development activity during a certain phase of the software life cycle.
(2) Test Library
The configuration item associated with the test, after the unit test, before the end of the system test.
(3) Baseline library (controlled library)
A library of configuration items and related information that is released as a result of a phase at the end of a phase of the software life cycle, related to development activities. Changes to the configuration items included in the baseline library must follow the change process guidance.
(4) Product Library
Before the project results are formally submitted to the user, SCM extracts the final product configuration items from the baseline library under the direction of the project manager.
16.1.2.5 software configuration management (software configuration MANAGEMENT,SCM)
It is software configuration management
16.1.2.6 software work products (software workproduct)
Any artifacts that are generated as part of defining, maintaining, or using a software process. It includes process descriptions, plans, procedures, computer programs, and associated documents.
16.1.2.7 Peer review (peer Review)
A software work Product Builder's peers follow defined procedures to review the product to identify defects and improvements
16.1.3 the main processes and activities of software configuration management
The main processes and activities of software configuration management are as follows
(1) Configuration item recognition
(2) Working space management
(3) Version control
(4) Change control
(5) Status statistics and reporting
(6) Configuration audit and review
(7) Product generation
(8) Process Management
The main processes and activities of software configuration management are as follows:
16.1.4 main tasks of software configuration management
The main tasks of software configuration management are as follows:
(1) Develop the project configuration plan
(2) Configuration item identification and configuration library management
(3) Version control
(4) Change control
(5) Regular configuration audits
(6) Report configuration status to relevant personnel
16.1.5 Software Configuration Management plan
The content of the software configuration management plan is as follows:
(1) Configuration management software resources and hardware resources
(2) Configuring the library structure
(3) Personnel, roles, and configuration management practices
(4) Baseline plan
(5) Configuring the library backup plan
Main functions of 16.1.6 configuration management system
The main functions of the configuration management system are as follows:
(1) Parallel development support
(2) Revised edition management
(3) Version control
(4) Product release Management
(5) Building Management
(6) Process Control
(7) Change Request management
(8) Code sharing
16.2 defect (bug) management process classification of 16.2.1 defects
From different angles, bugs can be divided into software errors, software defects, software failures and software failure
(1) Software error
Software errors refer to a series of issues that exist in software products that result in differences between expected run results and actual running results.
(2) Software defects
Software defects are those that exist in the software that are not desirable or unacceptable deviations.
(3) Software failure
Software failure refers to an unwanted or unacceptable internal state that occurs during the course of a software operation.
(4) Software failure
Software invalidation refers to the result of an unacceptable external behavior when the software is running.
16.2.2 Concepts related to software defects 16.2.2.1 the scope of software defects
The ability to conform to the following 5 rules is called a software flaw:
(1) The software does not meet the function specified in the product specification.
(2) The software shows the error that the product specification indicates will not occur.
(3) The SOFTWARE function is beyond the scope specified in the product specification.
(4) The software does not meet the objectives that the product specification does not indicate but should be achieved.
(5) Software Testers believe that the software is difficult to understand, difficult to use, slow to run, or the end user is considered bad.
16.2.2.2 Classification of software defects
The classification of software defects is as follows:
(1) function is not normal
(2) The software is not easy to use
(3) The structure of the software is not well planned
(4) Insufficient function
(5) Poor interaction with software operators
(6) Poor use performance
(7) Not doing error handling
(8) Boundary error
(9) Calculation error
(10) Errors resulting from the use of a period of time
(11) Error in control process
(12) Errors caused by large data volume pressure
(13) Errors generated in different hardware environments
(14) Errors caused by poor version control
(15) Errors in the software documentation
16.2.2.3 Severity of software defects
The severity of software defects can be divided into:
(1) Fatal (Fatal)
Complete loss of functionality, system crashes, crashes, data loss or corruption
(2) Serious (Critical)
Some of the main function loss, result error, function omission and data cannot be saved
(3) General (Major)
Minor features are not implemented, but do not affect normal use, such as interface layout, incorrect hints, and glitches
(4) smaller (Minor)
Does not affect the use of defects or small suggestions
16.2.2.4 Priority of software defects
The priority of software defects can be divided into:
(1) highest priority (P1): System can hardly be used or test cannot continue, need immediate fix
(2) Sub-high priority (P2): Must be repaired before product release
(3) Medium priority (P3): If time permits should be fixed
(4) General priority (P4): can be repaired, but does not affect publishing
16.2.2.5 software defect Tracking status
The state of the software defect in Bugzilla is described as follows:
(1) NEW
The tester submits the bug to the task dispatcher (the development module owner), where the bug status is new, starting the life cycle of the bug, and if the tester knows the specific responsible developer, it can also be specified directly, and enter the specific responsible developer email in the Assign to project.
(2) ASSI
When the task dispatcher distributes the bug to the designated developer, the bug is set to the Assi state, and the work to fix the bug begins.
(3) Reso DUPL
After the developer receives the bug assigned to it, check the bug list in the current project to see if the bug is duplicated with the previous bug, and if it repeats, place the new bug in the Reso dupl state and indicate in Commnet which bug is duplicated (some developers have placed the old bug Reso DUPL is wrong)
(4) Reso Inva
The developer has fixed a bug that has not been duplicated, and after analysis, if the bug is due to the wrong environment or due to faulty operation or due to the error of the tester, it is an invalid bug, the bug is set to the Reso Inva status, and the reason why it is invalid in Commnet is stated.
(5) Reso late
The developer fixes a valid bug that is not duplicated, analyzes it, if the current version cannot be repaired, but fixes it later in the project or when the condition is ripe, resets the bug to the Reso late state and notes the reason for late in Commnet ( Some developers mistakenly set this type of bug to Reso Inva is wrong)
(6) Reso WONT
The developer fixes a valid bug that is not duplicated, is analyzed, is not within the scope of the product requirement, and does not provide this functionality for the foreseeable future, placing the bug in the Reso wont state and stating the reason for wont in commnet
(7) Reso work
The developer will fix a valid bug without duplication, follow the steps of the bug, verify it multiple times, but not reproduce the bug, and require the tester to tell himself when the bug is discovered, so that when the bug is found, it is reso work status
(8) Reso FIXE
The developer has fixed a bug that has not been duplicated, found the cause of the problem, changed the code, can eliminate the bug, set the bug to Reso fixe status, and indicate the cause of the issue, the method of repair and the version to be repaired in commnet. For accurate and timely verification by testers (some developers only note that bugs have been fixed, but no version is stated, or the version is incorrect)
(9) VERI FIXE
When the tester is working on reso fixe, it is validated in the specified version and later versions, and if the bug is found to be no longer present, set the bug to Veri fixe status and indicate the verified version in Commnet
(10) Reop
When the tester is working on reso fixe, it is validated in the specified version and later versions, if the bug is found to be present, the bug is Reop state, the version of the bug is noted in commnet, the necessary information is added, and the developer continues to find the cause, Further fix the bug, the tester in the test process, found that the status of Veri fixe a bug is reproduced, the bug is set to Reop status, and in Commnet to indicate the version of the bug to reproduce, to supplement the necessary information, the developers need to continue to find the cause, further fix the bug, During the test, the tester discovers that a bug with a status of Clos is reproduced.
(11) CLOS
The tester verifies the bug in the veri fixe state again when the test is returned, if the bug is still not reproduced, resets the bug to the Clos state, and notes the last verified version in Commnet, the end of the bug's life cycle, and if the bug occurs in subsequent versions of the project. Requires Reop, the above operations are only handled in the same project, and there are no duplicate issues with bugs for different projects. When a tester submits a bug, if he wants others to know about the bug's progress, you can enter their email,bug in the CC entry and if you want others to know about the bug's progress, click Edit in the CC list to add their email
The Bug state transition diagram in Bugzilla is as follows
16.3 related applications of quality cost
Quality cost refers to all the expenses incurred by the enterprise in order to guarantee and improve the quality of the product or service, as well as all the losses caused by the failure to meet the product quality standards and the customer's needs.
Quality costs typically include:
(1) Consistent cost
All work to ensure consistency with requirements is called consistent cost
(2) Non-uniform cost
All work that is caused by non-conformance is called a non-uniform cost
The cost of these jobs mainly includes: prevention cost, appraisal cost, internal loss cost and external loss cost. The prevention cost and the appraisal cost are the consistent cost, and the internal loss cost and the external loss cost, collectively referred to as the failure cost, belong to the non-uniform cost.
The following table illustrates the calculation of consistent and non-uniform costs
Table 16-2 Test cost composition Table
Cost type |
Quality Cost Item |
Test cost Item |
Automatic test (yuan) |
Consistent Cost |
Test investment |
Test labor costs |
50000 |
Environmental usage Fee |
10000 |
Test Tool Fee |
15000 |
Test total investment |
75000 |
Non-uniform Cost |
Unit Test |
Number of defects found |
80 |
Cost per defect |
100 |
Internal (development) defect costs |
8000 |
Independent testing |
Number of defects found |
215 |
Cost per defect |
400 |
Internal (test) defect cost |
86000 |
Regression test |
Number of defects found |
5 |
Cost per defect |
4000 |
External (user) Defect cost |
20000 |
Total |
Quality cost |
Conformance costs |
75000 |
Non-uniform cost |
(8000+86000+20000) =114000 |
Total Quality Cost |
(75000+114000) =189000 |
Ddp |
Defect detection Rate |
(80+215)/(80+215+5) =98.3% |
16.4 Software test Project management 16.4.1 The scope of software test management
(1) test process Management
(2) Testing personnel and organizations
(3) test plan and test progress
(4) Test risk management
(5) Test cost management
(6) Management of test outputs
16.4.2 the process of testing quality control
Test quality control can be carried out in the following ways:
(1) Develop quality assurance plan
(2) Review the test document
(3) Audit test activities
National Computer technology and software Professional technical qualification (level) exam "software Evaluator"-Test content Summary (16) test project management