Shulou(Shulou.com)06/03 Report--

1. BUG processing flow chart:

Process description:

1. The tester found that bug was submitted to the developer.

2. The developer determines whether it is bug.

3. If it is bug, modify it. After the modification is completed, change the bug status to resolved.

4. If it is not bug, return it to the tester and describe the reason for the return, either for design, for external reasons, or for non-reproducibility.

5. The developer modifies the bug, which is verified by the tester, confirms that the modification is correct, and closes the bug.

6. Verify that the failed bug is reactivated, and the developer continues to modify it until the verification is passed, and the bug is closed.

7. The tester needs to confirm the bug returned by the developer.

8. Confirm that bug is not closed.

9. If you disagree with the developer and think it is bug, you need to submit it to the project leader for arbitration.

10. The project leader confirmed that the bug was modified by the developer, not the bug was closed by the tester.

Note: except for the arbitration link submitted to the project leader, all other links can be completed on the Zen path.

Second, the state that each role should pay attention to.

1. Developers: activate, reopen

Activation: the developer processes the activated bug and sets its status to "resolved", "so designed", "unable to reproduce", "external reasons", "repeated bug" or "deferred processing".

Reopen: the reopened bug is a resolved bug that has been verified by the tester and has not been modified correctly and needs to be modified further.

two。 Testers: resolved, unable to reproduce, designed this way, external reasons, deferred processing

Resolved: testers find BUG with a status of "resolved" and verify it in a timely manner, and set it to "off" if it is indeed resolved. Otherwise, "reopen"

Unable to reproduce: the tester found that the status of the BUG is "unable to reproduce". Modify it in time, describe the steps clearly, and set its status to "reopen".

The design is like this: when testers find BUG with a status of "such design" and "external reasons", they should inform the project manager in time, and it is up to the project manager to decide whether to modify it; follow up the "deferred processing" problems regularly, and notify the developer or report to the relevant person in charge if the problem is not modified according to the notes.

3. Project manager: this is the design, external reasons, postponement

The design is like this: because these BUG are controversial BUG for testers and developers, the project manager must pay attention to these BUG in time and make a reasonable decision in time. If you don't need to change the status to "off", if you need to fix it immediately, set it to "re-open", otherwise set it to "solve later". At the same time, the project manager should also pay attention to the BUG of "deferred processing" so that it will not be missed or forgotten and affect the launch of the project.

III. Definition of severity level and type of defect

U fatal errors include:

1. Cause the system to crash and crash

2. Cause illegal exit, endless loop, communication interruption or exception of the program

U serious errors include:

1. Functional discrepancy

two。 Data flow error

3. Program interface error

4. The password is displayed in clear text

U General errors include:

1. Interface error

two。 Wrong print content and format

3. Input restrictions are not placed at the front desk for control

4. No prompt is given for delete operation

5. The auxiliary description is not clear.

6. Display format is not standard

7. The long operation does not give the user a hint of progress.

U recommendation (non-defect)

1. You can get a better user experience after modification.

IV. Definition of defect priority

1. High: causes the test to be suspended and cannot be carried out; it must be resolved immediately and takes precedence over the development work.

2. Medium: some functions cannot be tested; priority needs to be given to solving the problem, and the solution period is 2 days.

3. Low: it does not affect the progress of the test; it can be solved when it is convenient, and the solution period is 3-5 days.

V. problems that must be paid attention to

1. Developers cannot shut down bug directly, and closing bug must be done by testers.

two。 Comments must be added when dealing with the problem, describing the reason that is not the problem, the planned version time for future resolution, and so on.

3. When dealing with their own problems, even if the problem is not caused by their own procedures, it is best not to ignore the problem, because the problem is shown in your part, and it should be relatively clear where the problem is. It is relatively easy to communicate with other relevant people, which can reduce communication costs, and Energizer can achieve "primary responsibility" or "problem ends here".

VI. Instructions for the use of Zen

1. Zen address: http://172.21.39.42/www/index.php

2. Testers submit bug

After the login is successful, select the test attempt, and then select the project from the drop-down list to enter the corresponding project.

Click create bug to enter the bug editing interface.

Select the bug influence version, the current assignor, enter the bug title, and the bug reproduction step.

Select the bug type and severity, select the system and browser where the bug appears, copy it to the project leader or other relevant personnel, insert the bug screenshot, and click Save bug to submit.

3. Developers deal with bug

After the developer logs in to the system, click on the defect management under the test attempt, select his own project, enter the relevant bug page, find that there is a bug assigned to him, click on the bug title, and enter the bug detailed description.

After browsing the bug reproduction step to locate the bug, modify the bug, click solve after the bug processing is completed, and proceed to the next step. If you think the bug is not a problem, click solve to proceed to the next step.

If the bug modification is completed, the solution selection has been resolved; if it is not considered to be bug, select the design; if the bug is not reproduced, select cannot be reproduced; if it is true that the bug cannot be resolved in the near future, select delay processing; if there are other problems, select the corresponding solution. Fill in the remarks to describe the bug processing. Click Save to complete the bug modification process.

4. Testers verify bug

After logging in to the system, the tester finds the bug assigned to him, and clicks bug to enter the bug description.

Check the bug solution and bug status, and if it is resolved, verify that bug is sure of the modification, if the modification is complete, click close, if the bug modification is not correct, click activate to reopen bug.

If the bug status is not reproducible, you need to reproduce the bug yourself, if it really cannot be reproduced, close it, activate and communicate with the developer or demonstrate the reproduction of the bug on the spot if it can be reproduced.

If it is another state, please negotiate with the developer to resolve it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.