Software testing for overly designed things

Too much, this is an ancient "Analects of Confucius" in an idiom, do it as if not enough to do the same. In the software testing industry there is also the situation of excessive testing, today I would like to swim a fish to talk about my understanding of the excessive testing.

Very detailed requirements documents can lead to a surge in maintenance costs

There have been several very representative PRD (product requirement document abbreviations, i.e. products requirements documentation) in the projects I have experienced:

1, a very detailed document to define a link is the new open a tab or in the original tab open, tell you all you want to know the information;

2, contains the product main function process document, will take the flowchart to assist the explanation, will not be too detailed, the detail content more must through the exchange and the discussion obtains;

3, an e-mail description or directly several people discuss the decision.

Especially for Internet projects, with frequent changes in demand, demand information is huge, for PM (product manager), the time required to complete a very detailed document does not say, each requirement change or review of the demand vulnerability needs to be updated to the PRD, for testers, need to read PRD changes in the part, and detailed requirements require more detailed use cases to cover, whether there is a need for such detailed documentation. For the Internet project can maintain a year is very little, we need to consider the document is not tired.

Detailed test sessions drag us down.

My point of view has always been to uphold a benchmark to ask myself and the rest of the team to write use cases: let people who do not know how to do business can also be used to execute use cases. And in the later part of the time, the use case was so painful to maintain, it takes a lot of time to update the detailed test steps and results each time, and it's very rare for a person unfamiliar with the business to execute these use cases, even if the new one comes to look at the use case, and still asks the detailed business multiple times, Discover or PRD look at more system more logical regulation, can understand business content more quickly. After all, looking at the use case, we seem to have executed 40, 50 use cases are still in a function, simply can not be linked with other functions, the business is familiar with how much of the obstacles ah. I think from macro to micro to macro is the right way. And for testing skills, the need for mentoring, and not from the use case to master too much, in addition to the careful consideration of the problem.

There was also an excessive maintenance in the directory where the use case was maintained, for example, there are ab two pages have a child function C, each regression test needs to the AB two page function on the return to avoid omission, the C for the use cases are copy to ab two directory, then each update maintenance also need to maintain a number of copies, Duplication of work is conceivable.

How to let the use case not drag us.

The title can be described without steps and results, too much content is not put down when there are detailed steps and results, can be attached to the form of the upload of Excel form a number of use cases, not for the specification and specification, and use cases are to test the executive staff, not to let the new understanding of the business and exist. The catalog results are too bloated to be optimized, for example, C has a special directory storage use case, AB set up a directory only to explain the function of C, such as Linux under the soft link, the original way even hard links, it can not sync update (PS. We are using the QC management use case).

Overly-designed use cases can reduce our efficiency

Have you ever encountered a situation where you have three input boxes, but there is no strong logical association, but they are required to determine whether the successful submission, if the design of 8 case to cover is required to fill the condition is enough to be assured that if there are more input boxes we will collapse.

Another situation, such as the need to call a third party to share, say Weibo, whether we need to cover the content of special characters can be successfully shared, long text content can be successfully shared.

The above two are obviously excessive design, we absolutely do not need for such equivalence class boundary value case to use the judgment table way to complete, like this kind of very simple page control, should write good unified test case set, different is the character length limit. Nor do we need to put our minds to testing third-party software. Of course, there may be many similar cases of excessive design in the work, the work experience of the people can be summed up in the past we more effective testing ideas.

......

Article Source: 51Testing Software Test Network http://www.51testing.com/html/10/n-848410.html