Five myths about test case design ...

The non-standard of the domestic software testing process, attention to development and contempt of the phenomenon of testing still exist, the importance of software testing, testing methods and testing process, there are many inappropriate understanding, which will further affect the development of software testing activities, and hinder the improvement of software testing quality.

The following list of test case design of the five major misunderstandings, and made a corresponding analysis and interpretation, I hope to help everyone.

The first big mistake: the use case of the flaw found is a good use case

First of all to affirm that this sentence is very reasonable, but I found a lot of people have distorted the original intention of this sentence, to design the discovery of "difficult to find defects" and fell into the blind one-sided, forget the purpose of testing, which is very scary.

I tend to recognize the test case as a set, and evaluate it only for the collection of test cases, and the test itself is a "v&v" activity.

The test needs to ensure the following two points:

* The program did what it should do

* The program doesn't do what it shouldn't

As a result, test cases that are based on test implementations must be fully covered by the test requirements, rather than being judged for a single test case.

The second big misunderstanding: the test should be sufficient to force the detailed

The test case should record all the operation information in detail, so that a person without contact with the system can also be tested;

Do not know whether there are companies in the country really do this, or, do not know that there are no domestic companies can be each test case is written so detailed. In my test experience, there has been a lot of hesitation about the detail and complexity of the test case description.

Write too simple, except that no one can execute, write too detailed, consumption in the test case maintenance (remember, test cases are dynamic, once the test environment, requirements, design, implementation changes, test cases need to change accordingly) on the time is really amazing, At present, most of the domestic software companies have insufficient testing resources, I am afraid it is difficult to achieve.

But I can meet some of these bosses or the project leader, or even the test engineer itself, regardless of the actual resource situation, be sure to write "people without contact with the system can also be tested" use cases.

Before we discuss this issue, we can consider the purpose of the test first. The purpose of the test is to find the defects in the program as much as possible, and the test activity itself can be considered as a project, as well as to achieve the goal under the given resource conditions, according to my personal experience, most of the domestic software companies in the testing of resources are not enough, So we have to clearly test the goals in the test planning phase, all around the target of the test.

In addition to constraints on resources, the level of detail of the test case needs to be determined as needed. If the test case performer, test case designer, test activity related to the system is very deep understanding of the test case is not necessary to be too detailed, the role of the document is to communicate, as long as the purpose of communication can be achieved OK.

In my project as a Test manager, in the test planning phase, generally give the test design time of 30%-40%, Test design engineers can determine the details of the use case according to the needs of the project, in the test case review phase by the relevant people involved in the review.

The third big mistake: test case design is a once and for all thing

This sentence here, I think no one will recognize, but in the actual situation, but often can find the shadow of this idea. I have been involved in a project where software requirements and designs have been changed many times, but the test cases have not been modified.

The direct result is that the newly added test engineer is overwhelmed by the execution of the test case, and the indirect consequence is that the test case becomes a pile of waste paper, and the developer is dismissive of the testers after having been interrupted by several invalid bug reports.

This example may be extreme, but the fact that the test case is not synchronized with the requirements and design is not uncommon in the actual development process, and the test case document is a "live" document, which should be borne in mind by the test engineer.

The fourth big mistake: test cases should not contain actual data

Test cases are "a set of inputs, execution conditions, expected results," and undoubtedly should include clear input data and expected output, and the use cases without test data are only instructive and not enforceable.

Of course, the test case contains the input data will bring maintenance, synchronization with the test environment, and so on, in this, "Effective software Test" provides detailed test cases, test data maintenance methods, can be consulted.

The big mistake: The test case does not need obvious verification means

I've seen many test cases written by test engineers, the "expected output" is described only as visible behavior of the program, in fact, the meaning of "expected result" is not just the visible behavior of the program.

For example, to an ordering system, enter the order data, click on the "OK" button, the system prompts "order Success", this is not a complete use case.

is not the system output of "order Success" should be our only means of verification. Obviously not.

The success of the order also needs to see if the corresponding data records are updated, so in such a case, you should also include an explicit validation of the test results: Execute the query in the database query, to see whether the query results are consistent with the expected.