Shulou(Shulou.com)06/03 Report--

Students who have studied testing theory must know that the first step for testers to participate in the project is requirements review, but many test students report that they seldom participate in requirements review and seldom call testers to participate in requirements meetings.

I think on the one hand, it may be a matter of the coordination of the various roles in the process, on the other hand, it may be because the test does not reflect the value of participation in the review process.

For the first possibility, the test needs to actively communicate with the product, expressing their willingness to participate in the requirements review on the one hand, and requiring them to call on the test during the requirements review on the other hand.

For the second possibility, testers need to improve themselves. Why do you say that? I have attended several requirements review meetings, and I found that the product was there to talk about the requirements, and the developer occasionally raised some technical implementation details. The test was just there, and after the meeting was over, we could do what we had to do when we went back to the meeting. Since there is no value for us to test and participate in the requirements review, how can the product remember to call us during the review?

Finally to the topic we are going to talk about today, what value can we contribute to participating in the requirements review as a test? Now let me express my point of view.

1. The role of requirements review

Before answering the above questions, let's take a look at what the requirements review is for. No matter what the book says, in my experience, requirements review has two functions:

1. Detailed design of requirements for synchronized products

two。 Collect all kinds of feedback on requirements

For requirements design, the product must be initiated and responsible, so as a tester to participate in the requirements review, the focus is on the second point, the feedback on the requirements.

two。 The form of requirements review

At first, I mentioned that some students said that they had not participated in the demand review, and some of them were said by the interviewees, but after asking them in detail, I knew that he was talking about the question of form.

For example, the requirement review that he understands is that we all work together to set up a conference room, where products talk about requirements, development and testing, but the actual situation is that as soon as the product throws the requirements into the group, everyone starts to talk about it. Or the product comes directly over and communicates face-to-face at the development and testing station, even if it is done. Well, I say this is also a requirement review, and the form is not important. What matters is the purpose and effect of doing it.

3. Test whether you need to participate in the requirements review

Nonsense, it must be absolutely necessary. Just from the perspective of synchronous requirements design, the effect of synchronizing requirements face-to-face is certainly much better than that of text communication. In fact, the most important thing is the feedback put forward by the test in the requirements review, which is the most valuable, so I will mainly talk about which aspects are mainly reflected in the value of testing for requirements feedback.

4. The rationality of demand in demand Review

The demand is reasonable, which is one of the places where the most products are developed and tested.

Isn't it too disturbing for users to play such a big box? I suggest reducing it by 1/2.

Uninstall a software, but also confirm so many times, users should be bored, right? I suggest you click the uninstall button and finish it.

There is already a lot of content on the home page, will it be effective to add another one? Wouldn't it be better to be a little more concise? I suggest that there are no more than five items on one screen.

This operation flow is a little anti-human, how is the interaction designed? I suggest that the main operation can be achieved in one step, and the minor operation can be completed within three steps.

Well, although the final decision may be the final decision of the product, but as a seed user, it is still necessary to make suggestions, especially in some places where there is no final conclusion on the products, and the opinions are very likely to be adopted at this time. If the suggestions are adopted more times, their own suggestions will be paid more attention to, then the right to speak will be enhanced accordingly.

However, in fact, many people will not refute the rationality of the demand. at the worst, they will complain in their hearts that "such a stupid design can be figured out at a loss." maybe this has something to do with the company environment, but if they really have any good suggestions, it is suggested to find an opportunity to put it forward. After all, we are testing, and the quality of user experience is also within the scope of quality.

5. Requirement comprehensiveness of requirements review

The rationality of the requirements mentioned above requires us to consider the problem from the point of view of the users. Not everyone can do it, which is understandable, but the comprehensiveness of the requirements is indeed an issue that must be considered in the requirements review. This is not only for product design, but also for development and implementation logic.

If the user logs in and times out, how will the product be displayed?

If the user enters data within the non-specified range, is there any exception handling logically? how to tell the user?

If the user does not turn off the phone for a long time, is there a logical problem and how to deal with it?

What will happen if multiple users log in at the same time?

What will the product do if the system resumes after hibernation?

For this part of the content, mostly for the coverage of usage scenarios, when many products consider the requirements, they only cover the main operation branches of regular users, while the consideration of abnormal cases is relatively less, for testing, the consideration of exception scenarios is our strength, so we should confirm the handling of various exception scenarios with the product as much as possible in the requirements review stage. It can greatly avoid being reworked after problems occur in the testing process.

Well, long-winded said so much, I hope it will be helpful to everyone, if there is any doubt, welcome to leave a message to communicate.

This article is originally published on the official account "sylan215", ten years to test the original practical information of veterans, follow me, rise posture!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.