Vulnerability handling Specification

1 Overview

This document defines the whole life cycle of bugs, and standardizes the solution and management process of bugs. There are rules for bugs to follow in the process of circulation. Specification of bug severity level and bug resolution priority, so that developers and testers can accurately judge the severity of bugs and solve them according to this document.

2 Key roles and responsibilities

Role	Responsibilities
Test engineer	1. Submit bugs according to specifications; 2. Verify whether the bug has been solved in time; 3. Timely pay attention to bugs rejected by developers, and communicate and discuss solutions with relevant personnel
Test Leader	1. Review the bugs submitted by test engineers; 2. Review bugs regularly, report the status quo, and give solutions
Development engineer	1. Analyze and solve bugs based on priority
Development Leader	1. Review bugs regularly, and strengthen code review and unit test for bug-rich modules; 2. Analyzed the progress of bug resolution, and made risk assessment on product quality and progress
Product manager	1. When there is disagreement between development and testing, confirm requirements 2. Prioritize bug modification from a product perspective

 

3 Bug Lifecycle

 

4 Writing specification

4.1 Theme

1) Describe le in a short sentence; Or a problem caused by an operation;

2) Concise and get straight to the point when describing the problem, but grasp the main points;

3) The number of occurrences of occasional bugs marked before the theme;the problem of a modu

4) Some modules have more functions, and specific operations can be marked before the topic description

Example:

[Account switching] Login with non-local mobile phone number. After switching back to local phone number and logging in, no message can be received；

The program stops running when adding carrier library

4.2 Description

 Description areas include: steps, expected results, actual results, test environment, bug time, screenshots, logs

1) Numbers and describe step by step the recurrence steps of the problem;

2) Different operation steps produce different problems, and need to report bugs respectively; Try to report one problem per bug;

3) If there is an occasional problem, it must be clear when the bug appears, and provide screenshots and logs

5   Bug solutions

New status bugs submitted on the same day, the corresponding developers need to review them all within 2 days, and divide the bugs into the following 3 categories: refusal, in progress, delay, feedback (to the product)

Develop fixed bugs: set the bug status to resolved; At the same time, add verification version number, error cause and solution

ex：

Verification version: V1.0.1.1101 (1101 means it can be verified on November 1st)

Cause of problem: no conditional judgment

Solution: Make reasonable boundary judgment

Bug status is rejected by the developer: Assigned to the bug creator; At the same time state the reasons for the refusal

ex：

Reference to the design of XXX, testers understand wrong

The bug lacks the necessary information：Set bug status to rejected; Assigned to the bug creator; At the same time state the reasons for the refusal

ex：

      Missing required log

The development has been fixed, and the testing has verified that the bug passed：Set the bug status as solved, and indicate the approved version number;

ex：

     Verification of V1.0.1.1103 passed

Development fixed, test validation failed bugs：Set the BUG status as "hit back", and indicate the reason for feedback according to the actual situation;

ex：

The V1.0.1.1103 version verifies that this problem still exists;

Steps: XXX

Time of occurrence: XXX

Test environment: XXX

Screenshots, logs

Tester and developer controversial bugs：The tracking category is set as demand and the state is set as feedback; Assign to corresponding products, discuss and confirm the modification plan; And indicate the reason for the feedback

ex：

     Test that the IP address is set wrong, should prompt the user, but should not appear to stop running

Bug that can't be fixed：Change the bug status to recognized, and indicate the recognized reason

Bug that can't be reproduced：Mainly rely on the log to analyze the cause of the problem, and then make corresponding modifications; After developing the modification, test back to 3 versions, or use the testing tool to test repeatedly, if there is no reappearance, close first; And indicate the closed version number

ex：

     V1.0.1.1103 is not reproduced yet, close first

A bug that needs to be postponed：Change the bug status to low and the scheduled completion date to the scheduled date to fix the bug; And state the reason for the extension

ex：

     Requirements change, change momentum is large, affect the release time

Product confirmation of bugs that need to be corrected：Modify the bug status to call back, assign it to the corresponding developer, and indicate the modification content

Product confirmation does not need to modify the bug：Change the bug status to resolved and indicate why it is not required

It's not a bug on the back end：By the bug end (the end) personnel to give analysis, transfer to the corresponding end and developers, and oral notice

 

6  Bug Tracking Category

Bug: A problem that the tester determines to be a bug;

Optimization: the function has been implemented, need to do the performance optimization problem;

Suggestions: Test some improvement suggestions for the product;

Requirement: a demand problem that requires the product to be reorganized

 

7  Bug status

New: New bug, optimization, or suggested problem status submitted by the tester;

In progress: The developer has confirmed that it is a bug and the problem status needs to be fixed;

Resolved: The status of the problem that the developer has fixed;

Closed: Test validation to determine the status of the resolved problem;

Rejected: Issue status rejected by the developer for testing that is not considered a bug;

Feedback: Feedback to product confirmed problem status;

Recognized: A problem state that is confirmed to be a bug but cannot be solved;

Call back: Test verifies that the bug has been solved, but the problem status is still not fixed

 

8  Bug Severity

 

Fatal: Unable to perform normal functional operation, or system crash due to product reasons, which needs to be fixed immediately

ex：

       The program could not start, or log in;

The program crashes, stops running, and the system crashes, unable to proceed to the next operation

Serious: there are serious defects in some functions, which can still be tested without affecting the stability of the product

ex：

     An occasional program crashes and stops running

Function not implemented

Data out of sync

Function error, cannot proceed further operation

General: minor functions or some errors in the interface do not affect the normal testing

ex：

      UI display is inconsistent with renderings;

Incorrect prompt;

Wrong character;

The query results show an error

Suggestions: Test some improvement suggestions for the product

 

9  Bug priority

Low: the impact on the product is relatively small, in the case of time does not allow the temporary modification;

Medium: Must be revised, not necessarily right away, need to discuss to make sure that the revision is completed before a specific milestone;

High: Must be modified before release;

Urgent: affects the test, needs to be fixed immediately or in the next release