Infeasible Test Requirements

TL;DR

In the previous post, we explained the coverage criterion. Today we move on to the problem of Infeasible Test Requirements. We will introduce you to software testing based on the remarkable book,  Introduction To Software Testing by Paul Ammann and Jeff Offutt.

Infeasible

[adjective] – not possible to do easily or conveniently; impracticable.

Software Testers like to say that it is not possible to test everything. The right statement is that some test requirements are impractical.

The problem with infeasible test requirements is that they are quite common.

Example

Let’s review our sanitizer example. We have the following test requirements marked with T R:

T R = { type = “surface”, type = “electronics”, type = “hands” }

T R = { color = “transparent” }

We also concluded that criterion C1 sanitizer type subsumes criterion C2 sanitizer color.

Let’s introduce the interaction criterion. We first divide our sanitizers into

T R = { origin = “human”, origin = “object” }.

We have one human origin, hands, and two object origins, surface and electronic.

Our interaction criterion could be let’s combine each type with some other type with the same origin. Test Requirement to try type in human origin group with some other type in the same human group is INFEASIBLE. We only have one human origin group member.

What we could do is to replace each of the infeasible test requirements from the interactional criterion. Let’s combine each type with some other type with the same origin with the corresponding test requirement from the test criterion sanitizer type. In that case, we would test hand sanitizer by themself.

Remember

Infeasible test requirements are not impossible and to have them is quite common.