1: Review process
A: Make the following preparations before starting
1. Determine the reason for review
2. Determine the time for review
3. Identify the participants in the review
4. Clarify the content of the review
5. Determine the end of the review criteria
6. At least one day in advance, the content that needs to be reviewed will be sent to the relevant personnel of the review meeting in the form of email. And indicate the time and place of the detailed review and the personnel involved in the compensation.
7. In the email, remind the relevant personnel of the review meeting to read the review content at least once, and record the related questions so that they can be raised at the review meeting.
8. The meeting host (usually a use case writer) should sort out relevant questions before the meeting so that they can be raised at the meeting.
B: Start review
1. Hold a review meeting. Participants gave comments and suggestions after the designer's explanation, and at the same time carried out a detailed review record.
2. Communicate with relevant personnel by general mail
3. General IM tools communicate directly with relevant personnel
4. Review according to the content of the review
2: Judging content
1. Whether the structural arrangement of the use case design is clear and reasonable, and whether it is conducive to efficient coverage of requirements.
2. Whether the priority arrangement is reasonable.
3. Whether to cover all the function points on the test requirements.
4. Whether the use case is well executable. For example, whether the prerequisites, execution steps, input data and expected results of the use case are clear and correct; whether there are obvious verification methods for the expected results.
5. Have redundant use cases been deleted?
6. Does it contain sufficient negative test cases? Fully defined, if the 2&8 rule is used here, it is four times the number of positive use cases. After all, in a robust software, 80% of the code is "protecting" 20% of the function implementation.
7. Whether to design test cases for user usage scenarios and usage processes from the user level.
8. Whether it is concise and reusable. For example, the highly repetitive steps or processes can be extracted and defined as some reusable standard steps.
3: Participating reviewers (here will be divided into multiple levels for review)
1. Department review, review involving all members of the testing department.
2. Company review, including project managers, requirements analysts, architecture designers, developers and testers.
3. Customer review, including the customer’s developers and testers. This situation is more common in outsourcing companies
1. Purpose of use case review The
test case review process specification mainly provides guidelines for the development of test case review work, and standardizes test case review management.
2. Test case review process content
2.1 Prerequisite: Testers have written a complete functional module test case or have completed all test cases;
2.2 Process input: A. Test case; B. Requirements specification;
2.3 Process output: A. List of problem records; B. Test case review report;
2.4 Participants in the review: project managers, test leaders, testers, requirements analysts, architecture designers, developers;
2.5 Evaluation method:
1) Convene an evaluation meeting. Participants give comments or suggestions after the test case writers explain, and record the review meeting minutes at the same time;
2) Communicate with relevant personnel through emails and timely communication tools.
No matter which method is adopted, the relevant documents of the test cases that need to be reviewed should be emailed to the relevant personnel participating in the review in advance, and the relevant personnel participating in the review should be reminded to review the review content before the review. And record related issues so that they can be raised at the review meeting to save communication costs.
2.6 Checklist for review use cases:
1) Whether the test cases are written in accordance with the company-defined template;
2) Whether the description of the test case itself is clear and whether there is ambiguity;
3) Whether the content of the test case is correct and whether it is consistent with the requirements and objectives Consistent;
4) Whether the expected result of the test case is certain and unique;
5) Whether the operation steps should be consistent with the description;
6) Whether the test case covers all requirements;
7) Whether the test design is redundant;
8) Testing Whether the use case is executable;
9) Whether to design test cases for user scenarios and business processes from the user level;
10) Whether the scenario test cases cover the most complex business processes;
11) Whether the use case design includes positive and negative use cases ;
12) the output item is automatically generated by the system indicate whether the generation rules;
13) of the test should include intermediate inspection and background data;
14) test should be the correct name and ID;
15) to be marked test Priority of execution;
16) Test cases include relevant configuration information: test environment, data, pre-test cases, user authorization, etc.;
17) Each test case step should be <=15 Step;
18) The automated test script must have comments (comments should include : Purpose, input, expected results, etc.);
19) Are non-functional test requirements or untestable requirements listed and explained in the use case?
2.7 Exit criteria:
1) Collect the feedback information of relevant personnel during the review process (ie, the problem record list), and update the test cases on this basis until the review is passed;
2) After the review, the person in charge of the test will issue a test case review report To relevant personnel;
3) The review results are approved by the project manager.
2.8 Control mechanism: When
adopting the review meeting, the host should try to grasp the progress of the meeting and try to complete the review work on time and effectively;
Annex 1: List of problem records Annex 2: Test case review report
What is the significance of test case review: Test cases must meet product requirements, but product functions are developed and written, and the logic of development and implementation needs to be reviewed and communicated to avoid unclear logic points; it can improve the correctness of test cases and improve test efficiency; Improve the coverage of test cases and find bugs better.
3. Use case review time
For agile development projects, it is recommended to control it within half an hour.
If you think that the requirements are complicated and there are too many function points to cover in half an hour, then it is recommended that you prioritize the function points, review the use cases with high priority first, and then review the use cases with many questions, and finally use cases with simple functions. Take it briefly. Always remember the review goal of our use case, not just a formality.
Fourth, the form of use case review
1. Control test cases, read from top to bottom, from left to right, one by one.
This is the current practice of many companies. If you have done this before, I believe you may not like this method because it is time-consuming, regardless of priority, and the enthusiasm and attention of the participants gradually decreases, and the efficiency of the entire use case review is low. , As the host, I also talked dry and dry, with half the effort.
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.
In the review process, there will be no conclusions for a while, which can be recorded as the focus of discussion and follow-up after the meeting.
This approach has many advantages. At the beginning of the review, everyone’s attention and enthusiasm are high. During this period of time, there are difficult and questionable issues to be discussed, and it is efficient. Do the most important things first.
In addition, the entire review meeting has clear priorities, with climax and slower, which can achieve our review goals more efficiently.
5. Formal review
There are several details that need to be paid attention to in the formal review process. If you have done it all, then you can say that the entire review is successful and valuable.
1. The review should be carried out according to the priority of the use case and the complexity of the function;
2. Try to do as much as possible during the review process, with clear thinking, and use the most concise language to explain each function point;
3. Questions that cannot be determined for more than 5 minutes are reserved for discussion and follow-up after the meeting.
6. What needs to be done after the review?
It's not that the review will be over when the review meeting is over. In fact, this is only half done for the entire use case review.
After the review is over, the test cases are sorted out as soon as possible, and the revised content is rearranged and supplemented.
For the unconfirmed content at the meeting, follow up after the meeting until the result is confirmed.
Where you are asking, let’s make a simple use case review meeting summary (such as which function points have been revised and which have been completed? Which module functions have been changed? Which functions have been postponed to the next issue? etc.),
This summary is a summary of the entire use case review work for yourself, and it is also important to share information with other members of the project team at the same time.
Software testing exchange group: 785128166
WeChat public account: Programmer Erhei; After paying attention, you can receive a set of video resources for free; explain in detail: python automated testing, web automation, interface automation, mobile terminal automation, interview experience and other related content, the value of learning resources depends on you Action, don’t be a "collector"
Here is a collection of selected dry goods articles for functional testing: