Software Testing Techniques :

on

 Software Testing Techniques

Testing Techniques

What is Software Testing Technique?

Software Testing Techniques help you design better test cases. Since exhaustive testing is not possible; Manual Testing Techniques help reduce the number of test cases to be executed while increasing test coverage. They help identify test conditions that are otherwise difficult to recognize.

In this tutorial, you will learn 5 important software testing techniques:

Boundary Value Analysis (BVA)

Boundary value analysis is based on testing at the boundaries between partitions. It includes maximum, minimum, inside or outside boundaries, typical values and error values.

This black box testing technique complements equivalence partitioning. This software testing technique base on the principle that, if a system works well for these particular values then it will work perfectly well for all values which comes between the two boundary values.

Guidelines for Boundary Value analysis

  • If an input condition is restricted between values x and y, then the test cases should be designed with values x and y as well as values which are above and below x and y.
  • If an input condition is a large number of values, the test case should be developed which need to exercise the minimum and maximum numbers. Here, values above and below the minimum and maximum values are also tested.

Example:

Input condition is valid Between 1 to 10

Boundary values 0, 1, 2 and 9, 10, 11

Equivalence Class Partitioning

Equivalent Class Partitioning allows you to divide set of input data, into a partition which should be considered the same. This software testing method divides the input domain of a program into classes of data from which test cases should be designed.

The concept behind this technique is that test case of a representative value of each class is equal to a test of any other value of the same class. It allows you to identify valid as well as invalid equivalence classes.

Example:

Input conditions are valid between

 1 to 10 and 20 to 30

Hence there are five equivalence classes

--- to 0 (invalid)
1 to 10 (valid)
11 to 19 (invalid)
20 to 30 (valid)
31 to --- (invalid)

You select values from each class, i.e.,

-2, 3, 15, 25, 45

Decision Table Based Testing.

A decision table is also known as to Cause-Effect table. This software testing technique is used for functions which respond to a combination of inputs or events. For example, user should be logged in if enter valid email and password.

The first task is to identify functionalities where the output depends on a combination of inputs. If there are large input set of combinations, then divide it into smaller subsets which are helpful for managing a decision table.

For every function, you need to create a table and list down all types of combinations of inputs and its respective outputs. This helps to identify a condition that is overlooked by the tester.

Following are steps to create a decision table:

  • Enlist the inputs in rows
  • Enter all the rules in the column
  • Fill the table with the different combination of inputs
  • In the last row, note down the output against the input combination.

Example:




State Transition

This technique falls under the Black Box testing techniques


1.  Understand State Transition diagrams and State tables
2.  Derive test cases from the State Transition diagrams and State Tables
3.  Sequences – shortest, longest sequences
4.  Null or Invalid transitions

State-transition diagrams are very useful for describing the behavior of a system and are part of the Software Design Document.


Any system where you get a different output for the same input, depending on what has happened before, is a finite state system. For example, if you request to withdraw $100 from a bank ATM, you may be given cash. Later when you make the same request you could be refused money (because your balance is insufficient). This later refusal is because the state of your bank account has changed from having sufficient funds to insufficient funds. And the transaction that caused your account to change its state was probably the earlier withdrawal.

A state transition model has four basic parts:(consider the ATM example)
The states that the software may occupy (funded/insufficient funds);
The transitions from one state to another (not all transitions are allowed);
The events that cause a transition (withdrawing money); –> Inputs
The actions that result from a transition (an error message, or being given your cash). –> Output

The figure shows an example of entering a Personal Identity Number (PIN) to a bank account. The states are shown as circles, the transitions as lines with arrows and the events as the text near the transitions.



P.S: the picture has been taken from the internet.

Not all events have an effect in all states. Where an event does not gave an effect on a given state, it is usually omitted , but it can show as an arrow starting from the state and returning to the same state to indicate that no transition takes place; this is sometimes known as ‘null’ transition or an ‘invalid transition’.
eg. Invalid card entered

