How To Use Decoding Decision Tables & White-Box Testing

Decision Tables in boundary value analysis and equivalence class partitioning do not consider combinations of input conditions, but consider each input separately. A decision table is a good way to test the system behaviour for different combination of inputs It is useful to determine the test scenarios for complex business logic.

It is a systematic approach where the different input combinations and their corresponding system behaviour are captured in a tabular form. This table helps us to deal with different combination of inputs with their associated outputs. Also, it is known as the cause-effect table.

To use this method, following steps are done:

Formation of Decision Table:

A decision table is formed with the following four components:

• Condition stub is a list of input conditions for which the complex combination is made.
• Action stub is a list of resulting actions, which will be performed if a combination of input condition is satisfied.
• Condition entry is a specific entry in the table corresponding to input conditions mentioned in the condition stub.
• When the condition entry takes only two values TRUE or FALSE, then a table is called Limited Entry Decision Table. In Limited Entry Decision Table, condition entry, which has no effect whether it is TRUE or FALSE, is called Don’t Care state or immaterial state (Represented by | ) and it doesn’t affect the resulting action.
• When the condition entry takes several values, it is called Extended Entry Decision Table.

• When we enter TRUE of FALSE for all input conditions for a particular combination, then it is called a Rule and it defines which combination of conditions produces the resulting action.
• Action entry it the entry in the table for resulting action to be performed when one rule is satisfied. Action entry is denoted by ‘X’ in the table.

Test Case Design Using Decision Table:

For designing test cases from a decision table, following interpretations should be done:

• Interpret condition stubs as the input for the test case.
• Interpret action stubs as the expected output for the test case.
• Rule, which is the combination of input conditions, becomes the test case itself.
• If there are K rules over n binary conditions, there are at least K test cases and the most 2 test cases.

Example 1: A program calculates the total salary of an employee with the conditions that is the working hours are less than or equal to 8, then give normal salary. The hours over 8 on normal working days are calculated at the rate of1.35 of the salary. However on holiday or Sundays, the hours are calculated at the rate of 2.00 times of the salary. Design test cases using Decision Table testing.

 White-box Testing:

White-box testing is a software testing method in which the internal structure/ design/ implementation of the software being tested is known to the tester. The tester chooses inputs to exercise paths through the code and determines the appropriate outputs. Often developers use this technique to test their own design and code.

It is a dynamic testing technique. It is also known as glass-box, open box, logic driven, clear box, structural or development testing, It is a complementary to black-box testing.

It ensures that the internal parts of the software are adequately tested. As it is based on the inner workings of an application and revolves around internal testing, the term “White-Box'” was used because of the see-through box concept. Need of White-box testing.

It is needed for the following reasons:

• It is used for testing the module for initial stage testing. There may be portions in the code, which are not checked when executing functional, Test cases, but these will be executed and tested by white-box testing.
• Errors that come from the design phase will also be reflected in the code and therefore, we must execute white-box test cases for code verification (Unit verification).
• We often believe that a logical path is not likely to be executed but, in fact, it may be executed on a regular basis. White-box testing explores these paths too.
• Some typographical errors are not observed and go undetected and are not covered by black box testing techniques. White-box testing techniques help to detect these errors.

Advantages of White Box Testing:

• Code optimization by finding hidden errors.
• White box tests cases can be easily automated.
• Testing is more thorough as all code paths are usually covered.
• Testing can start early in SDLC even if GUI is not available.

Disadvantages of White Box Testing:

• Expensive as one has to spend both time and money to perform white box testing.
• Every possibility that few lines of code are missed accidentally.
• In-depth knowledge about the programming language is necessary to perform white box testing.

Classification of white box testing:

White-box testing can be classified as structural and static testing.

Structural Testing: Structural testing considers the program code, and test cases are designed based on the logic of the program such that every element of the logic is covered. This type of testing requires knowledge of the code, so, it is mostly done by the developers.

It is more concerned with how system does it rather than the functionality of the system. It provides more coverage to the testing. It can be used on different levels such as unit testing, component testing, integration testing, functional testing etc.

The following are different structural testing techniques or coverage which is also known as white-box.

1. Logic Coverage Criteria:

Statement Coverage:

The aim of this form is, all the statements of the module are executed or tested of least once to notify every bug. Using the technique we can check what the score code is expected to do and what it should not, It can also be used to check the quality of the code and the low of different paths in the program.

The main drawback of this technique is that we cannot test the false condition in it. (Statement coverage No of statements Executed/Total no of statements in the source code 100).

If we want to cover every statement in this, then the following test cases must be designed:

Test case 1: x=y=n, where n is any number e.g. x=y=5

In this case, while loop is skipped and hence all statements of while loop are not executed. Statement coverage= 4/11 *100=36.36%

Test case 2: x=n, y=n’, where n and n’ are different numbers. e.g. x=5,y=6

In this case, while loop is executed, but not all statements of a loop. Statement coverage=10/1 1 *100=90.90%

So two more test cases are designed as:

Test case 3: x>y, e.g. x-6,y-5, statement coverage=9/11 *100-81.81%

Test case 4: x<y, e.g. x=5,y-6, statement coverage=10/1 1*100=9 1.91%

If we executes only Test case 3 and 4, it is sufficient to execute all statements of the code, and Test case 1 will never be tested and error will go undetected. Hence this form is not a sufficient criteria for logic coverage.

Branch Coverage:

It says that each decision takes on all possible outcomes(True or False) at least on e each branch or edge direction must be covered at least once. It doesn’t provide a good coverage from different conditions that lead from one node to another node as it covers that branch only once.

If we consider the previous code 1, while and if statements have two outcomes: True and False. So, test cases must be designed such that both outcomes for while and if statements are tested.

The test cases are designed:

Condition Coverage:

This form says that each condition in a decision takes on all possible outcomes at least once. It aims to test individual conditions with possible different combination of Boolean input for the expression. It is modification of Decision coverage but it provides better coverage.

It will reveal how the variables or subexpressions in the With all three above test cases it covers all branches as shown in above figure. conditional statement are evaluated. In this coverage expressions with logical operands are only considered.

e.g. while (I<=5 && J<count)

in this loop statement, two conditions are there. So, test cases should be designed Such that both the conditions are tested for True and False outcomes.

The following test cases are designed:

Here 100% condition coverage is there, but branch coverage is 50%. So we need to perform decision/condition coverage.

Decision/ Condition Coverage:

Condition coverage in a decision doesn’t mean that the decision has been covered. If the decision if(A && B) is being tested, the condition coverage would allow one to write two test cases:

Test case 1: A is True, B is False

Test case 2: A is False, B is True

However, these test cases would not execute THEN clause. The obvious way out this dilemma is a criterion called decision/condition coverage. It requires sufficient test cases such that each condition in a decision takes on all possible outcomes least once, each decision takes on all possible outcomes at least once, and each pol of entry is invoked at least once.

For code 3, we need one more test case as: Test case 3: x=5,y=-5

See black box testing

follow on twitter