How to effectively discover and input bugs?

It is a small and simple problem, but when it is closely related to daily work, it becomes a major problem that must be faced by testers throughout their work, there are always different insights at different stages of work, from the beginner testing cainiao to a certain level of technical or management personnel, we need to carefully analyze and track the process from bug generation to final solution. Today, I have a hard time talking about my personal opinions.

The premise is that you already have a good bug management system and a good bug model, so that you can enter problems, development, and products in a correct and unified manner, the test has such a common platform that makes it easier to analyze and solve tracking problems, and also makes it easier to statistically analyze related problems.

In general, there are three steps from bug discovery to entry:

　　1. Discover and reproduce bugs

Find the method for recreating bug100 %. If the reproduction is not 100%, you need to analyze the probability of reproduction. If the reproduction is relatively random and the probability cannot be analyzed, you can communicate with development or test colleagues, see if you can help find a reproduction method.

　2. Locate the cause of the bug

When beginners are used to discovering bugs, they immediately put the bugs into the database. However, the best way is to analyze and communicate with developers based on their own understanding and try to locate the causes of the bugs, the bug reproduction steps are simplified to a minimum, and the bug description can also point to the key. This is first based on the depth of product functions and the use of debugging tools. In fact, this is also the most difficult point for testers. It cannot be said that the deeper the positioning, the deeper the tester's skill, actually reflects this point to a certain extent. Effectively locating bugs not only helps you better understand product features, but also reduces the chance of repeating bugs, because it is often found that many bugs have different causes. More importantly, it reduces the time needed to return to bugs and saves everyone in the same group time.

　　3. Input bugs

In general, developers only modify bugs according to your descriptions. Therefore, when entering bugs, it is important to summarize the descriptions of bugs, whether they are concise and clear, and whether the reproduction steps are clear. Generally, there are four input bugs:

1) KEYWORDS:

First, indicate the functional modules of the bug and whether there are special instructions, such as system compatibility and product compatibility. We collectively refer to it as keywords. This keyword can be used to query bugs in the bug Management System in the future, for example, to search for all bugs of a function module in a certain period of time.

2) detailed descriptions of bugs:

It mainly refers to a comprehensive and detailed description of the problem phenomenon and your positioning analysis. People who are interested in Bugs want to clearly know from this description what the bug is, where the error is, and what the correct one should be, you can even understand the cause of the bug without looking at the reproduction steps.

3) Reproduction steps:

Although many bug developers can locate the nature of the problem through detailed descriptions and modify the bug, it is also necessary to reproduce the write steps, because you need to enable anyone who doesn't understand this function to reproduce this bug through your description, and make it easier for you to read this bug later, clearly understand the reproduction process of this bug.

Some bugs are easy to reproduce, but some bugs are difficult. Therefore, if you can reproduce a bug, you need to accurately explain the necessary conditions in the reproduction steps to list all the steps. If you discover bugs that cannot be reproduced, you need to provide as much effective information as possible to developers and keep the environment for analysis. It is best to pull the debugging analysis immediately. Or back up the environment, especially the bugs that you cannot confirm. The issue of whether to report bugs that cannot be reproduced has been very tangled. For bugs that developers identify as problems and find the cause, they must report the issue, so for bugs that cannot locate the cause, as you describe: in the XX environment, an unknown cause crashes once, and such bugs are submitted for development, and people can only stare at them, because there is no useful information. This bug is still not reported. It is wonderful to remember to keep an eye on it.

So here we need to involve a bug evidence problem. If the interface problem is not easy to describe, we need to keep the environment for the problem that is difficult to reproduce, and try our best to get dump for problems such as crash blue screen crashes.

4) information related to other bugs

After the previous steps, you have confirmed that the bug exists. At last, you need to provide relevant information so that you can determine the time and environment of the bug. It mainly includes the project, version information, bug type, and bug discovery environment to which the bug generation module belongs. This information is mandatory for each bug, you can select and enter the information in the Multi-choice box to facilitate query and management.