Unsupported in requirement definition-possible test blind area

Unsupported in requirement definition-possible test blind area

A product must have its system requirements or specifications, defined in the design instructions are not supported, not implemented features or features, and sometimes may be a blind spot in the test design.

(Example: Requirements define some properties of product products for--XX system does not support Win7 system, XX system only support IE kernel browser, xx system and YY system earlier version incompatible. ）

Instance:

A platform product, starting from Version1, a few years down has been iterative to Version4, during the access to n a variety of terminal products, peripheral products, databases, Web servers. Because the compatibility is too large, the product branches are also dense, resulting in maintenance and testing is very time-consuming. With the opportunity of major technical updates, platform products developed the VERSION5 version, the early compatibility after detailed discussion and design, agreed to support only a few major branches of the terminal, peripheral products.

This version of the plan for the joy of the Big Ben, both inside and outside the team said after the time saving. But unfortunately, when the release was beta-tested, there was a fatal problem with platform crashes.

Troubleshooting is a clearly unsupported earlier version of the device, access to the platform, resulting in platform anomalies. From the point of view of test design, this is the place of omission. The product is clearly defined as unsupported and does not imply that such scenarios are not considered in the test. According to the test design of boundary value, this kind of explicitly unsupported project can also be understood as the boundary value of n+1.

Access "explicitly unsupported" devices, and then you can verify many items:

1, compatible with fault tolerance, both sides of the system is abnormal/crash/restart.

2, design-friendly: whether there are human prompts-such as the version is too old, please upgrade the new version.

3, Design Rigor: direct prompt prohibition of access.

From the point of view of product design, the protection of compatibility is not well designed, it is definitely a design omission, but the test is not able to design the scene in time to verify the problem, the main responsibility is in the test design.

This is also the test design need to pay attention to the link.

The specification is clear, XXX function is not supported, or XXX version is not compatible, only support XX system, xx browser and so on. These do not mean that tests can not be tested. This is the obvious robustness and boundary value protection test.

But things have one and the same two sides, do not consider is wrong, but also do not fall into the excessive design of the horn inside.

Or the above example--XX system does not support Win7 before the system, then in the test design, there is no need to put XP, 98, Vista, 2000 are installed, for compatibility testing? In the same vein, for example, an Android app that explicitly doesn't support a previous version of 4, does it have to install the previous system for compatibility testing?

In terms of test design and input-output realities, the former (before Win7) is almost certainly not tested, and the latter (ANDROID4) may not be tested or tested.

This is a general classification of such test designs, the nature of the product, the customer, the coverage, and so on, which need to be considered comprehensively. According to the test design from less to more to sort, as follows:

First, operating system compatibility.

You can test on the systems supported by the requirements definition and do not require too much consideration for unsupported products.

First of all, since the product dare to define, it means that the product itself is not QQ, WPS, this requires a full version of the coverage of a very wide range of products, but may be a specific user, a specific environment, or the use of targeted customers accurate products. So there is not much to be needed, over-testing. such as Overwatch, you are excited to install, found the card of a mess, you will not scold Blizzard products rotten, will only blame themselves did not see the software running system requirements, and then to buy the video card.

Second, the Web client compatibility with the browser.

Similarly, since the design of the product, there must be a reason, if the user is the full coverage type, you design the product said does not support Chorme browser, may be similar products directly eliminated. But if it is to the company's internal OA system, ERP system, etc., can be done through administrative requirements, only need to be in a certain kernel browser perfect implementation can.

So the test design, is also a lightweight test design, to find several other kernel browser, probably installed to use, to see if there will be prompted "This product supports XX browser", whether there will be a system exception, resulting in browser crashes, or the operating system is not responding, it can be considered to achieve the design purposes.

Third, the app to the mobile phone operating system compatibility.

In the mobile phone operating system, can be clearly incompatible, but because the carrier is not controllable, this part still needs to be tested. Similarly, the online simulation cloud is very much, and does not need solid machine brush ROM, input and output or positive.

Iv. compatibility between their products.

For example, some industry products, such as supermarket scanning code billing system, residential building alarm system, from the platform, to the terminal, from software to equipment, are doing their own, then this upgrade compatibility, but the product design and test design focus.

Iterations of the new product can clearly not support an old product/old version, but give a friendly hint, or clear solution.

So this kind of test, often is xy of a table, or XYZ of the table, test the past, tick the fork, tedious, but it is important.

This article mainly describes a possible blind area of the test design-features/features that are explicitly not supported by the specification. But it also made clear that you should not overdo it, otherwise it would be a waste of cost and project time.

Test design is actually a complex model of weighted coefficients, and products, customers, use, frequency, defect repair costs, industry, the company a lot of factors related, must not generalize.

This article is from the "Willow" blog, please be sure to keep this source http://eilfei2000.blog.51cto.com/2956473/1851623

Unsupported in requirement definition-possible test blind area