Good border testing

Question

• If I say that I created an input text that should only accept any decimal number from 1 to 100, how can I check it?

  IMHO, I will test in this thread:

  "0", "1", "50", "100", "101", "0.9", "100.1", "A"

  This is enough? Is there a structured flow on how to test such border testing? (any good article?) Should I also check "1 + 1"?

• What if the question has changed to "accept any integer from 1 to 100", is this series of tests sufficient? Is there a difference in the sequence of data input from testing a decimal number?

  "0", "1", "50", "50.5", "100", "101", "0.9", "100.1", "A"

Answer 1

For # 1, you're on the right track, and I think you might have too many cases that are in equivalent classes. Usually, if you have a lower bound L and an upper bound U, it is enough to verify that L and U are valid and that L - e and L + e are invalid (where e is the smallest or sufficiently small increment to exit the boundary). If you want to add extra meaning to sanity, then testing for something between L and U also works. Some will say that choosing a random value between L and U also works, but I prefer my tests to be deterministic.

So, in the above example, L is 1, and U is 100. Since this is a decimal value, the value of e is complex, since e can theoretically be infinitesimal. It’s good to choose something reasonable that is communicated by your client script. For example, if this is a dollar amount, choosing 0.01 would be a good choice. In this case, it will leave us with "1", "100", "0.99" and "100.01".

Since your text field can also accept letters, then it makes sense here also to check the odd data, as you did above, using "A". An alternative approach to ease the burden of testing is to design your customer experience to allow only valid values. In the integer case, one way to do this is to use a combined field that has only integral values ​​from 1 to 100.

For # 2, the scenario has changed a bit. L is 1 and U is 100, but e is now 1, because the only valid values ​​are integer values. If you want to check that decimal values ​​give rise to errors, this is a different class of cases and is not bound by bounds. Thus, for error conditions, "50.5" and "A" are sufficient. Or, if you want to round decimal numbers, you can also check this.

Answer 2

The danger when testing boundaries (or sometimes called boundary value analysis) is that we tend to focus on clear and obvious boundaries. But there may be many unknowns and it is difficult to predict boundaries. If we too trust in clear and obvious boundaries, we run the risk of losing gaps around hidden borders.

Therefore, although it is important to focus on known boundaries, there is no harm in trying the sample tests at different intervals.

So, I would say that your test suite may be covered a bit.

Where you have: "0", "1", "50", "100", "101", "0.9", "100.1", "A"

I would be more inclined to add a few in between: "0", "1", "10", "20", "30", "40", "50", "60", "70", "80", "90", "100", "101", "0.9", "100.1", "A"

You may also consider adding some extreme cases, such as very large numbers or several million characters.

You always need to consider the cost and value. If these tests are automated and adding a few more data points to your input adds very little time for a test run, they are very low. But if these tests are manual, then you can decide to reduce the set of tests. But don't just don't stick to boundaries ...