Testing Techniques


Testing Techniques


The test development process is the key parameter that the mangers and the testers should consider before starting to test the application. Most of you would have been learned about the testing techniques in your basic software testing training course in your college or other training institutes. However, I would like to explain more in detail about it for everyone to understand it easily. The technique used by the QA leads directly impact the quality of the application. Hence ample time should be taken by the QA Leads before initiating the testing.
Some of the categories of test design techniques are as follows:
  • Black-box test design technique
  • Specification-based test design technique
  • White-box test design technique
  • Structure-based test design technique
  • Experience-based test design technique

Lets see the most common test design technique which is followed in the software industry.

Specification-based/Black-box techniques: 

  1. Equivalence partitioning
  2. Boundary value analysis
  3. Decision table testing
  4. State transition testing
  5. Use case testing

 

Equivalence partitioning:

o Inputs to the software or system are divided in to groups that are expected to exhibit similar behavior
o Equivalence partitions or classes can be found for both valid data and invalid data
o Partitions can also be identified for outputs, internal values, time related values and for interface values.
o Equivalence partitioning is applicable all levels of testing

Example: 
The equivalence partitions are usually derived from the requirements specification for input attributes that influence the processing of the test object. An input has certain ranges which are valid and other ranges which are invalid. Invalid data here does not mean that the data is incorrect, it means that this data lies outside of specific partition. This may be best explained by the example of a function which takes a parameter "month". The valid range for the month is 1 to 12, representing January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.
        ... -2 -1  0 1 .............. 12 13  14  15 .....
      --------------|-------------------|---------------------
 invalid partition 1     valid partition    invalid partition 2


Boundary value analysis:

o Behavior at the edge of each equivalence partition is more likely to be incorrect. The maximum and minimum values of a partition are its boundary values.
o A boundary value for a valid partition is a valid boundary value; the boundary of an invalid partition is an invalid boundary value.
o Boundary value analysis can be applied at all test levels
o It is relatively easy to apply and its defect-finding capability is high
o This technique is often considered as an extension of equivalence partitioning. 
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.

Example:  
Test cases for input box accepting numbers between 1 and 500 using Boundary value analysis:
1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 500 in our case.
2) Test data with values just below the extreme edges of input domains i.e. values 0 and 499.
3) Test data with values just above the extreme edges of input domain i.e. values 2 and 501.

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

 

Decision table testing:

o In Decision table testing test cases are designed to execute the combination of inputs
o Decision tables are good way to capture system requirements that contain logical conditions.
o The decision table contains triggering conditions, often combinations of true and false for all input conditions
o It maybe applied to all situations when the action of the software depends on several logical decisions 
The limited-entry decision table is the simplest to describe. The condition alternatives are simple Boolean values, and the action entries are check-marks, representing which of the actions in a given column are to be performed.

Example: 

A technical support company writes a decision table to diagnose scanner problems based upon symptoms described to them over the phone from their clients.

The following is a balanced decision table.
Scanner troubleshooter


Rules
Conditions
Scanner does not print
Y
Y
Y
Y
N
N
N
N
A red light is flashing
Y
Y
N
N
Y
Y
N
N
Scanner is unrecognized
Y
N
Y
N
Y
N
Y
N
Actions
Check the power cable


X





Check the Scanner-computer cable
X

X





Ensure scanner software is installed
X

X

X

X

Check/replace ink
X
X


X
X



Of course, this is just a simple example (and it does not necessarily correspond to the reality of scanner troubleshooting), but even so, it demonstrates how decision tables can scale to several conditions with many possibilities.

 

State transition testing:

o In state transition testing test cases are designed to execute  valid and invalid state transitions
o A system may exhibit a deferent response on current conditions or previous history. In this case, that aspect of the system can be shown as a state transition diagram.
o State transition testing is much used in embedded software and technical automation.
Example:
Suppose you want to withdraw $500 from a bank ATM, you may be given cash. After some time you again try to withdraw $500 but you may be refused the money (because your account balance is insufficient). This refusal is because your bank account state has changed from having sufficient funds to cover withdrawal to having insufficient funds. The transaction that caused your account to change its state was probably the earlier withdrawal. A state diagram can represent a model from the point of view of the system or the customer.

A state transition model has four basic parts:
1. The states that the software may occupy (funded/insufficient funds)
2. The transitions from one state to another (all transitions are not allowed)
3. The events that cause a transition (like withdrawing money)
4. The actions that result from a transition (an error message or being given your cash)
 Please note that in any given state, one event can cause only one action, but that the same event from a different state may cause a different action and a different end state.

 

Use case testing:

o In use case testing test cases are designed to execute user scenarios
o A use case describes interactions between actors, including users and the system
o Each use case has preconditions, which need to be met for a use case to work successfully.
o A use case usually has a mainstream scenario and some times alternative branches.
o Use cases, often referred  to as scenarios, are very useful for designing acceptance tests with customer/user participation   

This is the simplest testing technique, the whole testing is carried out using the use case.


Join our community in Facebook and Google+ at the below URL's to stay up to date:


Facebook Page: http://www.facebook.com/SoftwareQaHelp
Google+ : https://plus.google.com/101680718973348361876

No comments:

Post a Comment