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

1. Introduction to the document

1.1 Purpose of preparation

l Standardize defect reporting and handling process

l Specification defect version maintenance process

l Improve defect quality

l Improve work efficiency

For testers, defects shall be filled in and reported in strict accordance with the requirements in the "Proposal Filling Specification";

Developers and testers should strictly follow the treatment agreement for various state defects in the "Proposal Treatment Principle" and deal with defects in a timely manner.

For the test leader, the proposal version shall be handled accordingly in strict accordance with the requirements in "Proposal Version Maintenance."

1.2 Definitions, acronyms and abbreviations

no

2. Defect filling specification

2.1 defect filling procedure

(Required items marked in red for proposals)

A. Select project and proposal type

[Item] Select the defect library to fill in

[Proposal Type] Defect proposal Select "Problem"

User experience proposals Select "Enhancement proposals"

B. Enter the proposal details

[Summary] The title of the defect or suggestion is a summary of the specific description of the proposal and should be concise.

[Priority] ABCDE is divided into five levels, with severity decreasing from A to E.

l See classification criteria

[Expected Date] The date on which the proposal is resolved, up to the date on which the next round of testing begins. You don't have to fill it out.

[Component] Problem component

[Impact Version] The project version where the problem was first discovered

[Fixed Version] The version that solves the problem

l When a new proposal is submitted, the revised version is consistent with the selection of the affected version.

[Assigned by] Solver of proposal:

Defects with no objection to requirements are directly assigned to the development leader, who arranges for solutions.

Defects requiring product validation are assigned to the product owner, and proposals confirmed to be bugs are assigned to the development owner; otherwise, they are assigned to the test owner.

[Environment] Test environment: Operating system + browser version

[Description] A specific description of the problem or suggestion, in the format shown in

2.2 DECISION OF DEFECT PRIORITY

Class A failure: crash, system paralysis, key data unavailable, key functions of the system lost in some cases, key performance of the system can not meet the design indicators, etc.

Class B fault: basic function instability or loss, system importance can not reach the design index, etc.

Class C failure: The main function is unstable or lost, but there is no serious impact on other functions of the system.

Class D fault: the main and basic functions of the system have been realized, bugs can be bypassed, but the function realization is unreasonable, there are some interface problems, or the operation is inconvenient, it is easy to cause user ambiguity or misoperation, and there is no big impact on the system function realization.

Class E failure: Descriptive, recommendatory problem. System functions, performance, interface, operation and other aspects of the existence of the need to improve the place.

2.3 Format of defect description

[Four elements] Test account/url, operation steps, expected results, time results

Examples:

2.4 Supplements to defective proposals

[Additional Screenshots] Upload screenshots of bugs found to the proposal. When reporting bugs, it is recommended to paste screenshots as attachments to visually present the defects found.

[Additional File] Upload a file related to the proposal to the proposal. This file can help solve the proposal.

3. Version maintenance of defect proposals

Proposal version maintenance is performed by the test leader after each defect review meeting

3.1 affected version

Affected version refers to all versions from the discovery version of a defect to the closure of the defect verification.

Late version maintenance, not modifying the affected version of the proposal.

3.2 amended version

Fixed version refers to the version that solves the problem.

Later version maintenance needs to modify the revised version:

l If it is confirmed by the tripartite meeting that a proposal must be resolved in this project, the revised version of the proposal shall be added to the original revised version.

Examples:

The original revised version of this proposal was: Sina-Space-1.1 First round of system testing

Added revised version: Sina-Space-1.1 Second round of system testing

If the proposal is reopened in the second round, the revised version will continue to be added until the proposal is verified and closed.

l If it is confirmed by the tripartite meeting that a proposal can not be resolved under this item, the revised version of the proposal is changed to "planned version."

4. Principle of defect handling

4.1 Defect Handling Process

A.

The new newspaper proposal has a status of "open."

"Reopened" proposals, handled by developers.

Click [Resolution Proposal]

Bug Fixed: The Bug described in this proposal has been resolved.

Bug Unfixable: The Bug described in this proposal cannot be fixed for technical reasons.

[Mission Completed] Complete the proposal for the type of mission.

[Duplicate] The problem described in this proposal has been clarified by another proposal before, so it is necessary to note the repeated proposal number.

[Incomplete] The description of the proposal is unclear and key steps are missing.

[Cannot reproduce] Bug described in proposal cannot be reproduced.

[Not a Bug] After confirmation by product personnel, confirm that the Bug described in the proposal is not a Bug, which is the product definition.

[Delayed Processing] Due to time schedule, online and other reasons, the proposal is not resolved at present after confirmation by the three parties.

[Abandonment] The proposal shall be abandoned after being confirmed by the three parties due to technical and time progress reasons.

B.

Proposals that fail regression testing with status "reopened"

"Reopened" proposals, handled by developers.

Click [Resolution Proposal]

Bug Fixed: The Bug described in this proposal has been resolved.

Bug Unfixable: The Bug described in this proposal cannot be fixed for technical reasons.

[Mission Completed] Completed the proposal of the mission type.

[Duplicate] The problem described in this proposal has been clarified by another proposal before, so it is necessary to note the repeated proposal number.

[Incomplete] The description of the proposal is unclear and key steps are missing.

[Cannot reproduce] Bug described in proposal cannot be reproduced.

[Not a Bug] After confirmation by product personnel, confirm that the Bug described in the proposal is not a Bug, which is the product definition.

[Delayed Processing] Due to time schedule, online and other reasons, the proposal is not resolved at present after confirmation by the three parties.

[Abandonment] The proposal shall be abandoned after being determined by the three parties due to technical and time progress reasons.

C.

"Resolved" proposals, processed by testers.

If regression verification fails, click [Reopen Proposal] and comment according to the given comment.

Regression verification passed, click [Close Proposal], and give comments according to.

4.2 defect closure principle

Developers cannot close proposals.

Proposals can only be closed by testers.

If developers are found to close proposals, they should communicate in time and then "reopen proposals" and other operations.

4.3 defect annotation principle

Close proposal with comment XXX Round X System Test (Smoke Test X) Verification Passed

Re-open proposal with comment: XXX Round X System Test (Smoke Test X of) Verification Failure, Reason XXXXX

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.