Test Design Techniques

A test design technique provides an approach to design test cases, which helps to select a good set of tests from the total number of all possible tests for a given system.

There are many different types of software testing techniques. Each single technique is good at finding specific kinds of defect and comparatively poor at finding other types.

Test Design Techniques are used to recognize test conditions and test cases via which effective and proficient test cases can be written.

These techniques assist in attaining high test coverage and help in providing vision into the quality of a test object.

Types of Test Design Techniques:

[Figure: Test Design Techniques]

1. Static Testing Technique:

Static Testing is used to test software without executing the code. This includes, testing the work-products other than the code (typically requirements or specification documents) and the testing of code without actually executing it.

There are two types of Static Testing:

1.1 Review: used to discover and eliminate errors and ambiguities in documents before they are used in the development process, i.e. decreasing one cause of defects in the code.

Reviews are usually done manually.

• The types of defects most normally establish by reviews are:
  • Deviances from standards either internally defined or managed and regulatory/ legally defined by organization.
  • Requirements defects – e.g. requirements are vague, or omitted elements.
  • Design defects – e.g. design does not match the wants.
  • Insufficient maintainability – e.g. code is too complex to maintain.
  • Incorrect interface specifications – e.g. the interface requirement doesn’t match the design or the receiving or sending interface.

The kinds of review are created on the level of formality:

[Figure: Types of Reviews]

1.1.1 Informal review (least formal): No prescribed procedure for reviewing.

This may be documented though many informal reviews are not documented. The reviews provided may be valuable subject to who has piloted the review.

For e.g. the reviewer may not have technical skills however can ensure if the document makes sense. This is one of the low-cost ways of identifying a defect to attain a limited advantage.

1.1.2 Walkthrough: Review Sessions/meetings are organized by the writer of the document and are joined by the writer’s team members.

Sessions are open-ended with drive to facilitate learning about the content of the document under review, to assist team member’s to develop an understanding of the content of the document, and to find defects.

Walkthroughs usually explore scenarios, or conduct dry runs of code or process.

1.1.3 Technical review: Technical reviews are documented and is a precise defect detection procedure that comprises of team members and technical experts.

Reviewers organize checklists, and review report with a list of findings.

Technical reviews may differ from being informal to very formal and has a number of purposes, including discussion, decision making, evaluation of alternatives, finding defects, solving technical problems and examining conformance to requirements and standards.

1.1.4 Inspection (most formal): Inspections are run by a qualified moderator who is not the writer of the document and ordinarily involves individual inspectors working within defined roles.

The inspection process is formal, created on rules and checklists, and uses entry and exit criteria.

Pre-meeting preparation is important and comprises of reading of any source documents to confirm consistency.

An inspection report, with a list of findings is created, which contains ways to aid improvements to the procedure as well as fixing defects in the document under review.

1.2 Static Analysis

It allows code to be analysed for structural defects or systematic programming flaws which may lead to defects.

Static analysis is generally done automatically using tools. Like reviews, static analysis looks for defects without using the code.

Though, reviews static analysis is done once the code has been written.Its purpose is to find defects in software source code and software models.

Also Read: Test Case, Test Suite, Test Script, Test Plan

2. Dynamic Testing Technique

Dynamic Testing is to test the application or software at the time of execution which is done through the validation process. Dynamic techniques are sub-divided into:

 2.1 Specification-based (also known as ‘Black-box’ or ‘Behavioral’) Technique:

Specifications based techniques is testing the products against the requirements stated in the document.

It is also known as Black-box or input/ output driven testing techniques. These methods are based on test conditions and test cases derived from the Requirement Documents.

The five main types of Black-box techniques are as follows:

2.1.1 Equivalence Partitioning: In Equivalence Partitioning, the test cases are separated into valid data (values that are accepted) and invalid data (values that are not accepted) and only one test case of each is tested.

The equivalence partitioning technique takes benefit of the properties of equivalence partitions to minimize the number of test cases to be written.

Since all the values in an equivalence partition are handled in exactly the same way by a given program, we need to only test one of them as a representative of the partition.

For e.g. we have to test an ATM machine for withdrawal and the withdrawal limits are minimum $10 to a maximum of $100.

•       Input data is huge thus, we divide the data into three groups:
  • 0-$9 (values not to be accepted),
  • $10-$100 (values to be accepted) &
  • $101 and above (values not to be accepted).

So, we choose only one test case for each group and test. This is called Equivalence partitioning.

