In an application or a system there will always be boundaries.  For example a computer will not run for 1000 years continuously without any problem. When uploading a file there will be an accepted limit for its size. When sending a text message there will be a limit. Every functionality, size, property will have a limit created by an adjacent functionality, size or property. Adding a 10 TB attachment to an email is failing because of buffer limit used to read the data or because  account is limited and total size is less than the attachment etc.

So the limit will always exist for a certain size or type or value. The idea is to find the limit.

A lot of boundaries are not relevant or feasible to take in consideration or  try. For example heating a useful PC in an oven to check when it will stop working properly. But even in this case such information, without the hassle of course , would be useful.

In many situations is possible to check the relevant limits, either directly or by scripting. Some of them are already validated (you have to test that to make sure) like “The size of the image must be under 700 KB”. Finding the limit will not mean always finding a bug where the application crashes, but it will give you information about the system.

Having the limits of the system will help having a better map of the application in our mind.

Now going to a specific functionality and using boundary testing on it, its a science in itself. And a valuable test approach I think will need the exact context.

Connecting boundaries and negative scenarios (I call this way the scenarios where the application fails) can be done in 3 steps:

1. Make a list of the boundaries that can change the behavior of the application: username after a certain size, traffic too high, traffic too low (you need the context to make the list)
2. Go then through every item of the list and imagine a situation related to that limit where things can go wrong. Not to be pessimistic but to avoid bad things to happen before it gets to the client. For example application is storing some data. The negative scenario is that the disk will become full after a while.
3. The last step is a complex one where you are now able to connect more dots ( the real ones and also the imagined ones) and you can derive a lot of other scenarios. You can gather info on the application. Finding bugs and negative scenarios increase motivation and productivity because there is a purpose involved. As opposed to just navigating without direction in the application. The probability to find critical issues is also higher.

ShareThis