Testing Techniques

Testing Techniques

Testing Techniques is  required testing approach to be followed during testing. for eg: if we want to check the functionality of a module , then we go for black box testing.

Boundary value analysis and equivalence partitioning both are test case design strategies in black box testing.

Equivalence Partitioning:

In this method the input domain data is divided into different equivalence data classes. This method is typically used to reduce the total number of test cases to a finite set of testable test cases, still covering maximum requirements.

In short it is the process of taking all possible test cases and placing them into classes. One test value is picked from each class while testing.

E.g.: If you are testing for an input box accepting numbers from 1 to 1000 then there is no use in writing thousand test cases for all 1000 valid input numbers plus other test cases for invalid data.

Using equivalence partitioning method above test cases can be divided into three sets of input data called as classes. Each test case is a representative of respective class.

So in above example we can divide our test cases into three equivalence classes of some valid and invalid inputs.

Test cases for input box accepting numbers between 1 and 1000 using Equivalence Partitioning:

1) One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a valid test case. If you select other values between 1 and 1000 then result is going to be same. So one test case for valid input data should be sufficient.

2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid input data test case.

3) Input data with any value greater than 1000 to represent third invalid input class.

So using equivalence partitioning you have categorized all possible test cases into three classes. Test cases with other values from any class should give you the same result.

We have selected one representative from every input class to design our test cases. Test case values are selected in such a way that largest number of attributes of equivalence class can be exercised.

Equivalence partitioning uses fewest test cases to cover maximum requirements.

Boundary value analysis:

It’s widely recognized that input values at the extreme ends of input domain cause more errors in system. More application errors occur at the boundaries of input domain. ‘Boundary value analysis’ testing technique is used to identify errors at boundaries rather than finding those exist in center of input domain.

Boundary value analysis is a next part of Equivalence partitioning for designing test cases where test cases are selected at the edges of the equivalence classes.

Test cases for input box accepting numbers between 1 and 1000 using Boundary value analysis:

1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 1000 in our case.

2) Test data with values just below the extreme edges of input domains i.e. values 0 and 999.

3) Test data with values just above the extreme edges of input domain i.e. values 2 and 1001.

Boundary value analysis is often called as a part of stress and negative testing.

Note: There is no hard-and-fast rule to test only one value from each equivalence class you created for input domains. You can select multiple valid and invalid values from each equivalence class according to your needs and previous judgments.

E.g. if you divided 1 to 1000 input values in valid data equivalence class, then you can select test case values like: 1, 11, 100, 950 etc. Same case for other test cases having invalid data classes.

This should be a very basic and simple example to understand the Boundary value analysis and Equivalence partitioning concept.

Cause-Effect Graph:

Cause-Effect Graph graphically shows the connection between a given outcome and all issues that manipulate the outcome. Cause Effect Graph is a black box testing technique. It is also known as Ishikawa diagram because of the way it looks, invented by Kaoru Ishikawa or fish bone diagram.

It is generally uses for hardware testing but now adapted to software testing, usually tests external behavior of a system. It is a testing technique that aids in choosing test cases that logically relate Causes (inputs) to Effects (outputs) to produce test cases.

A “Cause” stands for a separate input condition that fetches about an internal change in the system. An “Effect” represents an output condition, a system transformation or a state resulting from a combination of causes.

The Cause-Effect Diagram can be used under these Circumstances:

• To determine the current problem so that right decision can be taken very fast.
• To narrate the connections of the system with the factors affecting a particular process or effect.

• To recognize the probable root causes, the cause for a exact effect, problem, or outcome.

Benefits of making cause-Effect Diagram

• It finds out the areas where data is collected for additional study.
• It motivates team contribution and uses the team data of the process.
• Uses synchronize and easy to read format to diagram cause-and-effect relationships.
• Point out probable reasons of difference in a process.
• It enhances facts of the procedure by helping everyone to learn more about the factors at work and how they relate.
• It assists us to decide the root reasons of a problem or quality using a structured approach.

Steps to proceed on Cause-Effect Diagram:

Firstly: Recognize and describe the input conditions (causes) and actions (effect)

Secondly: Build up a cause-effect graph

Third: Convert cause-effect graph into a decision table

Fourth: Convert decision table rules to test cases. Each column of the decision table represents a test case

Decision table testing: 

A decision table is a good way to deal with different combination inputs with their associated outputs and also called cause-effect table. Reason to call cause-effect table is an associated logical diagramming technique called ’cause-effect graphing that is basically use to derive the decision table.

Decision table testing is black box test design technique to determine the test scenarios for complex business logic.

We can apply Equivalence Partitioning and Boundary Value Analysis techniques to only specific conditions or inputs. Although, if we have dissimilar inputs that result in different actions being taken or secondly we have a business rule to test that there are different combination of inputs which result in different actions. We use decision table to test these kinds of rules or logic.

Advantage of decision table technique:

1. Any complex business flow can be easily converted into the test scenarios & test cases using this technique.
2. Such type of table are work iteratively, means the table created at the first iteration is used as input table for next tables. Such iteration can be carried out only if the initial table is unsatisfactory.
3. Simple to understand and everyone can use this method design the test scenarios & test cases.
4. It provide complete coverage of test cases which help to reduce the rework on writing test scenarios & test cases.
5. These tables guarantee that we consider every possible combination of condition values. This is known as its “completeness property”.

Error guessing

• The Error guessing is a technique where the experienced and good testers are encouraged to think of situations in which the software may not be able to cope. Some people seem to be naturally good at testing and others are good testers because they have a lot of experience either as a tester or working with a particular system and so are able to find out its weaknesses. This is why an error guessing approach, used after more formal techniques have been applied to some extent, can be very effective. It also saves a lot of time because of the assumptions and guessing made by the experienced testers to find out the defects which otherwise won’t be able to find.
• The success of error guessing is very much dependent on the skill of the tester, as good testers know where the defects are most likely to be.
• This is why an error guessing approach, used after more formal techniques have been applied to some extent, can be very effective. In using more formal techniques, the tester is likely to gain a better understanding of the system, what it does and how it works. With this better understanding, he or she is likely to be better at guessing ways in which the system may not work properly.
• Typical conditions to try include division by zero, blank (or no) input, empty files and the wrong kind of data (e.g. alphabetic characters where numeric are required). If anyone ever says of a system or the environment in which it is to operate ‘That could never happen’, it might be a good idea to test that condition, as such assumptions about what will and will not happen in the live environment are often the cause of failures.
• A structured approach to the error-guessing technique is to list possible defects or failures and to design tests that attempt to produce them. These defect and failure lists can be built based on the tester’s own experience or that of other people, available defect and failure data, and from common knowledge about why software fails.