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

one

During the interview, I often come up with a programming question about the requirements of a simple calculator, and then let me write a use case for this requirement. The topic looks very simple, but I can cover almost all the basic testing theories I want to know.

Today, I will also use this example to practice the value of testers participating in requirements review. "the requirements review concerns mentioned in.

For example, I am now in the role of the product, and the description of the requirements I give is as follows:

Now there is a PC client command line tool, this tool can receive three command line parameters, of which, the first two are numbers, the last one is the operator, the operator only supports addition, subtraction, multiplication and division, the function of the tool is to use the first two numbers to operate under the operator, and then output the results.

The following is a simulation of the requirements review for this requirement.

two

First, the discussion of the rationality of demand.

Test: "what is the calculator on the command line for? why not use the calculator that comes with the system?" "

Product: "well, at present is the demonstration, do not consider the user first, please ignore this problem." "

Test: why is it a command line tool? The controllability of the command line is too poor, so it is recommended to change it to GUI. "

Product: "this time is aimed at a specific Geek group, accustomed to command-line operation, and there are already many GUI implementation tools on the market." "

Test: "the first two are numbers, and the last is the operator, which is not in line with the operation habit. It is recommended to put the operator in the middle." "

Product: "well, let's go back and think about it." "

Test: "are you sure you only need to support addition, subtraction, multiplication and division?" Is the function too weak? "

Product: "this is the first iteration, and it will be expanded later according to the needs of users, so don't write it down in this place." "

After a simple discussion on the rationality of the requirements, the problem of the location of the requirements-parameters is changed, and at the same time, the developers consider the extensibility in advance when implementing the function. If these questions are raised in the testing phase, most of them may not move first, otherwise the code will have to be changed. If they are really changed, the workload of development and testing will increase accordingly. If you don't change it, it will increase the workload of the next iteration. In short, it will do you no harm to discuss the rationality of the requirements early.

three

Then there is a comprehensive discussion of the requirements.

Test: "what is the maximum supported Operand?" "

Product: "the maximum value of the floating point type is fine." Products that understand technology are good products. )

Test: "does the tool only do one operation after each run, or can it continue to receive new parameter input at the end of one operation?" "

Product: "the first version is not too complicated, it needs to be reexecuted every time, and only receives the input of parameters when it is executed directly." "

Test: "what is the separation between the three parameters?" "

Product: "spaces or commas, both are supported." "

Test: "there must be an explanation for this, otherwise the user will be foolishly confused." "

Product: "Yes, output a prompt for instructions if the parameter is in the wrong format." "

Test: "what is the error message if the parameter is missing?" "

Product: "prompt that the number of parameters you entered is incorrect, please enter it in the format of [Operand operator]. "

Test: "what is the error message if the parameter type is wrong?" "

Product: "prompted that the parameter type you entered is not supported, please re-enter it." "

Test: "this prompt is not clear, is it?" Parameter types are not supported, so which types are supported? Users will still be confused. "

Product: "then change, the parameter type you entered is incorrect, the Operand only supports floating point, the operator only supports +-* /, and the delimiter supports spaces and commas." "

Test: "what error message does it prompt if the divisor is zero?" "

Product: "prompt that the divisor you entered is zero, please re-enter it." "

Except for the problem of a main branch, the other belongs to the side branch, which is the supplement and improvement of the main branch, and it is also the place where people are most likely to ignore, and where the user environment is most prone to problems.

four

How's it going? For a requirement that can be solved with such a simple if statement, it is surprising that 12 valid questions can be asked. If these are raised during the testing process, consider each question from raising to product confirmation, then development and repair, and then test and verify, how much is the loss of this process? and if it is put forward in the requirements review stage, the development can consider the processing of various scenarios in advance in accordance with the established requirements. It greatly reduces the communication and rework costs caused by changes in demand.

Then, in the course of the interview, we will find that the code written by many people themselves will be full of loopholes by the test cases written later, such as the consideration that the divisor is zero. If we write use cases from the point of view of testing, many people can consider it, but 99% of people don't deal with it, and of course we don't rule out the simple implementation of some people during the interview. But it still illustrates the difference between development thinking and test thinking, so what I want to say is:

1. As a test, we try our best to lead by example in our requirements for development, so that we can better communicate with developers from the perspective of development.

two。 As a developer, 20% of the code implements and 80% of the code handles exceptions, so please don't wait for bug to come up to handle exceptions.

3. As a product, we should take into account all the places that may interact with the user, and the handling of details has always been the embodiment of the product foundation, which is why colored eggs are called colored eggs, so as not to turn them into smelly eggs as far as possible.

five

Okay, this time we will start with a simple requirement and talk about two concerns about requirements review. You can imagine that if it is a relatively large requirement, the test will ask a lot of questions, so you need to consider some strategic issues. For example, review in batches, each review to determine a reasonable granularity, easy for everyone to focus, but anyway. It is very important for testing to participate in requirements review.

Despite the simplicity of the above example, there may be some points that I haven't considered. If you have anything to add, please leave me a message.

This article was first posted 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.