Manual testing is a software testing approach where testers manually evaluate software or application quality without the help of automated testing tools or test scripts. Testers interact with the system like how an end user would to identify bugs, defects, and issues in the software that create friction in user experience.
When a developer manually runs their application and tries out the features they have coded, they are doing manual testing. Its simplicity makes manual testing great for small-scale testing of personal projects. Even for large-scale testing where there are thousands and millions of items and features to test, manual testing is still needed to some degree.
Any type of testing can be executed both manually and with the help of an automation tool. The final decision to choose which approach lies in the nature of that specific test case. Several testing types that are usually done manually include:
Read More: Different Types of QA Testing
Let's see how manual testing is done at Facebook!
Now imagine that you are a manual tester whose task is to ensure that the Login page of Facebook works 24/7. What test cases will you carry out to achieve that goal?
Done?
Here is a non-exhaustive list for you:
Performance Test Cases:
For each of these test cases, you must manually perform every single test step it requires. For example, for the “Login in with valid credentials” test case, here are the test steps you need to take:
Navigate to Facebook Login Page
Enter Valid Credentials
Click on Login Button
Verify Successful Login
While that may seem like simple and straightforward steps, when you factor in the number of test cases to do, and the number of times these test cases must be re-executed (known as regression tests), the amount of effort required becomes more than enormous.
It is highly likely that these test cases are all automated to increase efficiency. Manual testing is actually reserved for the more complex scenarios.
Unlike manual testing, automation testing involves executing test cases automatically either through reusable test scripts or with the help automation testing tools.
Read More: What is Automation Testing?
Both manual testing and automation testing have their strengths and weaknesses. The choice between them depends on factors such as project size, complexity, frequency of testing, available resources, and the specific goals of testing.
In practice, a combination of both approaches often yields the best results, with manual testing for exploratory and usability aspects and automation testing for repetitive and resource-intensive tasks. You can have a look at the table below to better understand the differences between the 2 approaches:
Aspect | Manual Testing | Automation Testing |
Tester Involvement | Human testers execute test cases manually. | Automated tools execute test cases automatically. |
Test Case Execution | Test cases executed manually without tools. | Test cases executed by automation scripts. |
Suitable for | Exploratory testing, usability testing, | Regression testing, performance testing, |
Testing Types | Ad-hoc testing, small projects. | Large-scale testing, repetitive tasks. |
Human Intervention | Requires human intervention for each test case. | Limited human intervention after script setup. |
Error Prone | Prone to human errors and subjectivity. | Reduces human errors, increases repeatability. |
Project Scale | Suitable for small projects or when test cases change frequently. | Suitable for large and complex projects with consistent requirements. |
Efficiency | Time-consuming for repetitive or large-scale testing. | Efficient for repetitive tasks and regression testing. |
Initial Setup | Simpler initial setup; doesn't require scripting skills. | Initial setup requires scripting skills and may take longer. |
Adaptability | Offers more flexibility in adapting to changes. | Less adaptable to changes in the application. |
Speed of Execution | Slower compared to automated testing. | Faster test execution once scripts are set up. |
Read More: Manual Testing vs Automation Testing
In the long run, automation brings good ROI. According to the State of Quality Report 2024, “the percentage of respondents reporting high to very high ROI increases from groups adopting automation for less than a year to those exceeding five years”. In other words, although initially automation testing requires a lot of investment and training as compared to manual testing, the benefit is totally worth it over time.
→ Check out the State of Software Quality Report 2024 to get the latest industry insights
No matter what approach testers choose, they all have to follow the Software Testing Life Cycle (STLC), with the major difference being the execution step: manually or automatically.
Manual testing begins with requirement analysis, which provides the QA team with a comprehensive understanding of the test objectives, serving as the foundation for the creation of a test plan by the QA manager. This test plan includes detailed instructions for test execution (what area to cover in the test, how to test, what technology is required, resources to be allocated, timeline, roadmap, contingency plans, and expected outcomes). These 2 initial steps align stakeholders with the overall vision of the project and prepares them for the real test activities later.
Read More: Key Differences Between a Test Plan and a Test Strategy Document
After the configuration of the test environment, testers proceed with manual execution of the test cases as outlined in the plan, then communicate bugs found to the development team for the troubleshooting process. Let’s take a simple test scenario: Form Validation. The goal is to verify that form fields display appropriate messages and behave as expected. A manual testers should follow these steps to execute that test:
Expected results: the form displays an error message indicating that the input characters are not in the correct format of an email
This test case can get more complex depending on the business requirements. For example, a B2B company only wants to collect business emails and not personal emails, so they want to make sure that users type in emails without the “gmail.com” ending. In this scenario, testers will perform the test above once again, but they’ll type in a personal email (for example: john@gmail.com) then a business email (john@amazon.com) to see how the form behaves.
Another good example is manual insurance application testing, where the tester examines the policy creation functionality, ensuring that a new policy can be successfully created with accurate information and stored in the correct system. The following steps should be followed:
Expected Result:
In this scenario, testers need to have a list of policy details to enter. Manually entering a long list of data is exhausting, and may introduce human errors, so although manual testing is possible, having some supporting tools for these scenarios truly helps.
If you don't know which test cases to start with, here are the list of popular test cases for you. They should give you a good foundation of how to approach a system as a tester.
The recent decade has witnessed a tremendous shift in the Software Testing industry from manual testing to automation testing. Many people claim that manual testing belongs to the past, and manual testers will be replaced by automation testing tools, especially now that AI, Machine Learning, and many other disruptive technologies are on the rise.
Read More: AI Testing: The Future of Software Testing
In reality, that will not happen, at least not in many years to come. Manual testing plays an essential role in the software development life cycle, and will continue to do so, for several reasons:
To be human is to be creative and intuitive, and in certain types of testing those 2 factors are a must-have. For example, in exploratory testing, testers have to actively explore and interact with the software to “get to know” the application before deep-diving into the details. It is proven that this approach allows testers to uncover bugs that they don't even know of in the first place. You can read more on the research here.
It is a free-style approach with no rules, no specifications, no documentation, only the tester simultaneously learning about the product and pinpointing potential areas for further testing. Manual testing allows us to ask questions like “What if I do it this way?” - and this liberty of experimentation is something automation testing just won’t be able to deliver.
After that there is usability testing to evaluate how good the UX is, and machines can’t differentiate between “good” usability and “bad” usability. Automated test scripts don’t know that a text is illegible, a button is just visually unappealing or the placement of certain text next to certain images makes the instructions unclear.
Only a human tester with adequate product knowledge and, most importantly, real-world perspective, can identify that. Skipping these types of testing is risky for the release quality, and there is no workaround as we know of for now that doesn’t involve a manual tester.
Software development is a highly dynamic process with requirements constantly changing, and human testers can adapt to these changes quickly by adopting a new test approach.
For example, previously the requirement was simply to test the login functionality if it accepts valid username and password, but now the requirement includes password strength verification. With manual testing, testers only have to type in several combinations of passwords that meet and do not meet the password strength criteria (include capitalization, special characters, and exceed a certain number of characters) to see how the system responds.
With automation testing, the process involves updating the test scripts, updating the test data, executing the scripts, then checking the results, which are more technical-intensive and time consuming, especially in teams with limited programming expertise.
Moreover, the scenario above does not happen many times - it only needs to be tested once and for all - so automating such a test case is counterproductive. If the QA team decides that a changing requirement is a one-off event, it is better to just go with manual testing.
To do manual testing is to experience the application in the same way an end user would, and almost anyone can become an end user. Manual testers, of course, must have enough technical knowledge and experience to know how to best “break” the app, but other than that they don’t need programming skills or engineering expertise to create test scripts like an automation tester. The low learning curve of this approach allows teams to start testing quickly at limited resources.
Even in large scale testing projects with established infrastructure for automation testing, there can be test scenarios that are too complicated to be automated. Admittedly, automation testing is more ROI-positive in the long run than manual testing, but in too complex cases, technical limitation is truly a roadblock.
The happy path is the expected and ideal journey through a system or application where everything goes smoothly without any errors or issues. It's like following a clear and direct route to reach your destination.
Automation testing typically focuses on the happy path since its goal is to verify that the system or application functions correctly according to the intended design and requirements. To login and use all of the features correctly is staying on the happy path, but unexpected scenarios exist, and QA teams must account those scenarios into their test plan too. Manual testing allows them to venture into the “unhappy path” where error conditions are triggered and the system is put under the extremes.
With manual testing, the QA team must be creative to think of and test scenarios where users can potentially cause errors, such as malformed data, empty mandatory fields, or database connection failures. They also need to simulate extreme cases that cause system overload to see how it responds. These scenarios don’t happen frequently, but when they do, the consequence is huge, and manual testing is the best way to test them.
Automation testing requires upfront investment whether you choose to build an automation testing framework from scratch or buy a prebuilt automation testing tool from a vendor. We have written quite an extensive post comparing Katalon vs Selenium, a prebuilt tool vs a library to build automation framework. While the long-term savings and scalability is great, small projects, small businesses, and start-ups don’t want to add this to their already high short-term cost. Manual testing is a more reasonable choice here.
A huge roadblock to many automation testing adopters is the maintenance cost and effort. Many companies cut automation out of their techstack to escape the need for constantly revising their automation test scripts when their code changes, or else their test scripts become obsolete and no longer reliable. On the other hand, manual testing does not require any test case maintenance: when a code update occurs, testers can adapt immediately.
The more unstable the system is, the more important manual testing is. Humans can respond to unpredictability, but for automated test scripts, a slight change in the environment is enough to return false positives.
Despite all of the benefits mentioned above, manual testing still presents its own challenges. It is simple to see how manual execution of tasks gets progressively more resource-intensive as the project scales.
Manual testing involves executing test cases step-by-step, and the time it takes to perform each step depends on the speed of the human tester, who is greatly limited by their human physical capabilities. Humans can’t process billions of data points within a few seconds like a machine, and they are prone to error, fatigue, and distraction. When they make a mistake, they have to go back and correct it, further increasing the testing time.
The most time consuming activity is regression testing, where testers have to execute a large number of tests to verify if anything goes wrong after a code update. Regression testing involves re-executing a lot of test cases, such as the Login feature test. It is a really simple test, but having to manually login over and over every time the code gets updated is exhausting and counterproductive.
That’s not to account for the number of Operating Systems, browsers, and devices that testers have to run their tests on. The number of tests add up exponentially until it is humanly impossible. Over time, some QA teams even abandon some features to prioritize testing on more critical ones since they don’t have enough resources, leading to limited test coverage. which is a risky move.
Read More: How To Switch From Manual Testing to Automation Testing?
Another major issue with manual testing is that tests can’t be reused like automation testing where tests are stored as automation scripts, ready to be executed whenever needed. Manual testing usually can’t be recorded in any form except for documentation on test results or test planning. In other words, every test execution is a new execution, which is why sometimes testers happen to discover a bug but can’t replicate it.
Lack of test reusability results in 2 subsequent issues:
Without test management tools, manual testing efforts become a mess, since there is nowhere to document test cases or test scenarios and all test results are recorded by human testers with varying degrees of experience.
Many testers advocate for using Google Sheets to manage test cases, which makes sense because Google Sheets can be considered as an all-purpose management tool. Each row is a test step, and the next column is a dropdown of whether the test passed, failed, or was unable to be tested, and the next column to that is the environment (browser + OS). You can customize the sheet to be as detailed as your team wants it to be. Google Sheet is also great for collaborative test plan development.
In fact, Google Sheet has a default template for test management that everyone can immediately gain access to.
It was good, at first, for basic needs. But once again, when the project scales, managing everything on a single spreadsheet gets unnecessarily complicated, and having dozens of testers simultaneously tampering with the spreadsheet is just a hassle, especially when a function gets modified and all cells return an error. By this point, you would wish you have a more dedicated system designed for test management.
A good test management goes beyond what Google Sheet offers:
Katalon Platform is a comprehensive quality management platform supporting test management for both manual testing and automation testing on web, API, mobile across a wide variety of environments, all in 1 place, with minimal engineering and programming skill requirements.
Katalon is a great addition to your manual testing techstack, helping you manage your day-to-day testing activities such as preparing test cases, executing them, storing results, robust report generation for analytics, bug tracking, import/export test cases, and even JIRA integration for project management. It gives you the capabilities of all of the tools you use everyday with specific customization for testing.
For example, for test planning, once you have activated Katalon TestOps, you can create a test project and schedule a test release, with detailed information on test case status, start date, and release date. If you have a JIRA integration, you can click the “Populate JIRA release” button to import your existing JIRA test plan.
This integration allows for seamless synchronization of manual testing activities with bug tracking, project management, and other related tools, enabling better alignment between testing and development teams.
You can easily add your test cases in Katalon TestOps. The folders are displayed in a tree view in the left sidebar. Below is the Project Dashboard for the Web UI Tests Project for an eCommerce website, and in the Test Cases folder you can find the Order and check out a single product test case.
You can click on the test case to edit its details.
For reports on your manual testing efforts, Katalon highlights your testing activities with real-time data, which is categorized into 3 components: profile coverage (categorized by test profiles), execution trend (number of tests executed/passed/failed by day/week/month), and platform coverage (Mac, OS). These reports can all be shared automatically via email to the relevant stakeholders of your choice.
In addition to all of that, Katalon has a Slack - Microsoft Teams integration to allow you to send test reports to a Slack/Teams channel for enhanced collaboration and communication, resulting in a unified testing approach.
If you want to experience the Katalon Platform, there is a Free Forever version and 30-day Free Trial that allows you to fully enjoy its capabilities.
Start Testing With Katalon Platform Free Trial
The decision to prioritize manual or automation testing is based on factors like:
A general rule of thumb is that test cases with higher complexity and low repetitiveness should be conducted manually to ensure that there is human input to the test, while repetitive test cases are generally automated so that testers can focus on other value-generating activities
Manual testing does not require coding skills. Testers manually execute test cases and validate software functionality without writing code.
Test scenarios in manual testing are detailed descriptions of possible interactions, conditions, and actions that users might undertake with the software. They guide testers in conducting tests, ensuring various functionalities are adequately validated.
A user story in manual testing is a concise, informal description of a feature's functionality from an end user's perspective. It helps testers understand the context and purpose of testing, enabling effective test case creation.
To test a website manually, testers navigate through its various pages, functionalities, and features. They validate links, forms, user interactions, responsiveness, and visual aspects. Additionally, they perform boundary tests, input validations, and compatibility checks across browsers and devices.
Read More: A Complete Web QA Checklist