Software defect tracking management
(Dai Jinlong, Xie Min)
Zheng Qiang apparent: This article is copyright to the computer world, any reprint and a large publication, be sure to collect the author.
1 Why do you have a software defect tracking?
Explain a typical software development process: Demand analysis - Summary design - Detailed design - Program Coding - System Integration - Delivery and Maintenance, you will find that dependence and inheritance relationship between the phases in this process is quite close. The correct part of the previous stage or the correct part will be inherited and refined by the next stage, however, if an error occurs in the previous stage, the tester does not intervene in this stage of quality control, then The error will be inherited and enlarged in the next stage, and the order is sequentially passed. If you wait until the delivery and maintenance phase, the error is discovered, then the relevant error correction work will become a cost-high and minor effect, in some cases, even the failure of the entire development work. This is not intentional to talk about it. According to a report of the National Institute of Standard Technology, large-scale private software, which occupies 85% of the world software sales, its failure rate is as high as 70%.
Therefore, every stage of the software development process must introduce software test technology, early test, and eliminate the spread of errors. However, the nature of the test work determines that the tester may be the role of the developer always wants to avoid. In the early days of test practice, when the tester found a defect, when the report was given to the developer, the developer would sign a symbolism in most cases, and then put the test report on the side and continued to work in hand. If there is any modification afterwards, no one knows. If the tester is frequently reported by the same developer or constantly chasing the modification of the defect, the developer may gradually lose his temper, for maintenance technology authority or other purpose, he will sieve: This is not a mistake, this is a software special function. Or say: This is not a big problem, now the progress is tight, and it is quite troublesome, and then there will be time to say. So, can't, the problem still exists.
In order to avoid this situation, software companies must introduce software defect tracking management mechanisms. Test staff no longer need to contact developers, and don't even know who developers are, they can directly report to the defect tracking management system (some test teams are written), developers do Do not make changes and what time must be completed before the project management department (of course, the test team can also refer relevant recommendations). Introducing a defect tracking management mechanism, one side of the various roles, avoiding unnecessary disputes, and on the other hand, it also helps the project management department promptly understand the quality status of software products in the production process, thereby better controlling products. the quality of.
2 Description of software defects
In the discussion of the previous section, there is no strict distinction between defects and errors. Before starting this section, you will briefly explain these two concepts. Defects, referring to software documents (such as software requirements specifications, design specifications, etc.) or data errors in program code, logical errors, content omissions, and inconsistencies on content, and more. It includes errors, synonyms with bugs (Note: For defects, errors, bugs have more detailed discussions, in view of this practical article, the author does not intend to do more stringent distinction). In the top section, we talk about each stage developers in the software development process may introduce defects, so how to describe a defect? The author talked about his opinion.
1. Description of defects should include trackable information
All defects are assigned to each defect. Each number must be unique and can be searched according to the number, depending on, check the processing of the defect.
2. Description of defects should contain basic information about defects
The basic information of usually defects includes defect state, defect title, severity of defects, defects, defects, defects, defects, defect resolution time, defect resolution results, defect handlers, defect processing Time, defect processing results, defect confirmation, defect confirmation time, defect confirmation results, etc. The following writer explains: Defect status: labeling the defect to be corrected, to be reviewed, to verify, shut down state information; defect title: Concisely illustrate the type and content of defects; Defect severity: Defect severity given by testers It can be fatal, severe, general, suggestion; defect emergency: test processing priority given by testers; Defects Author: Discover the test personnel of this defect, it is best to accompany contact details to facilitate defect The handler is confirmed; the defect submission date: the date of submission of the defects; the deficiencies belongs: the module where the deficit is located or the name of the development document belongs; the defect resolution person: Who is solved by the defect, clearly demand analysis Personnel, design person is still a program code person; the defect solution time: the defects returned by the project group, the defects are expected to process; the defect resolution results: the result of the expected defects can be achieved; defect handlers: Who should handle this defect; Defect treatment final time: refers to the actual time of defects; defect processing results: final actual processing results; defect confirmation: Who confirmed that the defect has been corrected; Defect Confirmation Time: Time to repair the defect repair Defect confirmation results: Confirm whether the correction work for software defects is valid.
The entries listed above are not necessary. The reader can cut according to the actual situation of the project, and should also add some items that some author did not take into account depending on the actual needs of the test. In addition, it is necessary to pay attention to the above-mentioned entry is not filled in the test person, such as: defective solution time, defect resolution results, defect handlers, etc., should be determined by project management personnel, progress, etc.
3. Description of defects should contain detailed descriptions of defects;
That is, the feature of defects should be described in detail, such as errors in program code, and detailing the fiddle-generated hardware and software environment, related input output data, error programs, etc., to facilitate the coder to make errors And wrong positioning. Another example is an error in the design specification, which should indicate which terms in the high-level software development document (such as the requirements specification) are contrary to why it is necessary to describe it, so that the designer is further verified.
4. Description of some defects should include the necessary accessories;
Sometimes, some defects may not be clearly used by language text, such as some of the defects in the user interface, and the optical language text is difficult to expressly expressly. At this time, it is necessary to further describe defects by means of screen copying, etc..
3 general processes for software defect management
Let's take a simple process of a software defect tracking management system:
This process involves the following roles:
Test staff: People who perform tests are defective speakers.
Project leader: Includes the project management personnel mentioned above. He is responsible for the entire project and is responsible for product quality.
Developers: design and coding personnel
Reviewer: In the final confirmation of defects, the project member exercises arbitration power when the project member reaches the defect processing.
The assignments of each role are as follows:
"Submit", "failed", "through" is defined by the tester;
"Assign" is defined by the project leader;
"Amendment" is defined by the developer with "not corrected";
"The review" and "evaluation pass" are defined by the reviewer.
In the figure, several states mentioned in the software defects are: initial state, to be allocated, to be corrected, to be verified, to be evaluated, and the final shutdown state.
The reader can adjust the process to achieve higher efficiency according to the actual situation of the enterprise.
4 deficient tracking management system overview
Defect Tracking System (Defect Tracking System) is a database program for centralizing the defects found during software testing. Software defects can be managed by adding, modifying, sorting, searching, and store operations.
At present, there have been some universal defect tracking management software. These software have functions in feature, and can be purchased directly according to the actual situation. It is also possible to develop a dedicated defect tracking system based on the actual needs of the test item, such as Lotus Notes development.
4.1 Role of defect tracking management system
(1) Easy to find and track defects. For the testing process of large and medium-sized software, the total number of defects that the report may reach thousands, and if there is no support for the defect tracking management system, it is desirable to find an error, and its difficulty and efficiency can know.
(2) It is easy to work together. The defect tracking management system can work as a test staff, developer, project leader, and defective reviewer work together.
(3) Guarantee the effectiveness of the test work. Avoid testers repeat the error, but also facilitate the current state of the defects in time, thereby completing the test work of the corresponding state.
(4) Easy to track and monitor incorrect processing processes and methods. It is convenient to check if the processing method is correct, track the name and processing time of the processor, as a reference for the statistics and performance assessment of the workload.
4.2 Implementation principle of defect tracking management system
The defect tracking management system is a database application on the implementation of the technical level. It includes a front desk user interface, a background defect database, and an intermediate data processing layer. At present, many defect tracking management systems are implemented using the B / S structure, accordingly, the programming language employed is ASP or JSP. Readers can choose to purchase commercialized defect tracking management tools as needed, or choose to develop software defect tracking management tools. The information displayed by the user interface of this type of system should generally differ depending on the user's role (tester, developer, project leader, defect reviewer, etc.), because each role is not used by the system. Similarly, if the tester is used to report defects or confirm that the defects can be turned off, the developer is used to understand which defects require him to deal with and whether the defect has been closed after processing, and the project person in charge needs timely understanding of what new defects currently Which must be corrected in time and so on. In addition, the data operation permissions owned by different roles are not the same. For example, developers have no right to fill in new defect information through their user interface to the database, and no need to turn off a known defect; and tester does not have the right to assign who to fix a known deficiencies, no right to decide whether to fix some defect. In addition to the design of the user interface to consider the difference in roles, the business logic used by such system data processing layers also requires a quite feet. The defect tracking management process discussed in Section III in this article is a model for reference, and readers can further refine it to form the business logic of the defect tracking management system to be developed. There are also some other structural business logic, readers can access or ask for professional consulting companies through consultation. The design recommendation of the defect tracking management system background database should take into account the application needs of different roles, such as the test personnel may need to do frequent records of frequent records, inquiry, etc., software developers may pay great attention to the records related to him. And do not interested in other records, and project responsible personnel may have a significant guiding significance for the new discovered defective data needs to be met, these needs have greatly guided significance for the construction of the database. The specific implementation of the database can select Microsoft Access or SQL Server according to the application size, and some other database techniques (such as Oracle) are available.
5 Significance of implementing defect tracking management
Above we discussed how to describe software defect information inside a software company, and how to implement defect tracking management, we discussed the implementation principle and design essentials of defect tracking management tools. This part of the content is important for readers who want to understand software defect tracking management technology. Implementing software tracking management technologies For companies, its significance is to ensure that each discovered defect can be resolved. Here, resolution may refer to defects being corrected, or it may refer to a consistent handling of project group members (if not processed). The defect data collected in the software defect tracking management process provides quantification of reference indicators for evaluating the quality of the software system, the performance of testers, and the performance of developers, but also provides the software enterprise to provide the necessary case accumulation. . In addition, some software companies also determine the optimal release timing of software products based on the distribution trend of defects obtained in the defect tracking management process.
