Popular Software Testing Techniques With Examples

Read this in-depth tutorial with examples of various Software Testing Techniques available to perform software testing in a systematic manner:

Software Testing is one of the important aspects of the development of software. Without proper testing, the software developed can be a big failure.

Various Software Testing Techniques are available to carry out testing in a systematic way.

Software Testing Techniques

There are testing techniques that are used while testing a Project and have to be chosen appropriately.

Let’s discuss the testing techniques in detail.

Equivalence Partitioning

In equivalence partitioning, the input of a program is divided into classes. An equivalence class consists of Valid and Invalid states. It reduces the number of test cases as the main idea behind using Equivalence Partitioning is to have the same output from any of the values chosen from the classes created.

Guidelines for defining Equivalence Partitioning:

InputEquivalence Class

Specific ValueOne Valid and two invalid

Member of a setOne valid and one invalid

Range of ValuesOne Valid and two invalid

Example:

To find a square root of a given number which:

Should be a whole number
Should be between 10-50
Should be a multiple of 10

Derived Equivalence Classes:

1Number is a whole numberValid

2Number is not a whole numberInvalid

3Number is between 10-50Valid

4Number is less than 10
Invalid

5Number is greater than 50
Invalid

6Number is a multiple of 10
Valid

7Number is not a multiple of 10 Invalid

Test Case:

S.noTest DataExpected ResultClasses covered

130
True
1,3,6

25
False
4,7

315.5
False
2

456False
5

Boundary Value Analysis

This technique focuses on boundaries as a greater number of errors occur at the boundaries of the input domain. For example, the programmer chooses < rather than =< which would lead to defects.

Guidelines for Boundary Value Analysis:

InputValues to be tested

Range (Between X and Y)X-1, X, X+1, Y, Y+1, ,Y-1

Number of valuesMinimum number
Minimum number -1
Maximum number
Maximum number +1

Example:

Check the salary of an Employee whose maximum salary is 20,000 and minimum is 10,000.

Boundary Value specification will be:

{9999, 10000, 20000, 20001}

Test Case:

S.No Test Data Expected Result

1
9999False

210000True

320000True

420001False

Decision Table Testing

Decision table testing is also called Cause-effect graphing. It uses different input conditions (cause) and their system results (output/effect) in a graph which is further converted into a tabular form. This technique provides a comprehensive representation of conditions and their actions i.e. of cause and their effects.

Steps:

1. Causes (input conditions) and effects (actions) are listed for a module and a cause-effect graph is developed.
2. The graph is converted to a decision table.
3. The decision table is then converted to test cases.

Example:

If X stays at Y’s place. X has to pay rent to stay in Y’s house. If X does not have money to pay, then will have to leave the house.

Causes:

• C1 – X stays at Y’s place.
• C2 – X has money to pay rent.

Effects:

• E1 – X can stay at Y’s place.
• E2 – X has to leave the house.

Cause-Effect Graph:

Decision Table:

C1

11

C2
1

E1
10

E21

Test Scenarios:

1. If X pays rent, X stays at Y’s house.
2. If X does not pay rent, X has to leave Y’s house.

Exploratory Testing

Exploratory testing is all about exploring the application. Experienced testers can justify this testing technique with their experience and domain knowledge. Not much planning is required as the test cases are prepared while testing is being done. It requires minimum planning & maximum test execution.

This technique is used when the requirements documents are not available or they are partially available or it can be used once scripted testing is done to vary the testing process.

This requires more of a thinking process and tester’s intellectuality & smart work. As it involves exploring and testing approach, it helps to find critical defects at an early stage than any other approach as it gives freedom to the tester to test as they want and as per their intuition.

Functionality is checked in an ad-hoc manner i.e. tester chooses any functionality to test first rather than it is in a structured or systematic manner. Exploratory testing helps in finding unexpected defects.

Experienced Based Testing

Experienced-based testing comes into consideration when the requirements documents are not available or are inadequate or the time frame for delivering a product is very less.

In such situations, the experience of the tester matters a lot as the testers are the ones who can throw light on areas where maximum defects can be found and the areas where critical defects can be found from their previous experience on a similar application or product.

Every individual (Business or technical) involved in this testing technique should be experienced as they have a different point of view and approach towards different phases while developing a product.

Use Case Testing

What Is Use Case?

Use Case represents the different ways in which the system can be used by the users. The use case divides the system behavior into scenarios, such that each scenario performs some useful action from the user’s point of view.

