Structure Based Technique White Box

Structure based testing is a strategy in which testing is based solely on the internal working and structure of the code. Testing is based on the internal paths, structure, and implementation of the software under test (SUT). In contrast to its complement, black box testing, it generally requires detailed programming skills.
Structure based testing is commonly referred to as "white box testing". It is also called as "Glass box" or "Clear Box" testing.

Process involved in white box testing are follows:

1. Analyze the SUT's implementation and then identify paths through the SUT.
2. Choose the inputs to cause the SUT to execute selected paths. Expected results for those inputs are determined.
3. Execute the tests. Actual outputs are compared with the expected outputs.
4. A determination is made as to the proper functioning of the SUT.

Notre: The tester must have programming skill to understand and evaluate the SUT.

White box testing comprises following techniques under static and structural testing:
Desk checking
Code walkthrough
Formal or fagan inspection
statement coverage
Flow graph and path testing
Data flow testing
syntax testing

How To use All Pairs Technique Testing

All PairsTesting: It is also known as Pairwise Testing Technique which is a combinatorial software testing method where, for each pair of input parameters to a system, all possible discrete combinations of those parameters are identified and tested.

In this method, a set of test cases is generated that covers all combinations of the selected test data values for each pair of variables. It's also referred as 2-way testing. It is also possible to do all triples or all quadruples testing, but the size of the higher order test sets grows very rapidly.

This technique normally begins by selecting values for the system's input variables. These individual values are often selected using domain partitioning. The values are then permuted to achive coverage of all the pairings.

The steps for using all pairs testing technique follows:
STEP 1: Analyze the given test inputs or requirements and list out the variables in the application to be tested. This can be listed in the form of a table where column headers represent the various variables to be tested.

Note: Equivalence class partitioning technique can also be used at this point to partition and group together variables.

STEP 2: List out the various possible values each of the variables can hold. These values can be put in rows just beneath the corresponding variables.

STEP 3: Create the "ALL Pairs" table by putting the variables in the top row and start by filling in the values for the variables in each column.

STEP 4: If a combination does not exist, then swap around with the values to see if the combination can be got.

STEP5: Else add a new row

Technique with examples orthogonal array testing

Orthogonal array testing is combinatorial software testing which uses a systematic, statistical way of deriving test conditions and test cases. It is followed in places where there are a large number of combinations that should be tested and would be risky if we do not test them.

Technique:
The steps for using orthogonal array technique are:
STEP 1: Analyze the given test inputs or requirements and list out the variables that needs to be tested for interaction.
STEP 2: Determine the number of choices or values for each variable.
STEP 3: Locate an orthogonal array which has a column for each variable and values within the columns that correspond to the values for each variable.
STEP 4: Map the variables with their values on to the orthogonal array.
STEP 5: Each row in the table corresponds to a test condition or a unique test case.

Examples: Company A has designed a web page with three distinct sections (Top, middle, and bottom). These sections can be individually shown or hidden by the user. The browsers on which the webpage can be viewed with are internet explorer and firefox. The server used for launching the application can be IIS, Apache and weblogic. Create an orthogonal array to test the interactions of the different sections. Use orthogonal array to select the test conditions that would be required to test this scenario.

Solution:
STEP1: The variables that needs to be tested for interaction are sections, visibility, browsers and servers.
STEP 2: The number of choices or values for each variable is:

• Sections: Top, middle, bottom
• Visibility: shown, hidden
• Web browser: Internet explorer, firefox
• Servers: IIS, APache amd weblogic

STEP 3: The orthogonal array that can be used would be Lbase 9(3power 4)array.
STEP4 : Map the variables with their values on to the orthogonal array

State transition diagram in testing

State Transition Testing Technique:
Steps for using state transition testing are:
STEP 1: Understand the various states that the system , user, or object can be in, including the initial and final states. Examples of states can be 'User raising a purchase order' or 'leave request is accepted'.  State are represented as,

STEP 2: Identify transitions, events, conditions, and actions that can and can't apply in each state.

STEP 3: Use a graph or table to model the system. This graph or table also serves as an oracle to predict correct system behavior along with a requirement specification.

STEP 4: For each event and condition (i.e each transition) verify that the correct action and next state occurs.

STEP 5: Create test cases in such a way that all states are visited at least once, all events are triggered at least once and all paths are executed at least once. (i.e all transitions in the system are tested at least once).

