Bug classification and severity
Bug classification (Zen Tao as an example)
1) Functional defect: business process is not implemented
2) Code error: error page 404 , 500
3) Interface optimization: UI problem, graphic display
4) Installation and deployment: installation failure, inaccessible, etc.
5 ) Performance issues: long response time, slow loading
6) Security related: password plaintext display
7) Others: ease of use, compatibility
8) Design flaws: Requirement flaw
bug severity
1) Fatal (highest): system crashes, crashes , Infinite loop, database data loss, database connection failure, main function loss, important first-level menu is unavailable
2) Serious (high): Partial loss of main functions, database save, submit and call errors, functional design and requirements are seriously inconsistent, Automatic exit, poor stability, numerical calculation and statistics error
3) General (medium): the function is not fully implemented, there are defects but does not affect the system stability (long query time, format error, boundary value error, deletion without confirmation, data table field too Many - generally about 12)
4) Slight (low): compatibility, interface optimization, does not affect the use of normal functions, typos, overlapping page display, missing prompts
5) Suggestion (very low)
bug priority (development ) Modify the order of questions) - Development Options
1) Very Urgent
2) Urgent
3) Normal
4) Not Important
Interview Questions: Does the higher the severity, the higher the priority?
Not necessarily, high-severity priorities may be relatively urgent.
For example: the login page of 12306 is written as a record in the mainland. There are many users, which directly affects the user experience. This is an urgent but not serious problem.
Bug status
1. To be confirmed (submit – activate): The status submitted after the tester or user discovers a new problem
2. Confirmed: It is confirmed as a bug after the test and development discussion, and the submitted status, the developer clicks the confirm button
3. Processed (Resolved): The development confirmed that it is the state of repair after the bug, the modification has not been verified, and the state is set by the developer
4. Modified (closed): The final state of the bug, the test passed, is set by the tester
5. Still Exist (reopen): The test failed, the bug was not successfully repaired, and the problem still exists, set by the tester
6. Not a bug: The R&D determines that it is not a bug/suggestion or the opinion decides not to be adopted. The developer will set it.
7. Pending): The current version will not be modified, and subsequent versions will be considered, or it will take time to determine whether it will be resolved, and it will be set by testing or development
Bug tracking process:
**There are two situations after the testers find the problem**:
one is to ask the leader to confirm when they are not sure, if the leader confirms that this is a problem, then create a problem, if everyone agrees that it is not a problem, give up;
the other is to The tester determines that this is a problem and directly creates the problem
;
After creating the problem, submit it to the development, and the development judges whether it is a problem after getting the problem. If it is not directly abandoned, if it is repaired, after the repair and the problem is solved, the tester will verify the problem
;
After the verification is passed, the problem will be closed directly. If the verification fails and there is still a problem, it will be reopened, submitted to the development again, and the development will deal with it again. After solving the problem, we will verify again until the verification passes and the problem is closed.
Detailed description of the bug
[Project belonging to] Associated project name
[Affected version] The version in which the problem occurred
[Current assignment] The processing person
[Deadline] The deadline for processing
[bug type] Bug classification
[Operating system] What system is used for testing
[Browse Browser] The browser used for the test
[bug title] Describe the problem, concise and to the point
[Reproduction steps] Use the form of 1, 2, and 3 to explain
[Result] Description of the problem after the
operation [Expectation] The correct phenomenon after the operation is
mentioned. The purpose of the bug
1. To record the corresponding problems, to avoid the lack of repair and testers due to the lack of a corresponding recording process.
2. Explain the corresponding operation steps
. The process of bugs may have different flows towards
creating high-quality bugs
1) Title: Briefly describe the bug, so that people can quickly understand the problem
2) Test environment: The software/hardware system that found the problem, what version, if needed Also indicate which hardware platform
3) Preconditions: system environment information before the user test step
4) Submission steps: problems found when performing any operations
5) Actual results: in the process of testing the software, the performance of the software itself The result may be different from the
expected
result
Communicate with the development
1) Make sure that the bug you submit is a bug that can be reproduced
2) If there is any doubt in the development, or there is no bug, we can explain the inconvenience of the user when using the system from the user's point of view
3) The bug needs to be clearly written or described. After the developer understands the problem, he can accurately locate it.
4) After confirming with the developer and modifying this piece, it will mainly affect where it will affect other modules, and if so, We need to re-focus
5) Pay attention to the language and communication words
B/L is based on the granularity of needs to B/L
References:
none
Remarks:
If there is any infringement, please contact by email, I am really sorry.
This is only for learning personal notes, and if there is any reprint, please indicate the source.
Contact Email: [email protected]
Learn to test the penguin group together (chat, water group, do not disturb advertising): 826471103