Wednesday 12 December 2012

Tell me 4 test case techniques?


Boundary Value Analysis


Boundary Value Analysis (BVA) is a core Black Box Testing technique that limits the number of test cases you need to write in order to cover the functionality. BVA is similar to Equivilance Partitioning (EP), but more specific. While Equivilance Partitioning says that any value in a given range (partition) is equivilant for testing purposes, Boundary Value Analysis states that the values on the edges of each equivilant partition provide the most valuable test cases. By testing those values you will catch most of the bugs in the functionality because you are testing the boundaries of logic behind those rules.
Lets look at the data we used in the Equivilance Paritioning example to see how Boundary Value Analysis would handle the same set of data.
 0   1  |    2   3    4   5     |    6   7   8  9...
Invalid (too low) |      Valid       |   Invalid (too high)
BVA would suggest looking at the data, and selecting tests at the boundry of each section. Thus, you would select the following values: 0, 1, 2, 5, 6.
  • 0 is the lowest invalid value
  • 1 is the highest of the first set of invalid values.
  • 2 is the lowest valid value
  • 5 is the highest valid value
  • and 6 is the first invalid value in the second set.
By testing these values, you have tested the values at the boundries of each set of valid and invalid data.
In this example offers two sets of valid data:
           0   |   1 2      3      |     4      5 6     |     7  8 9...
Invalid (too low) | Valid (message A) |  Valid (message B) |  Invalid (too high)
BVA would select the following values: 0, 1, 3, 4, 6, 7  – just the values at the edges of each equivilance partition.
Since bugs tend to cluster at these edges, it is a perfect place to do your testing. While Equivilance Partitioning is a good way to split up your data, Boundary Value Analyis offers a way to select meaningful test data from those partitions.

Equivalence Partitioning


Equivalence Partitioning (EP) is a common software testing technique that seeks to limit the sheer number of tests needed to completely cover a given set of inputs. It is often part of Black Box Testing, as the tester simply bases their tests off the requirements given for the field, instead of evaluating how the software handles the input.
The concept is basically this: Any number or character within any given range of inputs, both valid and invalid, is equivalent to others in the same range (partition).
Example:
  • A field allows only numeric characters
  • Length must be 2-5 characters long
You could could be partition those requirements like this:
             0 1  |   2  3  4  5   | 6  7  8 9
Invalid (too low) |      Valid       |   Invalid (too high)
According to EP the values in each partition are equivalent. So 0 and 1 are equivalent, as are 2 – 5 and then the third partition of 6 and over.
This means that if you were testing this field, you could test 0 and 8 as your invalid entries and 3 as your valid one. The idea is to test the algorithm behind the software by testing a value from each part of the rule, but not all values. This is a good idea in theory.
It makes a lot of sense with larger input fields as well. While it is easy to test inputs 2-5, it is harder to test inputs 2-500. It is necessary when designing test cases to find ways to reduce the number of test cases while still maintaining coverage in order to test effectively and efficiently.  However you must be careful when using this technique, because if you incorrectly assume that each value in the partition is equivalent, or if you miss a partition all together by not understanding the underlying logic, you can miss some key functionality.
My issue with this practice is that if you only test 3 as your valid value, you are trusting that the developer coded the valid range (2-5) in correctly. For example, 3 may always work, but perhaps in this code, 5 is the cut off, but instead of allowing 5 characters, it takes 5 and anything over and rejects it. Logically when looking at requirements, EP makes sense, but in the real world of finding bugs, I find it has some flaws when used stand alone. It is also only as effective as the partitions you decide on. Any error in creating the partitions can lead to lacking coverage.
Example:
  • An input field accepts 2-5 characters
  •  If the input is 2 or 3 it outputs message A
  •  If it the input is 4 or 5 it outputs message B (for example, it may be alerting you to the security of a password, and the longer passwords are deemed more secure.)
So when you start testing with Equivalence Partitioning, you see that values 2-5 are valid and then you partition accordingly, just like we did above.
          0   1 |   2   3    4   5    |   6   7   8  9
Invalid (too low) |      Valid       |   Invalid (too high)
With the above rules, you are never testing Message A. You need further partitioning, like this:
      -2  -1  0 1 |    2      3      |     4      5     | 6  7  8 9
Invalid (too low)|Valid (message A)|Valid (message B)|Invalid (too high)
So to test fully, you would need to select values from each of 4 partitions, 2 invalid entries and 2 valid entries.
When using this practice, be sure you both understand the full meaning of the requirements so you don’t miss functionality, and be sure you have considered if your selections from each partition are really offering you complete coverage.
To help with some of these risk areas, I would always suggest using Boundary Value Analysis as well when testing with Equivalence Partitioning.


Cause Effect Graphing                     

              A testing technique that aids in selecting, in a systematic way, a high-yield set of test cases that logically relates causes to effects to produce test cases. It has a beneficial side effect in pointing out incompleteness and ambiguities in specifications.


No comments:

Post a Comment