The problem sheet is a problem found during the version testing process, which can also be called a bug or defect. Bill of lading is one of the essential skills of every tester. But not all testers will do this job well. When a problem is found, how to make a bill of lading and how to ensure that the content of the bill of lading is reasonable can reduce the workload of communication with developers, and even subsequent testers can directly obtain valid information from the problem sheet when they re-verify the synchronization order. This paper mainly describes from three aspects: the specification of the bill of lading, the specification of the content of the bill of lading, and the specification of the content of the return question sheet.
Bill of Lading Specifications
1. The correctness of the bill of lading. When a suspected problem is found during version testing, you need to analyze the root cause of the problem yourself. If the analysis can not come out, you also need to find the development positioning to confirm the problem. Unanalyzed issues cannot be billed directly.
2. Timeliness of the bill of lading. When you find a problem and confirm that it is already a problem, please make a bill in time. A bill of lading early also allows enough time for revisions to be developed, and also prevents you from forgetting about it while you are busy with the work at hand.
3. Do not combine the problem bills of lading. Try not to combine multiple questions into one question sheet. It is easy to cause missed changes in development or omissions when testing regression. Because it's possible for different issues to involve multiple developers, it's easy for a version manager to overlook a transfer to a single development.
4. The content description specification of the question sheet. This usually includes the test version, the feature or category it belongs to, the discovery phase, the problem rating, the problem description, etc.
Specification of the content of the bill of lading
Every company will have a fixed-use problem ticket tracking management system. Usually the problem list will include the following main aspects:
1. Brief description of the question sheet. Usually includes site, features, and brief description.
2. Test version. Including the platform version that the business includes and mainly depends on.
3. Preconditions. The main parameters or special parameters involved in the use case.
4. Operation steps. The main steps of the reproducible operation are sufficient.
5. Expected results.
6. Actual results.
7. Preliminary analysis of the problem. The root cause of the problem needs to be analyzed before the bill of lading. If the analysis fails, seek development assistance.
8. Problem related screenshots, logs, messages, etc. Provide the basis for the problem list analysis.
Question sheet regression content specification
When the problem ticket revision goes back to the test regression, the test needs to submit the regression scenario and process results to the system. The content specification of the return of the question sheet is mainly as follows:
1. Test version. Iterative version is included in the version number.
2. Test ideas. Mainly describe the test plan of regression problem list.
3. The testing process. Save and upload the use case results of regression ticket verification.
4. Test conclusion. Regression verification passed, failed, partially passed, etc.
5. Others. If the use case is an automation script use case, the script can be packaged and placed together. If the question sheet needs to be modified in other versions, it can be easily obtained.