2.1.2 Boundary Value Analysis: Boundary value analysis is to find the fault in the boundary area.

Boundary values comprises of minimum value, maximum value, just inside boundaries, just outside boundaries.

It is comparatively easy to apply and its bug finding ability is high and can be applied at all test levels.

For e.g. we have a login ID box accepting 6 to 12 characters. With Boundary Value Analysis, we test for Minimum characters i.e. 6, Maximum characters 12, just inside boundaries that is 7 and 11, just outside boundaries that is 5 and 13.

2.1.3 Decision Tables: Decision Table deals with mixture of inputs generating a set of diverse results.

When creating decision tables, the requirements are analysed and conditions and actions of the system are recognized.

The input conditions and actions are mostly stated in ‘True’/ ‘False’ form. The pros of decision testing is, it generates a blend of conditions that may not have been otherwise exercised by testing.

For eg,

Follow the below steps to answer:

i) Match Conditions with existing rules as input

ii) When all conditions match in that example, confirm respective rule condition for that answer.

For example in test Case 1, Flyer member is available with Rule 1 and Rule 2. Now check for the travelling business class. Here only Rule 1 matches the condition. So, Rule 1 satisfies both Condition 1 and Condition 2. So, according to Rule 1, Test Case 1 offers upgrade to Class First.

2.1.4 State Transition Testing: State Transition Testing is used where some features of the system can be labelled as ‘finite state machine’.

It lets the tester to vision the Software in terms of its states, transition among states, inputs or actions that activate state changes and the activities which result from these transitions.

This testing is mostly used in embedded software’s and technical automation.

This technique is also good for modelling a business object with specific states or testing screen dialogue flows (internet applications or business scenarios).

For e.g. Entering Pin Number for ATM card.

[Figure: State Transition for entering Pin Number for ATM card]

2.1.5 Use Case Testing: Use case testing is one way of identifying functionality for business scenarios or process flows. It captures the individual exchanges between ‘actors’ and the system.

An actor denotes a specific type of user and the use cases capture the interactions that each user takes part in to generate some output, which is of value.

Test cases based on use cases at the business process level, often called scenarios and are mainly useful in exercising business rules or process flows and regularly identify gaps or flaws, which might have not been found by exercising individual components in isolation.

This marks use case testing very effective in defining acceptance tests as the use cases denote actual likely use.

2.2 Structure-based (‘White-box’ or ‘Glass-Based’) Technique:

Structure-based Technique is also called Glass based technique or White Box technique, as the testers  required to know how the software is applied and how it works.

It is a way of testing software that tests the internal configurations of an application. It is usually done at unit level.

Types of Structure based techniques:-

2.2.1 Statement Testing and Coverage: It is the valuation of the percentage of executable statements which have been exercised by a test case suite. This testing technique derives test cases to execute specific statements generally to increase statement coverage.

2.2.2 Decision Testing and Coverage: It is connected to branch testing, that is the percentage of decision outcomes that have been exercised by a test suite called Decision coverage.

2.2.3 Liner Code Sequence and Jump (LCSAJ): LCSAJ is a software analysis method used to identify structural units in code under test.

2.3 Experience-based Techniques:

People’s understanding, expertise and background are vital to test conditions and test cases in experience-based technique.

It uses the testers and users experience to identify the most significant areas of the system and to use these areas in a way, which is aligned with expected use and likely to be sites of errors.

This technique goes hand-in-hand with Specification based and Structure based techniques and is extensively used, where there is no specification document or specification is insufficient or outdated.

It is used in low risk systems and may also be used when there is extreme time pressure. There are two types:

Types of Experience based techniques:-

2.3.1 Error Guessing: Error guessing can discover a number of errors that systematic techniques may fail to identify.

This involves tester’s skills, intuition and knowledge in similar software to recognize special tests, which may not be found by formal techniques.

The chief disadvantage of this is, its unpredictable effectiveness as it dependent on the experience of the tester deploying it.

2.3.2 Exploratory Testing: This testing conglomerates experience of tester with an organized approach to testing, where requirements are absent/insufficient or when there is a time pressure.

It is the most efficient and effective approach which produces valuable results in first hours of testing and identify the biggest bugs faster than any other approach.

You now know what all types of test techniques are at your disposal, choose the best according to your need. Usually it is combination of some but don’t trust us, just keep an open mind and keep on exploring.

Do drop in your comments if you like the post or suggestions if any !!