1 Overview
This document defines the whole life cycle of bugs, and standardizes the solution and management process of bugs. There are rules for bugs to follow in the process of circulation. Specification of bug severity level and bug resolution priority, so that developers and testers can accurately judge the severity of bugs and solve them according to this document.
2 Key roles and responsibilities
Role | Responsibilities |
Test engineer | 1. Submit bugs according to specifications; |
Test Leader | 1. Review the bugs submitted by test engineers; |
Development engineer | 1. Analyze and solve bugs based on priority |
Development Leader | 1. Review bugs regularly, and strengthen code review and unit test for bug-rich modules; |
Product manager | 1. When there is disagreement between development and testing, confirm requirements |
3 Bug Lifecycle
4 Writing specification
4.1 Theme
1) Describe le in a short sentence; Or a problem caused by an operation;
2) Concise and get straight to the point when describing the problem, but grasp the main points;
3) The number of occurrences of occasional bugs marked before the theme;the problem of a modu
4) Some modules have more functions, and specific operations can be marked before the topic description
Example:
[Account switching] Login with non-local mobile phone number. After switching back to local phone number and logging in, no message can be received;
The program stops running when adding carrier library
4.2 Description
Description areas include: steps, expected results, actual results, test environment, bug time, screenshots, logs
1) Numbers and describe step by step the recurrence steps of the problem;
2) Different operation steps produce different problems, and need to report bugs respectively; Try to report one problem per bug;
3) If there is an occasional problem, it must be clear when the bug appears, and provide screenshots and logs
5 Bug solutions
New status bugs submitted on the same day, the corresponding developers need to review them all within 2 days, and divide the bugs into the following 3 categories: refusal, in progress, delay, feedback (to the product)
Develop fixed bugs: set the bug status to resolved; At the same time, add verification version number, error cause and solution
ex:
Verification version: V1.0.1.1101 (1101 means it can be verified on November 1st)
Cause of problem: no conditional judgment
Solution: Make reasonable boundary judgment
Bug status is rejected by the developer: Assigned to the bug creator; At the same time state the reasons for the refusal
ex:
Reference to the design of XXX, testers understand wrong
The bug lacks the necessary information:Set bug status to rejected; Assigned to the bug creator; At the same time state the reasons for the refusal
ex:
Missing required log
The development has been fixed, and the testing has verified that the bug passed:Set the bug status as solved, and indicate the approved version number;
ex:
Verification of V1.0.1.1103 passed
Development fixed, test validation failed bugs:Set the BUG status as "hit back", and indicate the reason for feedback according to the actual situation;
ex:
The V1.0.1.1103 version verifies that this problem still exists;
Steps: XXX
Time of occurrence: XXX
Test environment: XXX
Screenshots, logs
Tester and developer controversial bugs:The tracking category is set as demand and the state is set as feedback; Assign to corresponding products, discuss and confirm the modification plan; And indicate the reason for the feedback
ex:
Test that the IP address is set wrong, should prompt the user, but should not appear to stop running
Bug that can't be fixed:Change the bug status to recognized, and indicate the recognized reason
Bug that can't be reproduced:Mainly rely on the log to analyze the cause of the problem, and then make corresponding modifications; After developing the modification, test back to 3 versions, or use the testing tool to test repeatedly, if there is no reappearance, close first; And indicate the closed version number
ex:
V1.0.1.1103 is not reproduced yet, close first
A bug that needs to be postponed:Change the bug status to low and the scheduled completion date to the scheduled date to fix the bug; And state the reason for the extension
ex:
Requirements change, change momentum is large, affect the release time
Product confirmation of bugs that need to be corrected:Modify the bug status to call back, assign it to the corresponding developer, and indicate the modification content
Product confirmation does not need to modify the bug:Change the bug status to resolved and indicate why it is not required
It's not a bug on the back end:By the bug end (the end) personnel to give analysis, transfer to the corresponding end and developers, and oral notice
6 Bug Tracking Category
Bug: A problem that the tester determines to be a bug;
Optimization: the function has been implemented, need to do the performance optimization problem;
Suggestions: Test some improvement suggestions for the product;
Requirement: a demand problem that requires the product to be reorganized
7 Bug status
New: New bug, optimization, or suggested problem status submitted by the tester;
In progress: The developer has confirmed that it is a bug and the problem status needs to be fixed;
Resolved: The status of the problem that the developer has fixed;
Closed: Test validation to determine the status of the resolved problem;
Rejected: Issue status rejected by the developer for testing that is not considered a bug;
Feedback: Feedback to product confirmed problem status;
Recognized: A problem state that is confirmed to be a bug but cannot be solved;
Call back: Test verifies that the bug has been solved, but the problem status is still not fixed
8 Bug Severity
Fatal: Unable to perform normal functional operation, or system crash due to product reasons, which needs to be fixed immediately
ex:
The program could not start, or log in;
The program crashes, stops running, and the system crashes, unable to proceed to the next operation
Serious: there are serious defects in some functions, which can still be tested without affecting the stability of the product
ex:
An occasional program crashes and stops running
Function not implemented
Data out of sync
Function error, cannot proceed further operation
General: minor functions or some errors in the interface do not affect the normal testing
ex:
UI display is inconsistent with renderings;
Incorrect prompt;
Wrong character;
The query results show an error
Suggestions: Test some improvement suggestions for the product
9 Bug priority
Low: the impact on the product is relatively small, in the case of time does not allow the temporary modification;
Medium: Must be revised, not necessarily right away, need to discuss to make sure that the revision is completed before a specific milestone;
High: Must be modified before release;
Urgent: affects the test, needs to be fixed immediately or in the next release