Excerpted from /u012938881/article/details/48652189

Usually considering these two aspects before writing a report will make your report more readable, that is: Report requirements What is the topic being expressed and who is the audience/audience of the report. For the same (or similar) topic, the audience/audience is different, and the specific content that needs to be stated in the report is usually different.

Below I would like to list the mode and content of the weekly test report from the perspective of the tester and the test team leader (responsible person).

1. Tester (tester)

Generally speaking, testers’ weekly reports are reported to their team leaders. As far as my own work experience is concerned, in general, the test team of a software company The leader has both project and administrative aspects, that is to say, on the one hand, he leads the testing tasks assigned to this test team, and on the other hand, he also pays attention to the work performance and team development of the team members. Therefore, the weekly report reported to the test team leader must explain in detail the work situation of the week from the aspects of project and team cooperation. It can probably include the following points:

1. Content summary and time spent list

Describe your main work situation this week, such as which projects and related tests you participated in , attended several company meetings, participated in several related training courses within the company (or outside), read any work-related materials/books, etc., and at the same time (recommended in the form of a table) list each job (or Related) content (work hour)

2. Number of test cases executed

List by project, how many test cases were executed this week, and how many were passed, How many fail, how many test cases are blocked and cannot be executed (the specific reason for being blocked needs to be listed separately, such as a bug or a certain test resource is not in place), and how many assigned test cases are not completed. This information is recommended to be given in tabular form, see the sketch below:

PassFailBlockedRemaining

Project A253216

...

If ad-hoc or exploration testing is performed, consider listing the test content in tabular form.

3. The specific number of bugs submitted

An important aspect that reflects the performance of testers is the quantity and quality of bugs submitted. All listed here are the number of valid bugs, the number of invalid bugs (duplicate bugs, unreproducible bugs), and the number of verified bugs (valid fixes-fixed, invalid fixes-reject) that you submitted in each test project this week. ), it is also recommended that this information be given in tabular form, see the sketch below:

Submitted-ValidSubmitted-DuplicatedSubmitted-UnreproduciableVerify-FixedVerify-Reject

Project A52083

......

4. Others

Any other work-related content. For example, you want to have an additional testing platform, you need a certain professional book, etc.

2. Test Team Leader

Generally speaking, the test team leader’s weekly report covers two aspects. One is the project-related situation. The target readers of this content are all personnel related to the project. (Project managers, product managers, developers, testers, publishers, etc.), and the other aspect is about team management (sometimes this item is put in a separate report and sent to the test manager, after all, the project related personnel Only pay attention to the test progress of the project and basically do not care about the specific work content of the test team members)

1. Serious issues

Any issues that prevent the smooth progress of the test must be highlighted here Please include a deadline by which you hope the issue will be resolved, and if you know who among the recipients of the report can help move the matter forward, name that person clearly.

2. The completion status of test cases for each project

can be represented by a bar chart similar to the one below

(If necessary, specific links can be given Point to the detailed content and results of this round of testing in the test case management library)

3. The increase or decrease of bugs in each project in fixed time units (usually counted by week in the weekly report)

(The number of bug statistics can be the sum of all priority/severity bugs, or only the first and second priority/severity bugs can be counted, because in many cases, the number of such bugs directly affects Whether the product is released or not, and this is what the project personnel are most concerned about)

For example, see the picture below

(If necessary, give a specific link to the bug management library. Details of all bugs in the project)

4. The bugs in each project are counted according to the percentage of certain categories

(This picture allows people who read the report to see at a glance the main problems in the current project. Where, is it functional, interface, communication, etc.)

For example, see the picture below (the specific classification varies according to different products and projects)

5. (If necessary) Approximate work status of test team members

This can include: how many testers participate, how much time each person spends on each project, and sometimes each person can also be listed. How many test cases have been executed by each tester, how many bugs have been submitted, how many bugs have been verified and other information

Please refer to the following table:

6. Other chores related to any project