Test report don't step on the pit

The test report is the core output of testers , It is an important carrying tool to reflect the value of your work , We need to take it seriously , So we should pay attention to the output of the test report , When writing the test report , What points do we need to pay attention to ？

01 Don't misuse templates

Many new testers are writing test reports , Will go to others for a so-called test report template , I always feel that others' reports are good , Without considering the actual situation of your team , It's not that you can't apply modules , Here are two small pits that need attention ：

Header and footers ： In a regular company , There are clear requirements for the header and footer of the document . But our reading habits will hide this content . This will cause you to apply the template , The modification of this part is ignored , The author once read a test report , Description and... On the header and footer Logo It turned out to be another company , This is awkward .

Blank title ： Templates are generally large and complete , So there will be many Title items , Give it to those who need it , For example, project background 、 Explanation of terms, etc , But these contents need to be tailored according to the actual situation . But novices may not know how to write , Just put it there , Don't delete . The author has seen a test report , There are 2~3 Item has only title but no content , Do you want readers to make up for you ？

02 No clear test scope

In the test report , We need to specify the test scope , If the content of the version is more , It can be abbreviated appropriately , But I have to write . The version content of the product is like a pre-sale train ticket . And the test scope in the test report , It's the ticket check before boarding , To align , There can be no missing , Try not to have entrainment , Otherwise, the train may lose control .

The point of change should be made clear ： If the version cycle is long , Or the demand changes during the research and development process , It needs to be clearly marked out in the test scope , Let those who read the report know clearly which points have been changed , Help them assess the scope of impact .

The cutting should be particularly clear ： For various reasons , The originally planned functions or requirements have not been realized , The cut function should be clearly marked out , Let everyone know clearly what is the final online content . Avoid misunderstanding caused by asymmetric information .

03 The content description is not clear

Don't write the test report as a novella . Various modifiers , There is a lot of running water , Cause the viewer to see the flowers in the fog , specious . I've read some articles that write test reports , The whole report is written , In my submission 、 I think 、 They should wait for a lot of appellation , Finally, draw a hasty conclusion , It's unclear, so .

Test reports should try to avoid subjective opinions , Add a bunch of subjective knowledge . It should be objective 、 State the process clearly and concisely . And as far as possible, it should be illustrated with pictures and tables . Such test reports are pleasing to the eye , It also makes it clear at a glance , So that the test results can be well presented to customers .

04 There is no risk statement

This is a very important point that is often ignored in test reports . In some core versions 、 In the version with larger changes , We need to specify some risk items , It's best to give the necessary solutions or countermeasures . Common risks generally fall into the following categories ：
Defect legacy risk ： Some version defects will not be completely fixed , So what are the risks of remaining defects , How to deal with , Whether it is necessary to unify the external discourse .

Test strategy risk ： In the test time nervous 、 In scenarios with particularly complex business functions , We used a specific testing strategy , What are the risk items that may be caused or left , Whether the plan has been prepared .

Release upgrade risk ： Important changes 、 Involving historical data migration 、 When upgrading the middleware version , In addition to comprehensive verification , It is also necessary to give the necessary fallback scheme .

Business risk ： Whether it depends on the synchronous upgrade cooperation of other subsystems , Is there a third-party system involved in the upgrade , Whether the corresponding training or operation documents have been prepared for the user operation changes brought by the new business （ especially To B Products ）, Whether the user feedback channel is reserved .

05 No test conclusion

Have you seen the test report without test conclusion ？ Um. , I have seen . It needs to be very careful to draw conclusions about the testing work of a certain version , Because you need to be responsible for the test conclusion （ Many people ignore this , Then he was thrown into the pot ）. After combining the testing process and testing risks , We need to give clear test conclusions ： adopt 、 Not through 、 Pass conditionally （ Some functions have been tailored , Or some scenes are through Mock And so on , Possible risks ）. Who says the test conclusion must pass ？

When writing the test report , There are also some small pits that need special attention , such as ： No typos 、 The typesetting should be standardized 、 The chart should be clear , Don't let these small details make others leave a bad impression on the whole test report .

Summary

A good test report should at least include the following points ：
Test range ： What is your final test scope , Which function points are covered . Which are the original iterative planning , Which are added temporarily , What turns in the next iteration . These need to be made clear , People who read the report will not necessarily participate in the whole process of R & D , So you need your test report to reflect what the real iteration content is .

Test conclusion ： From the professional point of view of testers , The quality evaluation of iteration is given , Whether the release standard is met , Whether you can publish , If not , Explain why .

Test risk ： Risks considered during the test , Possible risks after going online , If you know , Please make it clear , Let the roles of the team （ Research and development 、 product 、 Department heads, etc ） Based on your risk analysis , Decide whether to release the version together .

Of course , The test report contains more than just the above , But the above is what people who read the report pay most attention to , in addition to , It should also include, but not be limited to, testing strategies 、 Personnel input 、BUG analysis （ Important to the R & D team ）、 Test improvement suggestions, etc .

Last ： It can be in the official account ： Sad spicy bar ！ Get one by yourself 216 Page software testing engineer interview guide document information 【 Free of charge 】. And the corresponding video learning tutorial is free to share ！, It includes basic knowledge 、Linux necessary 、Shell、 The principles of the Internet 、Mysql database 、 Special topic of bag capturing tools 、 Interface testing tool 、 Test advanced -Python Programming 、Web automated testing 、APP automated testing 、 Interface automation testing 、 Testing advanced continuous integration 、 Test architecture development test framework 、 Performance testing 、 Safety test, etc. .

I recommend one 【Python Automated test communication group ：746506216】, We can discuss communication software testing together , Learn software testing together 、 Interview and other aspects of software testing , Help you advance quickly Python automated testing / Test Development , On the road to high pay .

Friends who like software testing , If my blog helps you 、 If you like my blog content , please “ give the thumbs-up ” “ Comment on ” “ Collection ” One Key triple connection ！