Each scenario may involve a single message or multiple message exchanges between the user and the system to complete itself.

Representation of Use cases:

A use case is represented with actors and systems. The actor represents the user. In the Use case diagram, Stick represents the actor, and ellipses in the rectangle represent the Use case.

Use Case Testing:

Use Case testing is a technique wherein the use cases identify all the test cases that cover the complete system.

Example:

When a new user tries to create an account on a xyz website.

Main Success ScenarioStepDescription

A: Actor
S: System
1A:Enters mobile no

2S: Verifies mobile number & asks to put OTP

3A: Receives OTP and fill it on the site.

4S: Verifies OTP and asks to put password

5A: Puts the password

6S: Verifies the password

7A:clicks on sign up to create a account

Extensions2aIncorrect mobile number

A:clicks on sign up to

2bcreate a account

S: Displays message That user already exists

4aIncorrect OTP

S: Asks to enter valid OTP

4bcorrect OTP

S:accepts & asks to provide password

6aPassword does not match the criteria

S: Displays message “Incorrect Password”

First, a positive scenario that carries end-to-end testing is tested i.e. complete scenario of creating an account is tested. Afterward, negative testing starts i.e. if the mobile number is incorrect, the user will get a message for the same.

Once the user provides a correct mobile number, the system will send OTP to the user’s mobile number and the user will have to provide the same on the OTP field of the signup screen.

In case of incorrect OTP, the system asks to provide the correct OTP.

Once correct OTP is provided, the system asks to fill the password, and the password should match the criteria defined else it asks to fill the password again. Once the correct password is provided the system creates the user’s account by clicking sign up.

Check List Based Testing

Checklist based testing is done using a pre-prepared checklist which is prepared by experienced testers and it keeps on updating with any new defect found while executing the checklist test cases.

While delivering any change request or fix of any defect, the quick checklist is run to verify that no defect has occurred because of the new change. In case the time span available to deliver a product is less as a quick checklist can be of great help. This checklist is not related to User stories.

Given below is an example of a checklist for Usability testing.

Checklist for Usability testing of a Website:

• Web page content should be aligned properly.
• Web Page content should not have any spelling and grammatical errors.
• If any images, it should be as per the requirement and should be properly aligned.
• All fonts on the website should be as per the requirement.
• Clicking on the logo should take the user to the home page.
• There should not be any broken links.
• No orphan pages should be there on the website.
• The user should be able to navigate easily.
• A confirmation message should be shown on submitting, updating or deleting any data. The message should be appropriate and no spelling and grammatical mistakes should be there.
• The scrollbar should be available only if required.
• Text box, Radio buttons, drop-down, etc. should be aligned properly and should be accessible by keyboard.
• Dropdown data should not be truncated.
• The tooltip should be available in every field.
• Disabled fields should be grayed out.

Risk-Based Testing

A risk is an unfavorable event or circumstance that can occur while a product is being developed. Risk-based testing helps to detect the most important and critical bugs at an early stage.

This technique has focused on features or areas of a product that are more prone to risk. If any risk is not identified in time, then it can hamper the completion of the Project.

The very first step is to identify the risks and then to assess i.e. to prioritize and then to handle risks.

Once the risks are identified, the risk needs to be assessed to identify the risks in terms of their impact i.e. how much damage it can cause. The priority of any risk depends on the probability of occurrence & its impact on the product i.e. how severe the impact is.

Priority = Probability * Severity

If all the identified risks are prioritized, then it becomes easier to handle the more likely and critical risks first.

Risk Management should start at an early stage in the life cycle so that the risks can be handled at an early stage.

A project can be affected by various risks.

Few categories which can affect the project are:

Project Risks: Project risk includes Budget, Resource, Schedule, customer-related issues, etc.

Example: Planning includes 5 resources for testing with a timeline of 10 days. But for some reason, 2 resources go on leave and are not available for 10 days. This would lead to a delay in the release of the Project as the schedule will be affected because of the unavailability of 2 resources.

Technical Risks: Technical Risk includes risk in the design, implementation, testing & development phases.

Most of the technical risks occur either during the requirement phase or during the coding as while gathering the requirement if it is not understood clearly can lead to major risks while development. Secondly, in the development phase, if the developers do not have good knowledge of the Product, that can also lead to major risks.

Business Risks: Business risks include budget issues, building a project which is not what the customer required, losing a customer.

