Table of contents
①The version where the problem was found
②The environment in which the problem occurs
③ Steps to reproduce the error
④Description of expected behavior
⑤Description of wrong behavior
⑦ Don't put multiple bugs together
3. How to define the level of bug?
PS: Bug tracking and status changes should follow some basic principles:
1. What is a bug?
First bug:
One day in September 1945, in an old building, a moth flew in through the window. At this time, Hopper was buried in his work in front of a computer named Mark Il, and did not notice that this moth was about to make history. event moths.
This computer used a lot of relays (electromechanical devices, before transistors). Suddenly, the Mark II froze. Hopper tried many times and still couldn't start. He began to use various methods to find the problem, and finally located the relay on a certain circuit board.
Hopper observed the relay and was surprised to find that a moth had been killed by the relay. Hopper carefully picked out the moth with tweezers, pasted it in the "event record book" with transparent tape, and wrote "the first instance of finding a bug". Hopper's event log, along with the moth, is now on display at the Museum of American History.
- A mismatch between a program and a specification is a software error if and only if the specification (software requirement) exists and is correct.
- When the function is not mentioned in the requirements specification, the judgment standard is subject to the end user: when the program does not realize the functional requirements reasonably expected by the end user (execution result != expected result), it is a software error.
Right now:
When the software function does not exist, the user requirement (software requirement) exists and is reasonable, and the software function does not match the user requirement, it means that the software is wrong.
2. How to describe a bug?
A qualified bug description should include the following parts:
①The version where the problem was found
Developers need to know the version where the problem occurs, so that they can obtain the corresponding version of the code to reproduce the fault. And the identification of the version is also conducive to statistics and analysis of the quality of each version.
②The environment in which the problem occurs
The environment is divided into hardware environment and software environment. If it is a web project, you need to describe the browser version, client operating system, etc.; if it is an app project, you need to describe the model, resolution, operating system version, etc. The environment can also be divided into a local environment and a server environment. A detailed description of the environment facilitates fault location.
③ Steps to reproduce the error
Describe the shortest steps to reproduce the problem.
④Description of expected behavior
Let the developer guide what is correct, especially to describe the behavior of the program from the user's point of view. If the fault is based on the requirement, it is best to state the source of the requirement. Believe it: Testers know the requirements best.
⑤Description of wrong behavior
Describe the error phenomenon. Crash, etc. can upload logs, and UI problems can have screenshots.
⑥Others
Some companies have some other requirements, such as the classification of faults: functional faults, interface faults, compatibility faults, etc.; preconditions for bug recurrence; BUG priority: serious impact on testing requires developers to modify first, you can set The priority is high; the bug is for whom.
⑦ Don't put multiple bugs together
Do not submit bugs together when you cannot confirm that the fault is caused by the same piece of code.
PS: Case 1
The following bugs were submitted:
- In the text message list, select a text message and delete it, but the deletion fails.
- In the text message list, select a text message to view it, and delete it on the view page, but the deletion fails. (This is better, to record in detail)
PS: Case 2
- Fault discovery version: VPS20180226_01
- Fault Category: Compatibility
- Fault Priority: Medium
- Fault Title: The interface under ie displays abnormally, and the text on the interface overlaps
- Fault description:
- Test environment: win7+IE8
- Test steps: 1), open the vps home page, click the "notification" link, enter the notification page
- Expected result: The notification page is displayed correctly, 10 notifications are displayed on one page, arranged in reverse chronological order
- Actual result: 10 notifications are displayed on the page, and the order of notifications is correct, but the text on the page overlaps
- Attachment: upload screenshot
3. How to define the level of bug?
The definition of bugs is different for each company, you need to check the company specification before defining the level.
The following is an example:
①Blocker (crash)
Issues that hinder development or testing efforts.
Cause system crashes, crashes, and endless loops, resulting in loss of database data, errors in connection with the database, loss of main functions, and loss of basic modules.
Such as: code errors, infinite loops, database deadlocks, important first-level menu functions cannot be used, etc.
(This problem rarely occurs in the test. Once it occurs, the current version test should be terminated immediately, and the test call back: the test writes a report to the superior leader and calls back to the development. Next, the development needs to be repaired. After the repair, you have to carefully have a test)
②Critical (severe)
Some of the main functions of the system are lost, the database is saved and called incorrectly, user data is lost, and the first-level function menu cannot be used, but it does not affect the test of other functions.
The functional design does not meet the requirements seriously, the module cannot be started or called, the program restarts, automatically exits, call conflicts between related programs, security issues, stability, etc.
Such as: errors displayed in the database after the data in the software are saved, missing functions required by users, program interface errors, numerical calculation statistics errors, etc.
(This level of problems can continue to test this version without affecting other functional tests)
③Major (General)
The function is not fully realized but it does not affect the use, and the function menu has defects but it will not affect the system stability.
Such as: long operation time, long query time, wrong format, wrong boundary conditions, no confirmation box for deletion, too many fields in the database table, etc.
(This problem exists most in the actual test)
④Minor (secondary)
Interface and performance defects, suggestions, problems that do not affect the execution of operation functions, solutions that can optimize performance, etc.
Such as: typos, irregular interface format, overlapped page display, hiding what should not be displayed, unclear description, missing prompts, uneven text arrangement, incorrect cursor position, poor user experience, solutions that can optimize performance, etc. .
(There are many such problems in the early stage of the test, and the priority is low; there are few problems in the later stage of the test, and they should be dealt with in time)
4. The life cycle of bugs
Every company and every tool defines the bug lifecycle differently. The following is just a common example.
Testers should track the entire lifecycle of a Bug, from Open to Closed.
BUG state transition diagram:
- New: Newly discovered bugs, which have not been reviewed to decide whether to assign them to developers for modification.
- Open: It is confirmed that it is a bug, and it is considered that it needs to be modified and assigned to the corresponding developer.
- Fixed: After the developer makes a modification, it is marked as a modified state, which is subject to regression test verification by the tester.
- Rejected: If it is considered not a bug, the modification is rejected.
- Delay: If it is considered that modification is not required or cannot be modified temporarily, the modification will be postponed.
- Closed: The bug that modifies the status is closed if the tester's regression test is verified and passed.
- Reopen: If it is verified that the bug still exists, the bug needs to be reopened and the developer can modify it again.
invalid bug:
- open->closed
- open-rejected-closed
The actual practice of each project team in the defect status change process may be different, and it needs to be used in conjunction with the actual development process and collaboration process.
For example, a newly discovered bug by a tester must be reviewed by the test team leader before deciding whether to open it and assign it to the developer. Bugs opened by testers can be directly assigned to the person in charge of the program module corresponding to the bug, or they can be required to be submitted to the development supervisor first, and the development supervisor will review and then decide whether to assign it to the developer for modification.
PS: Bug tracking and status changes should follow some basic principles:
- For each defect modification, the tester must take a new version containing the changed code for regression testing to ensure that the same problem does not reappear before the defect can be closed.
- Bugs that refuse to modify and delay modification need to be reviewed by representatives of testers, developers, and users (or people representing users).