What value should testers play in requirements review? Two minutes will stop you from being stupid

Preface

Hello , I'm testing caituotuo .

Chat with friends the other day , Talking about Requirements Review , As a tester , What should we do at the requirements review meeting ？

Remember to participate in the requirements review for the first time , Silly past sitting , Then listen to others for a long time , I'm at a loss 、 A face of meng , After the meeting, I spent a lot of time looking at the needs , When you wait for the test, you may not understand the requirements ……

So here comes the question . How can we make requirements review more efficient ？ As a tester, how to play value in it ？

The first person to participate in the review may be the product 、 Development 、 test , Time is generally controlled at 1 In hours or so , If it's too long , For example, two or three hours may not be very efficient , If too short , For slightly larger requirements, some detailed points may not be taken into account .

Requirements review

Before the meeting ：

Before conducting the requirements review , The product manager will usually give the demand related information , For example, our company will be built by the product manager jira single , The customer's background is attached to the list 、 customer demand 、 Product plan 、PRD、 Prototype drawings, etc . We need to read the relevant documents in advance , Deep understanding of needs , For the points in question, mark them in advance , Then actively participate in the meeting during the meeting , Raise questions . In addition to focusing on functional requirements , You also need to focus on data types 、 Interface definition 、 Performance requirements 、 Safety and so on , This is assessed on a business by business basis , For example, our company is engaged in electronic contract business , Will consider frequent requests for file thumbnails 、 Whether too many seals will lead to performance problems . At the same time, we need to consider some hidden needs .

In the meeting ：

1. Don't play with your mobile phone or do other things at the meeting when you need clarification , Because if you don't understand the needs deeply , The work related to the later test is difficult to carry out . Such as ： Can't write test cases correctly , Can't find the test point , Business related knowledge cannot be strung together .
2. Unreasonable product design in demand 、 It's hard to understand. 、 There's something wrong with logic 、 And places that may affect the original function , For these points, we need to raise questions for clarification , So as to promote product modification , Finally come to an agreement .
3. Points in requirements that are not quantified , for example ： The type of field involved in a function 、 Length and rules , Such as ： The title field type is normal text , The length is 100 Characters 、 The mobile phone number field should conform to the specification , The first is 1,11 Digit number . Why do we need to quantify ？ Because only after quantification , It is conducive to the preparation of subsequent test cases , Testing is possible with equivalence classes 、 Use case design based on boundary value , Development can carry out the design of some database fields （ Such as varchar（11）、int、bigint）.
4. Think about the test points in the requirements , Let the product manager explain what affects our testing , For example, how to deal with this abnormal situation ？ How many states ？ How to transform between States ？ In short, the product manager should give instructions on the places that affect our testing , This clears the way for us to write test designs and test cases later .

After the meeting ：

1. After the review , We need to sort out some places to be confirmed and put them out .
2. After discussion at the review meeting , There may be changes in some requirements , At this time, we need to make the product the latest PRD Sort it out completely and send it again , Then confirm the modification .

results

After the above requirements review , What will you get ？

1. Comply with the principle of software testing ,“ Testing should be done as soon as possible , It's best to get involved in the demand phase , Because the most serious mistake is that the system can not meet the needs of users ”, So as to help the whole team avoid many mistakes in the early stage of the product .
2. Fully understand the tested requirements , Deeply familiar with the tested business , For the follow-up test work 、 Clearing the way for writing test cases .