Risk Assessment: As discussed above, the risk is assessed on the basis of how severe the impact is.

Risk Control:

Risk can be controlled using three strategies:

• Risk Avoidance
• Risk Reduction
• Risk Transfer

Risk Avoidance: Risk avoidance is avoiding the risk of the project with the customer’s agreement. E.g. To avoid the risk of delayed delivery of the Project because of resource crunch, resources can be kept on the bench for a replacement if any resource goes on leave. The scope of work could be reduced for avoiding risks.

Risk Reduction: Risk reduction involves planning to handle the risks and to minimize their effect. E.g. To reduce risk, the incremental method should be used for delivering a Project.

Risk Transfer: This strategy includes buying insurance or any component developed by a third party to avoid risk occurrence by them.

Risk-based Testing Process:

The risk is identified & analyzed i.e. the impact & severity of risk is calculated and is taken care of as per the priority of the risk. Once the priority is finalized, the testing activity starts i.e. test scope & test plan are created and then test execution takes place.

User Journey Test

User Journey test as the name suggests cover’s the user’s complete journey through the system. It covers the end-to-end tests because of which the percentage of test coverage is more when compared to the other techniques.

This technique helps to reduce the number of test cases as the test cases are comprehensive & cover most of the functionality in one scenario. Scenarios are written for the most difficult journey. User journey tests are not connected to user stories.

Example: One of the user journey tests for a site:

A site like xyz.com has an important scenario as logging into the site, searching and exploring the product required, placing the product in the cart, and placing the order for the same by choosing the Payment option.

As for the user journey, first, the most critical scenarios are taken into consideration, this example covers the critical scenario as a failure at any point is one of the critical issues as the user would not be able to place an order. This would also help to find the defect early when compared to any other techniques.

User Story Testing (Agile)

A user story is a short and simple description of requirements from the customers or end-user. User stories are written by the Product owner as they are the ones who get the information from the customer for the product to be built.

If a user story is large, it is split into multiple smaller stories. User stories are written on Index cards and they are posted on the wall for discussion. While discussing the important aspects of the feature come up with the ones that are further used in the user story.

Acceptance tests are the final stage wherein the product is accepted by the customer, once it passes all the exit criteria.

Exit Criteria may include:

1. All critical & major defects are closed.
2. All the Test scenarios have been executed and their status is passing.

Acceptance criteria are defined by the Product Owner, PO can involve developers as well while defining the same.

Example:

User Story: XYZ site wants a Promotional text to be shown for 5 days on the top of the website in bold red color.

User Story: Test case

Acceptance Criteria:

1. Text should be the same as provided by the customer.
2. Text should be in the middle and top of the site.
3. Text Font and size should be Calibri and 10 respectively.
4. Text should be bold
5. The color of text should be red.
6. Text should keep on blinking.
7. Promotional text should not be available after a defined period of time.

Statement Coverage

In statement coverage, test cases are designed in such a way that each statement in the program is executed at least once.

The idea behind this technique is to find the defects present in any of the statements and that cannot be done unless all the statements are executed. Without executing a statement, we cannot find the actual reason behind the failure.

Branch Coverage

Branch coverage testing is also called EDGE testing. In this technique, the test cases are designed to cover all the branches and each branch condition returns true & false values in return.

Path Coverage

The Path coverage-based testing designs the test cases such that all the linearly independent paths in a program are executed at least once. A linearly independent path can be defined through the control flow graph. A control flow graph defines how the instruction of a program gets executed.

To draw a control flow graph, the statements are numbered and each numbered statement serves as a node of the graph. An edge is the control flow path between the two nodes.

Click here to get more details on Statement, Branch, and Path Coverage.

Conclusion

Software Testing techniques help in making testing easier as it helps to cover all scenarios.

Actually, it is not possible to test each and every value or functionality. But using techniques makes it possible to make sure that no aspect is left without testing and that too using fewer test cases i.e. techniques also helps in reducing the number of test cases.

Equivalence Partitioning, Boundary Value Analysis, Path Coverage, Branch Coverage, Statement Coverage come under Coverage-based techniques.

Equivalence Partitioning & Boundary Value Analysis techniques do not require coding knowledge whereas Path Coverage, Branch Coverage, Statement Coverage techniques require complete knowledge of coding.

Exploratory and experienced-based testing is a part of activity-based techniques as it focuses on how the testing would be done. User Journey test, User Story testing (Agile), Checklist based are agile techniques that are more in demand.