Common Manual Testing Techniques

What is Manual Testing?

Manual Testing is the process in which a software is tested to make sure it functions as intended.

Below are some common Manual Testing Techniques:

Exploratory Testing:

What is it?: Exploratory testing is done by exploring the app like an end user would do.

When do we use?: We use Exploratory Testing in the following cases:

1. When we have short period of time and have no enough time to write test cases, we use exploratory testing.
2. When we want to test the app like an end user would do, without knowing what the Functional Requirement Document says, we use exploratory testing. This way we explore the app and cover all scenarios an end user would encounter

How do we do?: We explore the application and note down any discrepancies/errors we see. We also note down all the scenarios we tested and make Exploratory Testing notes which we can deliver to the client, so one would know what exactly been tested and what sort of bugs have been discovered.

Experience Based Testing:

What is it?: Like the name suggests, Experience Based Testing is done based on one's own experience of the app or the domain. Its

When do we use?: We use Experience Based Testing in the following scenarios

1. If we don't have Requirement document, we follow experience based testing, to uncover bugs and to ensure the app works well
2. If we don't have enough time and needed to uncover all critical bugs
3. In early stage startups where the requirement is not stable, we use experience based testing

How do we do?: 'Error Guessing' is the common technique of Experience Based Testing. As an experienced tester, the tester would know where more bugs would occur and where the app might break. This way, its easy for the tester to uncover all the bugs from their past experience of the app, skill and intuition.

Blackbox Testing:

What is it?: Blackbox Testing is about testing the functionality of the app without knowing about how the application is built underneath.

When do we use?: Once the application is built, we do the blackbox testing by executing test cases and uncover any bugs.

How do we do?: First, we prepare test cases based on the Requirement Document. We will also have Requirement Traceability Matrix prepared to make sure all the requirements are covered in the test cases. Once the test cases are ready, we will execute them and make sure they all pass. In the case failure, we log bug and report to development team and all stakeholders.

Test case Design Technique:
In Blackbox Testing, we have the following major Test Case Design Technique.

**Equivalence Partitioning: **In Equivalence Partitioning, we divide the test data into equal parts and choose one data from each partition and test. This is useful when we have large number of data to test. For example: If we need to test age, we can partition it into 3 categories: Negative values, 0 to 18 and above 18. This way, we don't have to cover all possible values since its impossible and unnecessary.

Why Equivalence Partitioning:

1. We avoid redundancy by choosing only one number from a particular group
2. We make it efficient by only testing what would confirm the result
3. This also provides better coverage by testing for both valid and invalid data

Boundary Value Analysis:
In this technique, we check for errors at the boundary. For example, if only users above the age of 13 is allowed to create an account, then testers can derive test cases with values 12,13 and 14. Checking the boundary of a valid input ensures thorough testing and functions as most of the time there is likely to be an error at the edges of a valid input.

Decision Table Testing:

What is it? We use Decision Table for complex systems that has different outcomes for different combination of inputs
For example:

Conditions         Rule 1   Rule 2  Rule 3  Rule 4
Is New User?             Y    Y   N   N
Has Coupon?          Y    N   Y   N
Actions             
Apply 20% Discount   ✔            
Apply 10% Discount            ✔   
No Discount           ✔             ✔

How to Read this?
Rule1: If the user is New and has coupon, apply 20% discount
Rule2: If the user is New but has no coupon, apply no discount
Rule3: If the user is not new but has coupon, apply 10% discount
Rule4: If the user is not new and has no coupon, no discount

With the decision table, its easy to read and test complex rules and scenarios.

State Transition Testing:
We use this technique when the application involves going through several different states based on the previous actions and states.

For example: During ATM Pin validation, we display the choices based on the apps current state. If the current state is a welcome screen and if the user has entered right pin, then the application will show the next state which are options the user can carry out. If the user has entered a wrong pin, then it would show First-attempt failed screen. Below is the detailed state of each stage:

Current state            Event                    Next state           

Welcome screen         Enters right pin          Dashboard is shown

Welcome screen         Enters incorrect pin      First Attempt Failed

First Attempt Failed   Enters incorrect pin      Second AttemptFailed

Second Attempt Failed  Enters incorrect pin      Account Locked

Second Attempt Failed  Enters correct pin        Dashboard is shown

With state transitions clearly described, we can catch all the issues and also make sure it works in all the scenarios.

Use-case Testing:

In Use-case Testing, we start testing by writing use-cases from the requirement document. In this, we perform end-to-end testing, where we test from the beginning till the end of the flow uncovering any integration bugs or design defects.

Testers start by listing out all the posible usecases that an end-user might perform.

Benefits of use-case testing is that, it reduces the complexity of the system as the path of testing will be derived in the use-case document. Testing from the user's perspective is another good benefit to discover any bugs that lies in the typical path.

Some Drawbacks are that: As they are user-focused, some edge cases can be missed and 100% of the scenarios cannot be tested. Other thing is that it covers only functional part of the requirement. Aspects like performance and security cannot be covered.

Monkey Testing:

As the name suggests, in monkey testing, the tester would click random buttons, visits random pages, does random actions deliberately like a monkey would do in an aim to assert the application's stability and error handling capacity.

This would be helpful to discover some nasty workflows that would break the system. Its not possible to find these kind of bugs in a normal functional testing where focus is to ensure that the function works.

Monkey testing is necessary to make sure that the app works well even in any unpredicted steps that a user might carry out.

Future of Manual Testing in the Age of AI

In the age of AI, performing manual testing is made simple. Because we can use AI and write test cases in minutes. We can also take AI's help in thinking out all the possible scenarios including all sort of edge cases. Tester's efficiency is increased with the help of AI tools.

Following are some of the common AI tools we can use to write test cases in seconds:

• ChatGPT
• Google Gemini
• Claude

Though AI can analyse requirement, come up with test cases, implement them and run them, there are certain limitation. They are:

• They can't perform Exploratory Testing like an end user would do
• They can't do usability testing like a human would do
• They can't perform any testing that requires human intuition
• Though it generates Test cases, we may still require some manual editing as all of our instructions are not always followed no matter how good our prompts are. They are still in evolutional stage.

Verdict: Use AI but always double check how the actions are performed or created by AI as they are well prone to errors.