A few tips and experiences in designing and executing test cases-testing career development

Colleagues wrote, summed up their usual ideas about R software testing, to share.

1. Avoid vague terms

Do not appear in the case of ambiguous language, if there is no way to grasp some of the results, you can mark it out, find time to confirm, but can not use the language of generalization. Imagine if the person who designed the case is not clear, then how can the person who runs it know what the result is right, and what result may have a problem? (The test of the people to report running case of the think of Chengdu is a robot, only step-by-step)

2, grasp the depth and breadth

The design case does not directly repeat the contents of the Task/spec, as the Task/spec often describes the most common and basic scenarios, however, the test guarantees these conditions, only the basic test, for a function of up to 20% coverage. Many scenarios require a combination of experience and a functional interleaving to identify the problem. So how to grasp the depth and breadth of the test, is to rely on the accumulation of ordinary people and thinking. Sometimes when you find a heavyweight bug in a particular scenario, you're sure to be happy, and that's the tester's sense of accomplishment, although we can't look at our code as a function of joy, as developers do.

3, the initiative of testing

The work of software testing does not have the same amount of measurement as any other work, but also needs the subjective initiative of testers. The same 100 case,a may find only one bug, while B can find 4 bugs. We can't say a. A does not work well, can only say that A's test initiative and sensitivity is not very strong.

4, do not expect a lot of bugs found in the case

In some areas of testing, the team that designed the case was absolutely bull if the number of bugs found in cases reached 30% of the total number of bugs found. The most valuable of all in the test is experience testing and exploratory testing.

5. Testing and development are complementary

The goal of testing and development is consistent, is to provide customers with high quality products, so there is no opposition between the two. Although we test to some extent, sometimes play a role as a surveyor, I have also done development, said that the real sometimes hate testers, think they are in trouble, but testers do not forget to find fault is our work and responsibility, and not unreasonable. Developing and perfecting the code also requires testers to provide test results to prove their perfection. The test is to give the customer information, give the team confidence, let the product rest assured work.

This article is reproduced from the 51testing Software test network, see more: http://www.51testing.com