[Software Testing] Test Case Review Instructions

1. Purpose of use case review

Provide a reference standard for use case review to ensure the coverage and effectiveness of the review

• In order to avoid inconsistencies in the understanding of the requirements of the three parties
• Ensure that the quality standards of the testers are consistent with the project standards
• In order to reduce the ineffective work of testers in the execution stage
• Ensure that relevant personnel have an understanding of the needs to be launched

2. The role of use case review

1. For product managers

• Check whether the testers understand the requirements accurately and ensure that each requirement point is covered.
• By reviewing normal and abnormal test cases, it is also a process of self-retrospection to reflect on the situation that was not considered when designing the requirements at that time.

2. For developers

• Check whether there are still many situations that have not been considered perfect in your own program code. It is also a process of self-retrospective inspection of your own code, which indirectly realizes the left shift of the test.
• The three parties reached a high degree of agreement on the timely communication of the logic that cannot be realized in the use case.

3. For testers

• Communicate with all parties to improve test cases

3. Use case review participants

The use case review must require the participation of the product (the product manager who formulates the requirement), the development (the front-end and back-end developers who implement the product), and the test (the tester who is responsible for writing and executing the requirement use case).

The meeting is led by the testers, and the test students with corresponding needs go up one by one to explain their test cases.

• Review within the test group: participation of members of the test department
• Review within the project team: participation of project managers, product staff, developers and testers

4. Use case review content

1. General use case review content

• Whether the structural arrangement of use case design is clear and reasonable, and whether it is conducive to efficient coverage of requirements.
• Whether the priority arrangement is reasonable.
• Whether to cover all function points on the test requirements.
• Whether the use case is well executable. For example, whether the preconditions, execution steps, input data, and expected results of the use case are clear and correct; whether there is an obvious verification method for the expected results.
• Whether redundant use cases have been removed.
• Does it contain sufficient negative test cases. Fully defined, if the 2&8 rule is used here, it is 4 times the number of positive use cases. After all, in a robust software, 80% of the code is to "protect" 20% of the function implementation.
• Whether to design test cases for user usage scenarios and usage processes from the user level.
• Whether it is concise and reusable. For example, highly repetitive steps or processes can be extracted and defined as some reusable standard steps.

2. The internal review of the test group focuses on

• Whether the description of the test case itself is clear and whether there is ambiguity;
• Whether to consider the execution efficiency of the test case. Often the steps in the test case are repeatedly executed, but the verification points are different, and the redundancy of the test design has caused low efficiency;
• Whether to follow up on requirements changes, covering all software requirements;
• Whether the exception process and exception test points are covered as much as possible.

3. Test case review check items

• Whether the test cases are written according to the template defined by the company;
• Whether the description of the test case itself is clear and whether there is ambiguity;
• Whether the content of the test case is correct and consistent with the requirement goal;
• Whether the expected result of the test case is definite and unique;
• Whether the operation steps should be consistent with the description;
• Does the test case cover all requirements;
• Whether there is redundancy in the test design;
• Whether the test case is executable;
• Whether to design test cases for user usage scenarios and business processes from the user level;
• Does the scenario test case cover the most complex business process;
• Whether the use case design includes positive and negative use cases;
• Whether the generation rules are indicated for the output items automatically generated by the system;
• Test cases should contain checks on intermediate and background data;
• Test cases should have correct names and numbers;
• Test cases should be marked with the priority of execution;
• Test cases include relevant configuration information: test environment, data, pre-test cases, user authorization, etc.;
• Each test case step should be <=15 Step;
• Automated test scripts must have comments (the comments should include: purpose, input, expected results, etc.);
• Are non-functional test requirements or non-testable requirements listed and explained in use cases

5. Use case review method

• online meeting
• offline meeting
• General OA communicates with relevant personnel

6. Use case review time

• After the test case is completed
• After the requirement document is submitted, before development and testing
• It is best to control the meeting time within 1 hour. If there are many contents, it can be reviewed multiple times

7. Use case review process

1. Preparation before the meeting

• The test case is written
• Notify the participants in advance, agree on the review time and reserve the meeting room
• Send the test cases to the participants in advance for review
• Arrive at the meeting room 5 minutes before the meeting, and open the test cases, requirements documents, etc.
• When there are many use cases, mark them in advance, give priority to the use cases with high priority, and try to distinguish the front-end and back-end use cases, so as to facilitate the review
• Organize your doubts together for easy inquiry

2. Meeting process

2.1 Method 1: Read the test cases one by one from top to bottom, from left to right.

The general process is like this.

• Advantages: explain one by one, comprehensive and careful
• Disadvantages: time-consuming, regardless of priority, reducing the attention of participants

2.2 Method 2: First review the use cases with complex functions, high priority, and many questions, and then review the function points with simple functions and low priority.

Use cases with high priority will be explained first, use cases with many doubts will be explained next, and function points with simple functions and low priority will be explained.

• Advantages: focus, high efficiency
• Disadvantages: The explanation is not comprehensive, and there may be neglected points

2.3 Meeting Notes

• During the review process, if the result cannot be determined after more than 5 minutes, it can be recorded and used as the focus of discussion and follow-up after the meeting.
• Try to be as clear as possible during the review process, and explain each function point in the most concise language.
• For ambiguous issues, it needs to be clearly confirmed with the product and development.
• During the review process, the participants may experience visual and auditory fatigue, and the speaker should focus on key points and important personnel.
• For the problems in the review process, mark them in time.
• Use case reviews are only for use cases, not for individual capabilities.

3. Summary after the meeting

3.1 After the use case review meeting, it is necessary to follow up and improve the problems in the review.

• Points that need to be supplemented and modified by the product manager need to be recorded on the requirements document and prototype diagram
• Supplement missing test points, correct wrong test points, and manage use cases

3.2 If required, complete the use case review document

3.3 Summary of Personal Meeting Behavior

7. Use case review end criteria

• During the review process, collect feedback information from relevant personnel (that is, a list of problem records), and update test cases on this basis until the review is passed.
• After the review, the test leader issues a test case review report to relevant personnel.
• The results of the review are approved and confirmed by the project manager

Note: According to the company's requirements, some companies do not require the use case review report to be completed, so a self-summary review can be performed.