Bug reference standard (reposted on the Internet)

I. Purpose

Defines and standardizes the concept, type, status, and severity of bugs to further guide ourTestWork.

Ii. Concepts

BUG: flaws in the software may cause system failure. Simply put, there are errors or defects in the software system that may cause system errors, failures, crashes, and other problems.

III,BugType Division

• Function

A. duplicate features

B. Additional Functions

C. The function implementation does not conform to the design requirements.

D. Functional usability, convenience, and ease of use

• Interface Class

A. The interface is not beautiful.

B. Control Arrangement and format inconsistency

C. unreasonable or incomplete focus control

• Data Processing

A. unreasonable Data Validity Detection

B. The data source is incorrect.

C. Incorrect Data Processing Process

D. The data processing result is incorrect.

• Process

A. process control does not meet the requirements

B. Incomplete Process Implementation

• Prompt information

A. duplicate information or improper timing

B. the prompt message format does not conform to the requirements.

C. When the prompt box is returned, the focus position is unreasonable.

6. Suggestions

A. Functional recommendations

B. Operation suggestions

C. School Inspection suggestions

D. Suggestions

7. Performance

A. Concurrency

B. Data Volume

C. compression rate

D. Response Time

8. Common sense

A. against normal customs and habits, such as dates/festivals

9. special classes

A. It does not meet the special requirements of the OEM or demo version

IV,BugStatus

Submitted: The tester finds a bug and submits it to the status in the Bug Management System. (Initial status)

Modified:ProgramSubmitted to the Bug Management System after modifying the bug.

Do not modify: the programmer or project manager determines not to modify the bug based on the requirements in requirement analysis, outline design, and detailed design instruction. The bug status is not modified, so you need to explain the reasons.

Latency: the status of temporary delay based on the current project process or plan

To be discussed: You need to discuss the status of the bug to be modified.

Verified: Status of bugs that have been resolved and retested by the tester.

Close: it is completely resolved and is only available for future reference.

Re-open: re-appeared in the new version, re-opened the previously closed bug status

(Of course, in the bug tool, you can customize state projects suitable for the project, such as abolishing and rejecting the project)

V. BugClassification and priority

1. Serious: crashes, data loss, complete loss of main functions, system suspension, and other errors. Modify the priority to the highest level and the programmer needs to modify it immediately.

2. relatively high: the loss of main functions leads to serious problems or fatal error declarations. The priority is changed to high. programmers must modify the priority level as soon as possible.

3. General: Secondary functions are lost, which is not very serious. If the information is not accurate. The priority of the change is medium, which needs to be modified by the programmer.

4. Mild: minor issues have almost no impact on functions, and products and attributes can still be used. If there is a typo. The priority of modification is low. programmers must modify or not modify the priority.

6. Priority of bugs (generally associated with bug levels)

Reference 1: urgent, extremely high, high, moderate, and low

Refer to 2. Next build version, a test, B test, release version, and final release version

VII. Bug Record Content

• No.

• Title

• Project Module

• Test phase

• Type

• Operating Environment (Operating System, Ie and other software and hardware environments)

• Severity (Level and priority)

• Bug status

• Tester

• Programmers (releasers)

• Solution

• Resolution date

• Test date

• Detailed descriptions (steps, results, expectations, and remarks)

No.		Test Date
Title
Project module		Test phase
Tester		Operating Environment
Bug type		Level and priority
Detailed description
• Steps (operations, data input, etc) • Results • Expectation • Remarks
Programmer		Resolution date
Solution

Note: according to the specific project situation, we customize the bug specifications that are truly suitable for the project. Everything is fundamental to improving product quality and the company's benefits. If there is no uniform specification for bugs, it is only for the same purpose.