Example for using state transition testing:

What is State Transition Testing

State Transition Testing:
State-Transition diagrams are an excellent tool to capture certain types of system requirements and to document internal system design. These diagrams document the events that come into and are processed by a  system as well as the system's responses. When a system must remember what happened before or when valid and invalid orders of operation exist, then state transition testing could be used. It is useful in situations when workflow modelling or dataflow modelling has been done, which mean that the system moves from one state to another.

State Transition diagrams uses states, events, actions and transitions of the system to be tested. Together with all these components, they represent how a system interacts with the outside world and process them.

Some of the terms use din state transition testing are:
State: A state is a condition in which a system is waiting for one or more events. States remember inputs the system has received in the past and define how the system should respond to subsequent events when they occur. These events may cause state transitions and or initiate actions. The state is generally represented by values of one or more variables within a system.

Transition: It represents a change from one state to another caused by an events.
Event: Something that causes the system to change state. Events may have parameters associated with them. Events can be independent or casually related.

Actions:  An action is an operation initiated because of state change. Often these actions causes something to be created that is outputs of the system.

Decision Table Testing Technique and Examples

Technique followed for decision table testing are follows:
STEP 1: Analyze the given test inputs or requirements an list out the various conditions in the decision table.
STEP 2: Calculate the number of possible combinations (Rules)
STEP 3: Fill columns of the decision table with all possible combinations (Rules)
STEP 4: Find out cases where the values assumed by a variable are immaterial for a given combination Fill the same by "don't care" symbol.
STEP 5: For each of the combination of values, find out the action or expected result.
STEP 6: Create at least one Test case for each rule. If the rules are binary, a single test for each combination is probably sufficient. Else if a condition is a range of values,, consider testing at both the low and high end of range.

Example problem for decision table testing:
Question: The following instructions were taken from a University Examination Application Form. Examine the and create a Decision Table to represent the University rules and thereby decide on the test cases to be designed.

1. A candidate appearing for the exam should have a minimum 80% attendance
2. Has attended 3 internal tests with an average of 10 or more marks or
3. Has attended 2 internal tests with an average of 15 or more marks and 
4. Has taken up the external examination and scored more than 35 marks.

If the above conditions are fulfilled, then the student can be considered as pass in that subject
Answer:
Based on the decision table technique, the decision table conditions and actions can be drafted as given below:
C1 = Condition 1 - Attendance greater than 80%
C2 = Condition 2 - Attended 3 internal tests with an average of 10 or more marks
C3 = Condition 3 - Attended 2 internal tests with an average of 15 or more marks.
C4 = Condition 4 - Cleared external exam and scored more than 35 marks
A1 = Action 1 - Pass
A2 = Action 2 - Fail
R1 = Rule 1- C1, C2, C4 are satisfied
R2  = Rule 2- C1, C3, C4 are satisfied

Note: list the remaining rule ie. R3 TO R6 accordingly
The total number of alternatives = 2 the power of number of conditions = 2 the power of four = 16

Decision Table General Format

Decision Tables are used to describe and analyze problems that contain procedural decision situations that are characterized by one or more conditions; the state of which determines the execution of a set of actions.

They record the complex business rules that a system must implement. This serves as a guide to create Test Conditions. The basic parts of a decision table are shown below:

The upper left portion of the format is called the stub quadrant, it contains statements of the conditions. Similarly, the lower left portion is called the action stub quadrant, which contains statement of the actions. The condition entry and action quadrants appear in the upper and lower right portions (conditions and entry) forms a decision rule.

The various input conditions are represented by the conditions 1 through m and the actions are represented by actions 1 through n. These actions should be taken depending o the various combinations of input conditions.

Each of the rules defines a unique combination of conditions that result in the execution (firing) of the actions associated with rule. All the possible combinations of conditions define a set of alternatives. For each alternative, a test action should be considered. The number of alternatives increases exponentially with the number of conditions, which may b expressed as 2 power of Number of Conditions. When the decision table becomes too complex, a hierarchy of new decision tables can be constructed.

Note:

• The actions do not depend on the order in which the conditions are evaluated, but only their values.
• All the values are assumed to be available simultaneously.
• Actions depend only on the specified conditions, not on any previous input conditions or system state.

Recommended:

Decision Table Testing Technique with examples