The state diagram shows seven states but only four possible events (Card inserted, Enter PIN, PIN OK and PIN not OK).
States: States can be numbered as S1, S2 or as alphabets A, B, C etc
S1:Start, S2:Wait for Pin, S3: 1st try, S4: 2nd Try, S5: 3rd Try, S6: access to account, S7: eat card


Events:
Event1:Card inserted, Event 2: enter Pin, Event 3: Pin OK, Event 4: Pin not OK
Actions : (not shown in the above example) could be : Messages on the screen – error or otherwise.

In deriving test cases, we may start with a typical scenario.
First test case here would be the normal situation, where the correct PIN is entered the first time. A second test (to visit every state) would be to enter an incorrect PIN each time, so that the system eats the card. A third test we can do where the PIN was incorrect the first time but OK the second time, and another test where the PIN was correct on the third try.

Or Test cases can be derived with sequences.


The smallest “sequence” is one transition at a time. The second smallest sequence is a sequence of 2 transitions in a row and so on.
Eg.:



S1:Start –> Event 1(Insert card)—-> S2:Wait for Pin

You could also test a series of transitions through more than one state.

Eg for 1-switch (2 transitions): [double or a pair of sequential transitions]



The coverage element for state transition testing is measurable for different lengths of transition sequences for eg. all single transitions covered, all double covered, all triple covered etc. This is measured with Chow’s n-switch coverage where n= sequential transitions -1.

As is obvious, the State Transition diagram only shows the valid transitions between the states. (All transitions not shown are considered invalid). And this is a limitation of deriving test cases from a State Transition Diagram.
In order to see the total number of combinations of states and transitions, both valid and invalid, a State Table can be used.

A state table is a matrix showing the relationships between all states and events, and resulting states and outputs.


The state table lists all the states down one side of the table and all the events that cause transitions on the top (or vice versa).


Each cell represents a state-event pair. The content of each cell indicates which state the system will move into when the corresponding event occurs in that state. This will include possible negative or error events – events that are not expected to happen in certain states. These are the negative test conditions.

We generate test cases by stepping through the ST. Each row/column intersection is a test case.


The State Table for the PIN example can be simplified as below:



Invalid or Null Transitions are represented as ‘-‘ in red in the table above.

Null or Invalid transitions are when the event has no effect on a state. We have put a ‘dash’ in the cells that should be impossible i.e. they represent invalid transitions from that state. Most of the invalid cells would be physically impossible in this case!

State transition testing is much used within the embedded software industry and technical automation in general. However, the technique is also suitable for modelling a business object having specific states or testing screen-dialogue flows (e.g.for internet applications or business scenarios)

Error Guessing

Error Guessing is a software testing technique based on guessing the error which can prevail in the code. The technique is heavily based on the experience where the test analysts use their experience to guess the problematic part of the testing application. Hence, the test analysts must be skilled and experienced for better error guessing.

The technique counts a list of possible errors or error-prone situations. Then tester writes a test case to expose those errors. To design test cases based on this software testing technique, the analyst can use the past experiences to identify the conditions.

Guidelines for Error Guessing:

  • The test should use the previous experience of testing similar applications
  • Understanding of the system under test
  • Knowledge of typical implementation errors
  • Remember previously troubled areas
  • Evaluate Historical data & Test results

Conclusion

  • Software testing Techniques allow you to design better cases. There are five primarily used techniques.
  • Boundary value analysis is testing at the boundaries between partitions.
  • Equivalent Class Partitioning allows you to divide set of test condition into a partition which should be considered the same.
  • Decision Table software testing technique is used for functions which respond to a combination of inputs or events.
  • In State Transition technique changes in input conditions change the state of the Application Under Test (AUT)
  • Error guessing is a software testing technique which is based on guessing the error which can prevail in the code


Comments

Post a Comment