Software defects are often referred to as bugs. The so-called software defect refers to some kind of problem, error or hidden functional defect in computer software or program that destroys the normal operation ability.
The existence of bugs will cause software products to be unable to meet the needs of users to some extent.
(1) Viewed from the inside of the product, it refers to problems such as errors and defects in the process of software product development or maintenance.
(2) From the outside of the product, it refers to the failure or violation of a certain function required by the system in advance.
1. Types of defects
Defects can be divided into different categories
(1) Omission: Refers to the specified or expected requirements not reflected in the product.
(2) Error: It means that the requirements are clear, and the functions of the requirements are not correctly realized in the implementation stage.
(3) Redundancy: Only requirements not covered in the documentation are required to be realized
(4) Dissatisfaction: In addition to the above 3 situations, the user's dissatisfaction with the realization of the product is also called a defect.
2. Classification of defects
The classification of software defect levels by different companies is similar, and can be roughly divided into five levels.
(1) Well-known: Refers to problems such as system or application crashes, crashes, and illegal exits, which will lead to loss or destruction of user data, and the functional design is seriously inconsistent with the requirements.
(2) Serious: Refers to the lack of implementation of functions and features, resulting in module function failure or abnormal exit, as well as problems such as program interface errors or data flow errors.
(3) General: Refers to the loss of main functions, the prompt information is not correct, the user interface design is too poor, and the deletion is not prompted.
(4) Prompt: Refers to the problem that has no effect on the functions of users, and the product and attribute can still be used.
(5) Suggestions: Suggestions, questions and other issues raised by testers.
3. Bug report
The defect report is one of the most important output results after the test execution is completed, and a good defect report is also an important guarantee for improving software quality.
Different companies may have different defect report templates because of their different defect management processes. But a complete defect report should usually contain the following.
(1) Number: Use a number to uniquely identify a defect, usually, it will be automatically generated when a new bug is created in the defect management tool.
(2) Status: usually describes the status of the current defect, such as repair, postponement, etc.
(3) Title: Usually use a relatively concise sentence to summarize the Bug. Through the description, you can preliminarily speculate on the cause of the Bug, and help developers improve the efficiency of handling Bugs.
(4) Type: Mainly to further describe the causes of defects, such as functional errors, interface errors, database errors, etc.
(5) Version: Describe the test version where the current bug is located, so that you can pay attention to the test version in the later regression test.
(6) Module: Describe the business module where the bug is located, which is convenient for later statistics on the distribution of defects, and is conducive to the improvement of regression testing methods and testing strategies.
(7) Severity level: Refers to the severity of the bug. Usually, different bug severity programs have different consequences and risks to the software, and the priorities of developers are also different.
(8) Processing priority: Developers determine the priority of processing according to the severity of the bug.
(9) Founder: The submitter of the bug
(10) Discovery date: Generally, when a bug is submitted, it is automatically generated by the bug management tool, which is convenient for subsequent defect tracking.
(11) Probability of recurrence: refers to the probability of bug recurrence, which is convenient for developers to locate and analyze bugs. Generally include mandatory, occasional and so on.
(12) Designate handlers: Designate handlers according to the type of bug, usually designated developers, if the requirements are wrong, you need to designate product managers or requirements analysts to facilitate later tracking of bugs.
(13) Detailed description: describe in detail the cause of the defect and the reproduction steps, including the test environment, preconditions, test data, reproduction steps, expected results, actual results, etc.
(14) Attachments: In order to describe the bug in detail, we can add some attachment information when describing the bug, such as screenshots, screen recordings, error log information, etc.
Finally: In order to give back to the die-hard fans, I have compiled a complete software testing video learning tutorial for you. If you need it, you can get it for free 【保证100%免费】
How to obtain the full set of materials: Click the small card below to get it yourself
