Article Directory
1 Introduction
Compared with BUG, everyone knows that a program that runs incorrectly or does not match expectations is a BUG. Now let's look at BUG from the perspective of a tester.
2. How to describe/create a BUG
Testers need to test the developer's code to find out the problems that the developer may have overlooked, and then report the problem to the developer.
How to describe the BUG clearly and concisely will involve many things. This is not just a simple statement When a BUG is encountered.
The description of a qualified BUG is divided into the following parts:
- The version where the problem was found: There should be many versions of most software. Testers need to know the version corresponding to the problem in order to obtain the code of the corresponding version and reproduce the fault
- The environment where the problem occurs: The environment is divided into hardware environment and software environment. If it is a WEB project, it is also necessary to describe the version of the browser, the operating system of the client, etc. If it is an APP project, it is necessary to describe the model, resolution, operating system, etc. .Detailed environment description is helpful for fault location.
- Steps to reproduce the error: Describe the minimum steps to reproduce the problem.
- Description of expected behavior: It is correct to guide developers from the perspective of users.
- Description of the error problem: the scene when a BUG occurs
Describing a BUG does not mean that it can only have the above parts, but can also describe other aspects, such as: whether the BUG is a front-end problem or a back-end problem, the level of the BUG, etc.
Being able to describe a BUG makes it easy to create a BUG.
3. BUG level
There are different severity levels for BUG. The definition of BUG is different for each company, you need to check the company specification before defining the level .
for example:
- Blocker (Crash) : Problems that hinder development or testing; cause system crashes, crashes, and endless loops, resulting in loss of database data, errors in connection with the database, loss of main functions, and lack of basic modules. Such as: code error, infinite loop, database deadlock, 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).
- Critical (serious) : The main functions of the system are partially lost, the database is saved and called incorrectly, user data is lost, and the first-level function menu cannot be used but 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 saving data in the software, lack of functions required by users, program interface errors, numerical calculation statistics errors, etc.
- Major (General) : The function is not fully implemented but does not affect the use, and the function menu has defects but does not affect 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 (minor) : interface, 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. BUG life cycle
In the process of executing the test, if there is a corresponding BUG, the tester needs to create a BUG on the corresponding BUG management platform.
Each company and each tool has an inconsistent definition of the bug life cycle.
For example:
- New: Testers create bugs
- Open: The developer confirms whether it is a BUG, and if it is a BUG, the status will be changed to Open
- Rejected: If it is considered not a bug, the modification is rejected.
- Fixed: After the developer fixes the BUG, the status will be changed to Fixed
- Delay: After confirming the BUG, if the level of the BUG is not high or the developer cannot fix the BUG immediately, the status will be changed to Delay.
- Closed: BUG confirms that the repair is complete, and the tester changes the BUG to Closed
- Reopen: The developer fixes the BUG, but the BUG has not been fixed, and the BUG status is changed to Reopen
5. What to do if there is a dispute with the development
After all, testers have to try their best to test the developer's code and raise bugs. If it is not handled properly, it is easy to have disputes with the development. What should we do if there is a dispute?
For this problem:我们要坚持"对事不对人".
- Have "critical thinking", think about whether the BUG you describe is not clear enough, etc.
- If the developer does not recognize the level of the BUG, we must ensure that the level of the BUG is justified.
- Proposing a BUG will increase the workload of the developer, and the small problem may not be resolved. At this time, the developer can be guided to empathize, "If you are a user, would you accept such a situation?"
- Not only to propose BUG, but also to propose solutions
- If it is indeed a BUG, and friendly communication cannot solve the problem at this time, then a BUG review will be held.
The above answers are for reference only, if you have better ideas, you can also add them.
Supplement: People who need to participate in the BUG review include product managers, development representatives, test representatives, etc. The discussion content is generally divided into two parts: 1. How to solve the BUG 2. How to avoid similar problems from happening.
Thank you for watching! I hope this article can help you!
Column: "Software Testing" is constantly being updated, welcome to subscribe!
"Wish to encourage you and work together!"
