Black Box Testing Test Case Design techniques...

The most popular Black box testing techniques are:-

1. Equivalence Partitioning.
2. Boundary Value Analysis.
3. Cause-Effect Graphing.
4. Error-Guessing.

• Equivalence Partitioning: -A software testing technique that involves identifying a small set of representative input values that invoke as many different input conditions as possible.

It is a black box testing technique that divides the input domain of a program into classes of data from which test cases can be derived.

Equivalence classes may be defined according to the following guidelines.

1. If an input condition specifies a range, one valid and two invalid equivalence classes are defined.
2. If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
3. If an input condition specifies a member of set, one valid and one invalid equivalence classes are defined.
4. If an input condition is Boolean, one valid and one invalid equivalence class are defined.
   

Equivalence Partitioning Example

Grocery Store Example

Consider a software module that is intended to accept the name of a grocery item and a list of the different sizes the item comes in, specified in ounces. The specifications state that the item name is to be alphabetic characters 2 to 15 characters in length. Each size may be a value in the range of 1 to 48, whole numbers only. The sizes are to be entered in ascending order (smaller sizes first). A maximum of five sizes may be entered for each item. The item name is to be entered first, followed by a comma, then followed by a list of sizes. A comma will be used to separate each size. Spaces (blanks) are to be ignored anywhere in the input.

Derived Equivalence Classes

1. Item name is alphabetic (valid)
2. Item name is not alphabetic (invalid)
3. Item name is less than 2 characters in length (invalid)
4. Item name is 2 to 15 characters in length (valid)
5. Item name is greater than 15 characters in length (invalid)
6. Size value is less than 1 (invalid)
7. Size value is in the range 1 to 48 (valid)
8. Size value is greater than 48 (invalid)
9. Size value is a whole number (valid)
10. Size value is a decimal (invalid)
11. Size value is numeric (valid)
12. Size value includes nonnumeric characters (invalid)
13. Size values entered in ascending order (valid)
14. Size values entered in non ascending order (invalid)
15. No size values entered (invalid)
16. One to five size values entered (valid)
17. More than five sizes entered (invalid)
18. Item name is first (valid)
19. Item name is not first (invalid)
20. A single comma separates each entry in list (valid)
21. A comma does not separate two or more entries in the list (invalid)
22. The entry contains no blanks (???)
23. The entry contains blanks (????)

Black Box Test Cases for the Grocery Item Example based on the Equivalence Classes Above.

#	Test Data	Expected Outcome	Classes Covered
1	xy,1	T	1,4,7,9,11,13,16,18,20,22
2	AbcDefghijklmno,1,2,3 ,4,48	T	1,4,7,9,11,13,16,18,20,23
3	a2x,1	F	2
4	A,1	F	3
5	abcdefghijklmnop	F	5
6	Xy,0	F	6
7	XY,49	F	8
8	Xy,2.5	F	10
9	xy,2,1,3,4,5	F	14
10	Xy	F	15
11	XY,1,2,3,4,5,6	F	17
12	1,Xy,2,3,4,5	F	19
13	XY2,3,4,5,6	F	21
14	AB,2#7	F	12

· Boundary Value Analysis: -It is a black Box testing technique that leads to selection of test cases that exercise the boundary values. It is a test data selection technique in which values are chosen to lie along data extremes. Boundary values include maximum, minimum, just inside/outside boundaries, typical values, and error values. The hope is that, if a systems works correctly for these special values then it will work correctly for all values in between.

Rather than selecting any element of an equivalence class, BVA leads to selection of test cases at the “Edges” of the class. By applying the guidelines of BVA , boundary testing will be more complete.

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.

The Steps for this technique are listed as follows:-

1. Identify the causes (input conditions) and effects (output conditions) of the program under test.
2. For each effect, identify the causes that can produce that effect. Draw a Cause-Effect Graph.
3. Generate a test case for each combination of input conditions that make some effect to be true.

Error Guessing: - From intuition and experience, enumerate a list of possible errors or error prone situations and then write test cases to expose those errors.

White Box Testing Also known as glass box, structural, clear box and open box testing is a Software testing technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data. Unlike black box testing, white box testing uses specific knowledge of programming code to examine outputs. The test is accurate only if the tester knows what the program is supposed to do. He or she can then see if the program diverges from its intended goal. White box testing does not account for errors caused by omission, and all visible code must also be readable.

White Box testing strategies include designing tests such that every line of source code is executed at least once, or every function is tested individually. White Box testing is required because, on average, even well written programs have one to two bugs for every 100 statements.

One example of White Box testing conducted recently by the team of AppLabs technologies(SEI CMM level 5 Company) included testing the file extraction and transmission routines for JCL execution/ compliance, file movement over protocols such as NDM (direct connect) and file format checks. Also, security testing related to file transmission was performed to ensure that the system did not fail in any independent security audit. Conversion routines such as EBCIDIC to ASCII and ASCII to EBCIDIC were developed and tested by AppLabs engineers.

The following issues were addressed when we conducting White Box testing

projects.

•Properly allocate resources to perform class and method analysis and to document and review the same. Next, develop a test harness made up of stubs, drivers and test object libraries.

• Then, development and use of standard procedures, naming conventions and libraries is Performed.

• Establishment and maintenance of regression test suites and procedures is conducted as we allocate resources to design, document and manage a test history library.

White Box Testing generates the test cases that: -

• Guarantees that all the independent paths with in a module have been exercised at least once.
• Exercises all logical decisions on their true and false sides.
• Execute all loops at their boundaries and within their operational bounds.
• Exercise internal data structures to ensure their validity.

A white-box test approach should be taken to verify a unit's internal structure. Theoretically, you should test every possible path through the code, but that is possible only in very simple units. At the very least you should exercise every decision-to-decision path (DD-path) at least once because you are then executing all statements at least once. A decision is typically an if-statement, and a DD-path is a path between two decisions.