Friday, October 17, 2008

Black Box and White Box

Black box Testing:
Functional testing addresses the overall behavior of the program by testing transaction flows, input validation and functional completeness. Which is known as Black box Testing. There are four important techniques, which are significantly important to derive minimum test cases and input data for the same.

Equivalence partitioning:
An equivalence class data is a subset of a larger class. This data is used for technically equivalence partitioning rather than undertaking exhaustive testing of each value in the larger set of data. For example, a payroll program, which edits professional tax deduction limits within Rs. 100 to Rs. 400, would have three equivalence partitions.

Less than Rs.100/- (Invalid Class)
Between Rs.100 to Rs.400/- (Valid Class)
Greater than Rs.400/- (Invalid Class)

If one test case from one equivalence class results in an error, all other test cases in the equivalence class would be expected to result the same error. Here, tester needs to write very few test cases, which is going to save our precious time and resources.

Boundary Value Analysis:
Experiences show that the test cases, which explore boundary conditions, have a higher payoff than test cases that do not. Boundary conditions are the situations directly on, above and beneath the edges of input and output equivalence classes.

This technique consists of generating test cases and relevant set of data, that should focus on the input and output boundaries of given function. In the above example of professional tax limits, boundary value analysis would derive the test cases for:

Low boundary plus or minus one (Rs.99/- and Rs.101/-)
On the boundary (Rs.100/- and Rs.400/-)
Upper boundary plus or minus one (Rs.399 and Rs.401/-)

Error Guessing:
This is based on the theory that test cases can be developed, based upon intuition and experience of the test engineer. Some people tend to adapt very naturally with program testing. We can say these people have a knack for ’Smelling out’ errors without incorporating any particular methodology.
This “Error Guessing” quality of a tester enables him to put in practice, more efficient and result oriented testing than a test case should be able to guide a Tester.
It is difficult to give procedure for the error guessing technique since it is largely intuitive and ad hoc process. For example Where on of the input is the date test engineer may try February 29,2000 or 9/9/99.

Orthogonal Array:
Particularly this technique is useful in finding errors associated with region faults. An error category associated with faulty logic within software component.

For example there are three parameters (A, B & C) each of which has one of the three possible values. Which may require 3X3X3=27 Test cases. But because of the way program works it is probably it is more likely that the fault will depend on the values of only two parameters. In that case fault may occur for each of these 3 test cases.
1. A=1,B=1,C=1
2. A=1,B=1,C=2,
3. A=1,B=1,C=3

Since the value of the 'C' seems to be irreverent to the occurrence of this particular fault, any one of the three test cases will suffice. Depending upon the above assumption, test engineer may derive only nine test cases. Which will show all possible pairs within all three variables. The array is orthogonal because of each pair of parameters all combination of their values occurs once.

That is all possible pair wise combination between parameters A & B, B & C, C & A are shown since we are thinking in terms of pairs we say this array has strength of 2, It does not have strength of 3,
because not all thee way combination occurs A=1, B=2, C=3 for example, don’t appear but it covers the pair wise possibilities which is what we are concern about.

White box Testing:
Structural testing includes path testing, code coverage testing and analysis; logic testing nested loop testing and many similar techniques. Which is known as white box testing.

1. Statement Coverage: Execute all the statements at least once.
2. Decision Coverage: Execute each decision directions at least once.
3. Condition Coverage: Execute each condition with all possible outcomes at least once.
4. Decision / Condition Coverage: Execute all possible combinations of condition outcomes in each decision. Treat all iterations as two way conditions exercising the loop zero times and Once.
5. Multiple Condition Coverage: Invokes each point of entry at least once.

A Tester would choose a combination from above technique that is appropriate for the application and available time frame. A very detailed focus on all these aspects would lead to too much of vague information at times.

No comments: