Introducing problems

I believe that many developers see the test raised the bug list is not without teasing: what is this problem?

Also believe that many test engineers in the process of testing, encountered problems do not do a second confirmation, directly put forward a bug single. Next, let’s take a look at Zhang SAN’s question as an outsider:

Zhang SAN in the bug, immediately to the development of the bug, not to check the cause of the bug. This leads to three problems:

  • Zhang SAN does not verify the validity of the problem through secondary validation, which may result in invalid problems being referred to development.
  • By not identifying the cause of the problem, John may be pointing the finger at the wrong development.
  • Affect each other’s work efficiency

Not easy to find the effective problem, a simple sentence to describe the problem and bill of lading, there is a problem again:

  • If the description is not clear when making a problem sheet, it is difficult for the development to reproduce the problem
  • Affect the efficiency of each other’s work: development cannot reproduce the problem, and it takes time and development to describe the problem.

The symptoms listed for development testing:

Not understanding requirements

Wrong posture: Always test for situations that would never exist in a production environment. There are even requirements that are designed this way, where bugs are mentioned.

Get it right: Get your requirements straight, and when designing use cases, eliminate things that are not actually going to happen.

Inaccurate bug location

Wrong posture: Bug assignment. Front-end bugs refer to the back-end, and back-end bugs refer to the front-end.

Correct posture: analyze the cause of the error, analyze whether the front-end or back-end bug, 123 hit 😌

The problem is not clearly described

Wrong posture: The description of the bug either opens with a picture, or a sentence, the development of the recurrence of the bug depends on meng.

Correct posture: The problem should be described in detail, illustrated, scene description, as well as bug occurrence process, corresponding account password, etc.

To solve the problem

The correct flow from problem discovery to problem raising should look like this:

  • After you find a problem, try again to reproduce it.
  • After identifying the bug, analyze whether the source of the bug is the front-end or back-end. In this case, we need to identify the cause of the problem based on operations, request responses, service logs, and other analysis.
  • Now that the bug is valid, how do we let developers know about the bug recurrence process?

Mention the bug

The bug list is divided into three parts: title, basic information and description.

  • The title

    • [Problem side][Summary description]

  • The basic information

    • Severity of problems: The more serious problems are dealt with first
    • Problem priority: Problems with a higher priority are dealt with first
    • Bug Type: Indicates the bug Type
    • Assigned users (i.e., bug-introducing development)
    • Associated items: Associated with specific items for later analysis
    • Associated development (that is, bug-introducing development)

  • describe

    • Related test data

      • Such as test account, page jump link and some other test data.

    • Scenario description: How you describe a scenario is important and a key factor in determining whether your development can be quickly targeted

      • What kind of action is causing the problem
      • Try again to reproduce according to the steps we combed, and describe the operation according to each step
      • After the scenario description is complete, the expected results as well as actual results need to be described or presented

    • The screenshots

      • A screenshot of the UI page
      • Screenshot of an interface error
      • Snapshots of logs
      • Screenshots of DB results, etc

    • Troubleshooting Result [Optional]

      • Can exercise the ability of personal problem solving
      • The development will thank you

case

Case a

Title: [BE] / API/XXX returned incorrect data (note: if there are many bugs in a requirement or a problem is caused by the front end and the back end, labeling the responsibility can let us quickly know who is responsible for the problem)

  • In the scenario, I describe the steps of the problem, followed by the actual and expected results. However, it is not recommended to write a paragraph, it is suggested to write points, will be more clear (dog head: development will thank you). Paste the curl request and the response

  • Put up the relevant screenshots. Remember the relevant screenshots. If necessary, make a note in the diagram.

    • More clear combination of text and text, if necessary in the map to mark

conclusion

So the first thing we need to do when we find a problem is to confirm whether it is caused by our own testing irregularities. If you are not sure, try again to reproduce. Bug descriptions must be specific, otherwise you will not only waste development time, but also your own time. Of course, if some bugs are difficult to describe and the cost of face-to-face communication is the lowest, we can choose the cheaper way.