Testing Work specification of the testing department

Testing DepartmentTest Work Specification

1. Purpose

Standardize the work content and flow of the dedicated test group, and improve the overall work efficiency of the dedicated test group through the Standardized work mode.

2. Product testing work requirements 2. 1. Testing Work Flow

The test flowchart is as follows:

2. 2.2.1. Initial

Obtain the product test plan from the project manager or R & D Engineer, including the version number, planned completion time, requirement content, and modification content, discuss with the task initiator whether the product is testable based on the needs of different products.

2.2.2. Plan

Develop a test plan based on the time and scope of the product test plan, select existing test cases, write new test cases, and identify the use cases for each round of test, the selection of use cases should be reviewed and confirmed.

Output: test plan, test case, or outline

2.2.3. Run

After receiving the product package for testing, you must first perform a smoke test to ensure that the basic installation/uninstallation process is normal and the data flow is normal before entering the function test.

In each round of testing, the identified test cases should be fully executed, and the bugs found in the tests should be updated to the current work plan of the team's task management system, notify the R & D engineer to make the modification. Only after all the bugs are modified can the complete package be submitted for the next round of testing. Before the next test is enabled, R & D engineers are allowed to submit two files for Bug verification by replacement. After the bug verification is passed, developers are required to submit the package for the next test.

Output: Bug list, periodic test report (issued after each round of test execution)

2.2.4. Closing

After the internal test is completed, you must prepare the internal test report, release notes, user manuals, installation instructions, and other supporting documents.Some sub-modules can be stored in the database without providing user manuals.

Output: internal test report, version release notes, User Manual (optional), and installation instructions

2.2.5. Completed

If the package passes the test, enter the design change notice and notify the engineering department to package the program and upload it to the subdirectory specified in the release directory on the FTP server. After the package is sent to the Engineering Department, the test phase is completed.

Output: design change notice

2.2.6. Notes

N check whether the submitted testing work plan complies with the entrance standards. If the description is unclear or inaccurate, or the product name or version number is incorrect, developers are required to submit a test application again after modification.

N Ensure that the test cases are completed in each round, and then the bug is submitted to the developer. The developer is required to fix all the bugs before submitting the test. If only some modifications are made, test is not accepted unless reasonably justified.

3. external technical support work 3. 1. workflow 3. 2. Detailed description 3.2.1. Initial

The best way to submit external problems is to use an email for interaction. After receiving the problem, the tester should carefully check the Problem description. If the problem description is incomprehensible, the tester should directly interact with the problem submitter.

3.2.2. Analysis

Determine whether the problem is a known defect. If the problem is a known defect, directly reply to the problem submitter to handle the problem.

If it is not a known defect of the product, the problem should be reproduced on site, the cause of the problem should be analyzed, and the analysis conclusion should be transferred to the developer for a solution. In addition, you must enter the problem in the Bug Management System.

3.2.3. Final

A report on problem solving is provided. The report includes the analysis and positioning conclusions, and a solution for known defects. The report should be sent to the problem submitter and copied to the Test director and product manager.

3.2.4. Completed

Confirm with the problem submitter whether the problem is resolved. If yes, the task is completed.

3.2.5. Notes

It is best to use emails for interaction with N questions to save the issue interaction records as the basis for tracing and work records.

N for newly discovered problems, if they are product defects, you must fill in bugs, whether or not they have been solved manually.

4. Other requirements 4.1.bug description

When entering a bug, you must clearly describe the following:

N operation steps during the test, which clearly describes how the test is performed.

N problem phenomenon, it is best to attach.

N test analysis conclusions and suggestions, and the test analysis conclusions are given.

 

4. Instructions for filling in weekly/monthly reports 4.2.1. Weekly task statistics

Task Name	Working Hours (days)	Detailed description	Work result

4.2.2. Bug statistical table

New (number of new bugs)	Reopen (number of re-opened bugs)	Closed (number of closed bugs)	Reject (number of bugs rejected by developers)
0	0	0	0

Instructions:

N describes what work has been done this week and how much work is used for each job (unit: Day.

N. Summarize the bugs of this week.

 

4.2.3. Monthly Work Report

Monthly reports include:

1. Main Task Distribution this week: (%)

Project name	Test task (days)	Document Writing/modification (days)	External technical support (days)	Other (days)
XX Project	10	20%	50%	20%

Instructions:

N summarizes the work of this month and describes the number of working days that each task occupies in each project.

N. Summarize the problems found in the current month. all problems can be solved. analyze the causes and give some suggestions and opinions.