Agile Testing (9) Acceptance test Design

Acceptance Test Design

one case of the traditional test design is this :

Although the traditional test design is very comprehensive, but there are many defects:

1. The test case is very detailed, resulting in a special long design document;

2. Test case, the test steps may exist a large number of redundancy and duplication;

3. The test case has no structure, some cases have the order of precedence or dependence, can not be intuitively displayed;

4. It takes a lot of time to write, review, read and modify these test case;

The use of this test design, although theoretically very safe, not easy to create two semantic, but the phenomenon is often the case: RD does not follow the test design self-test, a lot of bugs .

question: Rd Why not test design by testing?

think: really is rd too lazy?

Research:

A, the document is too long, every time to review the time to sleep, not to mention the self-test of it;

b, the case is not clear, it is difficult to see;

c, no time;

Summary: It seems that, in addition to objective reasons C, need to look for the reason from QA themselves.

Improved:

1, to story for the granularity of writing test design (each story a file);

Features: Each self measurement is small, not easy to annoy.

2, the tree structure organization case,story number and the name is the root, in turn is the function block, the child function block, the function point. Each path from the root to the leaf node is a test case;

Features: Logical clarity, RD looks simple and straightforward.

3, each case can be marked when executed;

Features: Do not omit, do not walk long way;

First, give an example of the previous two points:

Demand:

More Wonderful content: http://www.bianceng.cnhttp://www.bianceng.cn/Programming/project/

The user enters the user name, the password and the authentication code, registers the system.
The following steps are implemented:
Step one: In the browser's address bar to enter the address http://xxx.xxxx.com, the browser to open the system's user login page as shown in the picture. The user name, password, and authentication code is empty, and the verification Code prompt area automatically generates the verification code.

Step two: Input user name, password and authentication code, click the "Login" button, the system in order to verify the user name, password and authentication code. If the user name is misplaced, prompt "username error", if the password is wrong, prompt "User password error", and if the Authenticode is wrong, prompt "Authenticode error". The user name is retained after validation errors, and other items are emptied. If validation passes, it is logged into the system. The password bar is displayed in the code display mode.

Case:

The image above is not complete, please right-click the picture address.

Click on the Login button section above, similar to pseudocode, while the other part is the list of function points, so that it structured. This will be very clear and concise reading.

Imagine, the above case, if the traditional way to write, the relationship between the case is difficult to see clearly, will produce a lot of duplicate input steps, 15 case, probably need 5+ page word, and this is just a landing .

Note: This test design is no longer just a way of thinking about your test execution, it needs to be complete, detailed, and unambiguous to ensure that Rd can correctly follow the test designer's vision for code implementation , Automation , and Case execution , otherwise there is a risk.

Disadvantages:

1. Text too little, no specific input and output, easy to produce two semantic;

2. There is no particular precise output, the criteria passed may be in the beholder;

But is the traditional way of writing case,rd really willing to read a word? The above two questions can be solved by continuous running-in (writing as far as possible in RD comfort) and necessary communication (communication in case of problems encountered).