boundary value analysis :
In projects there can be scenarios where in we need to do boundary value testing. For instance let’s say for a bank application you can withdraw maximum 25000 and minimum 100. So in boundary value testing we only test the exact boundaries rather hitting in middle. That means we only test above the max and below the max. This covers all scenarios. Below figure shows the BV testing for the bank application which we described previously. TC1 and TC2 are sufficient to test all condition for the bank. TC3 and TC4 are just duplicate / redundant test cases which really do not add any value to the testing. So by applying proper BV fundamentals we can avoid duplicate test cases which do not add value as such to testing.
Equivalence partitioning :
In equivalence partitioning we identify inputs which are treated by system in the same
way and produce the same results. You can see from the below figure application TC1
and TC2 both give same result i.e. Result1 and TC3 and TC4 both give same result i.e.
Result2. In short we have two redundant test cases. By applying equivalence partitioning
we minimize the redundant test cases.
So below test you can apply to see if it forms equivalence class or not:-
· All the test cases should test the same thing.
· They should produce the same results.
· If one test case catches a bug then the other should also catch.
· If one of them does not catch the defect then the other should also not catch.
Below figure shows how equivalence partition works. Below we have a scenario in
which valid values lie between 20 and 2000. Any values beyond 2000 and below 20
are invalid. In the below scenario the tester has made four test cases:-
· Check below 20 ( TC1)
· Check above 2000 (TC2)
· Check equal to 30 (TC3)
· Check equal to 1000 (TC4)
Test case 3 and 4 give same outputs so they lie in same partition. In short we are doing
redundant testing. Both TC3 and TC4 fall in one equivalence partitioning. So we can
prepare one test case by testing one value in between the boundary, thus eliminating
redundancy testing in projects.
In projects there can be scenarios where in we need to do boundary value testing. For instance let’s say for a bank application you can withdraw maximum 25000 and minimum 100. So in boundary value testing we only test the exact boundaries rather hitting in middle. That means we only test above the max and below the max. This covers all scenarios. Below figure shows the BV testing for the bank application which we described previously. TC1 and TC2 are sufficient to test all condition for the bank. TC3 and TC4 are just duplicate / redundant test cases which really do not add any value to the testing. So by applying proper BV fundamentals we can avoid duplicate test cases which do not add value as such to testing.
Equivalence partitioning :
In equivalence partitioning we identify inputs which are treated by system in the same
way and produce the same results. You can see from the below figure application TC1
and TC2 both give same result i.e. Result1 and TC3 and TC4 both give same result i.e.
Result2. In short we have two redundant test cases. By applying equivalence partitioning
we minimize the redundant test cases.
So below test you can apply to see if it forms equivalence class or not:-
· All the test cases should test the same thing.
· They should produce the same results.
· If one test case catches a bug then the other should also catch.
· If one of them does not catch the defect then the other should also not catch.
Below figure shows how equivalence partition works. Below we have a scenario in
which valid values lie between 20 and 2000. Any values beyond 2000 and below 20
are invalid. In the below scenario the tester has made four test cases:-
· Check below 20 ( TC1)
· Check above 2000 (TC2)
· Check equal to 30 (TC3)
· Check equal to 1000 (TC4)
Test case 3 and 4 give same outputs so they lie in same partition. In short we are doing
redundant testing. Both TC3 and TC4 fall in one equivalence partitioning. So we can
prepare one test case by testing one value in between the boundary, thus eliminating
redundancy testing in projects.
No comments:
Post a Comment