How to apply boundary value analysis to a practically unlikely/impossible boundary?

Question

I am involved in an effort to write a set of regression test scripts for a point of sale system. We are using ISO standards such as ISO/IEC/IEEE 29119-4 to determine our test techniques. For various operations I have been applying boundary value analysis.

For one specific operation on the till we can print out type balances (sales, refunds etc). The lower boundary is well defined as 0.00. However, the upper boundary is some magic number in the billions.

I could include a test script to say "test for this stupidly high number". However, I know that (through manual testing) it will be a huge effort. Many of these sub totals are limited in that the transactions have limits in themselves. For example, the system will only allow refunds of a maximum of 500.00 per transaction.

We can safely assume (by looking at client figures) that something like 99,999.99 would be a more realistic upper boundary.

Is it acceptable to re-define boundaries from functional to testable?

Or should I document the upper boundary as undefined/untestable, and capture a test scenario in some other test analysis approach (such as creating an equivalence class partition of "testable range" or use an "error guessing" approach to make sure such a large number doesn't break the system)?

Answer 1

Is it acceptable to re-define boundaries from functional to testable?

It depends.

If you are testing a value that represent a physical property you can safely limit yourself, although it is a good idea to document it somewhere and double check your assumptions (see the first F16 flights at Dead Sea heights of far below 0)

In your case I would invest this little effort and test this limit, you can never tell where will this piece of code end, or how bad inflation will be making numbers much much higher

Answer 2

This is a situation where a set of test data designed specifically for unusual/rare test scenarios comes in handy.

The way I'd deal with your situation is this:

• Set up two or more extremely high-priced items (preferably at a little under the maximum allowed price for a single item in the system).
• If your POS system allows quantity limits, ensure the high-priced items do not have quantity limits.
• If you can turn off transaction size limits, turn off transaction size limits.
• Explore any keyboard shortcuts your application offers for transactions - you may be able to perform an auto-add or similar operation by holding down a key: I've done this to quickly generate a mass of transactions in a system.

With that set of basic configuration in place, you should be able to determine whether it's feasible to test the maximum limits and the likelihood of them being encountered in real-world scenarios.