Boundary Tests
Boundary tests verify that the application works correctly around boundaries.
So we had better start by defining what a boundary is.
There are many times in the operation of an application where it will take a different action depending on the result of a previous action, or on the value of a piece of data.
For example, supposing that you have a specification for a bank account which pays you £10 whenever you make a deposit of more than £1000, with up to 3 deposits of more than £1000 in a month.
This small scenario has two boundaries in it. The first one is that you must pay in more than £1000 to get the £10. So what happens when you pay in £1000? Do you get the £10 credit or not? According to the specifications, the answer is "No", because the requirement is that you must pay in more than £1000 - and £1000 is not more than £1000.
A deposit of £1000.01, on the other hand is more than £1000, and so should get the £10 credit.
If Developer has written in his code
'if deposit > 1000 then credit = +10'
the code will work correctly. If, however, the Developer has written
'if deposit => 1000 then credit =+10'
the code will not work correctly.
How about
'if deposit > 1000.01 then credit =+10'
or
'if deposit >999.99 then credit =+10'
One will work, and one won't.
But don't let the pseudocode scare you. You don't need to know what is going on inside the code (as long as you are doing black box testing, that is - but more on that later).
The other boundary is how many times per month can you do this - the specification says up to 3 times. This is something that needs clarifying with the BA, because strictly speaking "up to 3" does not include 3 - it means up to and including 2.999 recurring (and you can't really make 0.999 of a deposit, can you).
It is possible that the BA meant "up to and including 3" when writing the Specifications, meaning that you can make a deposit of more than £1000 three times in a month and get a £10 credit. It is also possible that they meant "no more than 2".
While you are clarifying this (and a bunch of other questions) with the BA, the Developers will have gone ahead and already written large amounts of code. So if the Developer understood that "up to 3" meant "no more than 2", they will already have written code to reflect that understanding. By the time the BA gets back to you and says that it means "up to and including 3", the Developers will be working on other things, and may not even realise that the Specification has been clarified in a way that affects code they have written.
But now you know exactly what it is that you have to test - and you will test that. Sometimes, your tests will show that the application behaves as expected - and sometimes, they will show that it behaves differently.
Boundaries appear in all sorts of instances. This bank deposit illustration is just one of many possibilities. Some others are:
* An extra discount on car insurance if you are aged over 25 (does that start at 26 years, or at 25 years and 1 day)
* Car insurance costs more if you make more than 2 claims totalling more than £1000 in a year (same principle as the bank deposit illustration)
* Free postage if you spend over £25 (does a spend of £25 get free postage, or does it need to be at least £25.01)
* After 10 years at 7% growth, your investment will be ... (best make sure the counter counts 10 times - sometimes Developers start a counter at 0, and sometimes at 1 - that can make a big difference to the end result)
You'll find boundaries all over the place, so be on the lookout for them.
Boundary tests verify that the application works correctly around boundaries.
So we had better start by defining what a boundary is.
There are many times in the operation of an application where it will take a different action depending on the result of a previous action, or on the value of a piece of data.
For example, supposing that you have a specification for a bank account which pays you £10 whenever you make a deposit of more than £1000, with up to 3 deposits of more than £1000 in a month.
This small scenario has two boundaries in it. The first one is that you must pay in more than £1000 to get the £10. So what happens when you pay in £1000? Do you get the £10 credit or not? According to the specifications, the answer is "No", because the requirement is that you must pay in more than £1000 - and £1000 is not more than £1000.
A deposit of £1000.01, on the other hand is more than £1000, and so should get the £10 credit.
If Developer has written in his code
'if deposit > 1000 then credit = +10'
the code will work correctly. If, however, the Developer has written
'if deposit => 1000 then credit =+10'
the code will not work correctly.
How about
'if deposit > 1000.01 then credit =+10'
or
'if deposit >999.99 then credit =+10'
One will work, and one won't.
But don't let the pseudocode scare you. You don't need to know what is going on inside the code (as long as you are doing black box testing, that is - but more on that later).
The other boundary is how many times per month can you do this - the specification says up to 3 times. This is something that needs clarifying with the BA, because strictly speaking "up to 3" does not include 3 - it means up to and including 2.999 recurring (and you can't really make 0.999 of a deposit, can you).
It is possible that the BA meant "up to and including 3" when writing the Specifications, meaning that you can make a deposit of more than £1000 three times in a month and get a £10 credit. It is also possible that they meant "no more than 2".
While you are clarifying this (and a bunch of other questions) with the BA, the Developers will have gone ahead and already written large amounts of code. So if the Developer understood that "up to 3" meant "no more than 2", they will already have written code to reflect that understanding. By the time the BA gets back to you and says that it means "up to and including 3", the Developers will be working on other things, and may not even realise that the Specification has been clarified in a way that affects code they have written.
But now you know exactly what it is that you have to test - and you will test that. Sometimes, your tests will show that the application behaves as expected - and sometimes, they will show that it behaves differently.
Boundaries appear in all sorts of instances. This bank deposit illustration is just one of many possibilities. Some others are:
* An extra discount on car insurance if you are aged over 25 (does that start at 26 years, or at 25 years and 1 day)
* Car insurance costs more if you make more than 2 claims totalling more than £1000 in a year (same principle as the bank deposit illustration)
* Free postage if you spend over £25 (does a spend of £25 get free postage, or does it need to be at least £25.01)
* After 10 years at 7% growth, your investment will be ... (best make sure the counter counts 10 times - sometimes Developers start a counter at 0, and sometimes at 1 - that can make a big difference to the end result)
You'll find boundaries all over the place, so be on the lookout for them.
