Shulou(Shulou.com)06/03 Report--

Not supported in requirement definition--possible blind spot

A product must have its system requirements or specifications, clearly defined in the design description does not support, do not implement the function or feature, sometimes may also be a blind spot in the test design.

(For example, some attributes of the product defined by the requirements are-XX system does not support systems before Win7, XX system only supports IE kernel browser, XX system is incompatible with earlier versions of YY system.)

Examples:

A certain platform product, starting from Version1, has been iterated to Version4 in a few years, during which more than N kinds of terminal products, peripheral products, databases and Web servers have been connected. Because compatibility is too large, product branching is also dense, resulting in maintenance and testing are very time-consuming. Taking advantage of the opportunity of major technology updates, the platform product developed Version5, which was discussed and designed in detail for early compatibility, and agreed to support only a few major branches of terminals and peripheral products.

This version of the plan is big and popular, and both inside and outside the team say it will save time and effort in the future. Unfortunately, during beta testing, a fatal platform crash occurred.

After investigation, it was an early version device that was clearly not supported. It was connected to the platform, resulting in an abnormality of the platform. From a test design perspective, that's where it misses the mark. Just because the product explicitly defines no support does not mean that such scenarios should not be considered in testing. According to the boundary value test design, this explicitly unsupported item can also be understood as the boundary value of N+1.

Plug in an "explicitly unsupported" device and you can verify a lot of things:

1. Fault tolerance compatibility, whether there are exceptions/crashes/restarts in both systems.

2. Design friendliness: whether there are humanized tips-for example, the version is too old, please upgrade the new version.

3. Design rigor: Direct prompt prohibits access.

From the point of view of product design, compatibility protection is not well designed, it must be a design omission, but the test failed to design scenarios to verify this problem in time, and the main responsibility is still in the test design.

This is also a test design that needs attention.

It is clearly stated in the specification that XXX function is not supported, or XXX version is incompatible, only XX system, XX browser, etc. are supported. This does not mean that testing should not be done. This is the obvious robustness and boundary value protection test.

But things have two sides, and it's wrong not to think about them, but don't get caught up in over-designed corners.

Or the example above-XX system does not support Win7 before the system, then in the test design, is it necessary to XP, 98, Vista, 2000 are installed, compatibility testing? Similarly, for example, Android system App, clearly do not support versions before 4, then do you also want to install the previous system, compatibility testing?

From the actual situation of test design and input and output, the former (before win 7) is almost certainly not tested, and the latter (before Android4) may not be tested or may be tested.

This is a general classification of such test design, considering the nature of the product, customers, coverage, etc. Ordered by test design from least to most, as follows:

·Operating system compatibility.

Testing can be done on systems that are supported by the requirements definition without having to think too much about unsupported products.

First of all, since the product dares to define it like this, it means that the product itself is not a product with a wide coverage that requires full version compatibility, such as QQ and WPS, but a product that may be specific to a specific user, a specific environment, or a precise target customer. So there's no need to overtest. For example, Overwatch Pioneer, you are excited to install, found that the card is a mess, you will not scold Blizzard products bad, will only blame themselves did not see the software running system requirements, and then go to buy their own graphics card.

Web client compatibility with browsers.

Similarly, since the product is designed like this, there must be a reason. If the user is a full-coverage type, you may be directly eliminated by similar products if you design a product that does not support the Chrome browser. However, if it is for the company's internal OA system, ERP system, etc., it can be done through administrative requirements, only need to be perfectly implemented under a certain kernel browser.

So test design, is also lightweight test design, find a few other kernel browsers, roughly install and use, see if there will be a prompt "this product supports XX browser", whether there will be system exceptions, resulting in browser crash, or operating system no response, can be considered to achieve the design purpose.

Third, the compatibility of the App with the mobile phone operating system.

On the mobile phone operating system, it can be clearly incompatible, but because of the uncontrollable nature of the carrier, this part still needs to be tested. Similarly, there are quite a lot of simulation clouds on the Internet now, and there is no need for physical machines to brush Rom. The input and output are still positive.

Compatibility between products.

For example, some industry products, such as supermarket code scanning billing system, community building alarm system, etc., from platform to terminal, from software to equipment, are all made by themselves, then this upgrade compatibility, instead, is the focus of product design and test design.

Iterations of new products may explicitly not support an old product/version, but friendly hints or explicit solutions are given.

Therefore, this kind of test is often a table of XY, or XYZ, one by one test past, check and cross, boring and tedious, but important.

This paper mainly describes a possible blind spot in test design-functions/features that are explicitly not supported by specifications. But it also makes it clear not to over-design, otherwise it will waste cost and project time.

Test design is actually a complex weighted model, and product, customer, use mode, frequency, defect repair cost, industry, company many factors related, must not be generalized.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.