# Boundary Value Analysis: Why would you test valid values inside the boundary?

I can't understand why to use two values inside the boundary when using Boundary Value Analysis. For instance, suppose a program has the requirement: Values between 1 and 100 are true, while all other values are false.

```func calc(x): if (x >= 1 and x <= 100): return True else: return False```

A lot of books (Pressman, for instance) say you have to use the inputs 0, 1, 2, 99, 100 and 101 to test such a program.

So, my question is: Why use the inputs '2' and '99'? I tried to make a program with a fault such that the test case set (0, 1, 2, 99, 100 and 101) exposes a failure and the test case set (0, 1, 100, 101) does not expose it, but I can't make such program.

Could you make such program? If not, it is a waste of resources to create redundant test cases '2' and '99'.

• "I tried to make a program with a fault such that the test case set (0, 1, 2, 99, 100 and 101) exposes a failure and the test case set (0, 1, 100, 101) does not expose it, but I can't make such program." - you haven't tried hard enough. If (x == 2) return false. Oct 10 '17 at 1:01
• @JoeStrazzere Can you please explain how x=2 is giving false for above program? Oct 10 '17 at 9:29
• @aLearner - the OP wrote "could you make such program?" I just did. In Black Box testing, you don't read the code. Imagine a program that had what I wrote in it. Oct 10 '17 at 11:28
• @JoeStrazzere not quite right, since 0 and 101 also need to return false. See my answer ;) Oct 10 '17 at 13:20

In your example, yes, it might be overkill if you are performing white-box testing. However, if you couldn't read or didn't have access to the code (i.e. black-box testing), these tests would be very useful to make sure, for example, that the implementation didn't look like:

``````func calc(x):
if (x == 1 or x == 100):
return True
else:
return False
``````

So it really depends on the bigger picture of how you are designing your tests. By all means, if you're performing white-box testing, you should use the knowledge of how the code is actually written to ensure you don't write lots of extra tests because a book says to. You will likely come up with different (not necessarily fewer) tests when doing white-box testing to ensure things like statement and branch coverage.

For black-box testing on the other hand, it's often helpful to assume nothing. Especially if you don't know the quality of the codebase. I once worked on a project where a spinning object had problems in a "magic" RPM range that we could only have found by testing since we didn't have access to the actual firmware involved. Fixing it from our end was equally...entertaining.

• Ok, imagine ou are build a blackbox test. Why to use the values 2 and 99 if the values 1 and 100 are boundary true values. I present the code to show an implementation and help to think about an incorrect program that the tests (0,1,2, 99,100,101) gets a failure and the tests (0,1,100,101) does not get it Oct 9 '17 at 20:50
• I believe my code example does just that. Passing 1 or 100 would return true, passing 0 or 101 would return false, so the tests would pass if that was all you used. But 2 and 99 would also return false, causing the test to fail. Oct 9 '17 at 20:56
• @VictorVidigalRibeiro I just realized that my code is only two characters different than yours, so I'll point out the difference. Note that I used `==`, not `>=` and `<=`. :) Oct 9 '17 at 21:04
• Yeahh, It is the example: with == operator. Thanks... Oct 9 '17 at 21:12
• Checking 1 and 100 is useful even with white-box testing. The purpose of a test is to validate the current implementation and to prevent a regression when the code is modified. Besides, having a useless test is cheap compared to a missing test which could lead to hours of debugging. Oct 10 '17 at 17:51

We took 0 and 101 to test for INVALID data scenario.

We took 1 and 100 to test whether = part of <= and >= is working or not.

We took 2 and 99 to test whether VALID values are also working in(best case scenario) or not. You can treat this as a positive test case.

So three test cases scenario would be there:

1) for INVALID values.

2) for exact boundary values.

3) for VALID values.

Actually your example is very simple so by checking with 2 and 99 may seem redundant. But there may be cases which can be complex in real scenarios. So in those cases along testing with INVALID and exact boundary data values, it is also necessary to check with VALID data values.