The Manual Testing Process – The Steps Involved

Manual testing is performed by people working through a series of logical steps. The first step in the manual testing process is to become familiar with both the commissioning business and end user’s expectations of the product, and the final step in the manual testing process is the release of the product.

The entire process is time-consuming, but it is the human element that makes this form of testing successful in attaining a quality product. Manual testing is more straightforward to perform than automation because fewer technical skills are required, and there are no automation tools to learn or set up. However, testers do need to know about different manual testing techniques and test management tools. As with all types of software testing, the primary objective of manual testing is to compare the system against the defined requirements or user stories to identify bugs, then review the application and assist the development team in creating defect-free software.

Manual Testing Steps

All types of software testing fall into either the category of manual or automation. Whereas testing steps for both manual and automation testing overlap closely, the following steps apply directly to the manual testing process.

1. Requirement Gathering

The Testing process begins with understanding the application to be tested and what the end-user should expect from the product. This is done by reviewing all available documents, studying any existing systems and integrations, and by interacting with stakeholders to understand their business requirements.

Information gained from this study will drive the testing strategy and the testing implementation plan, so accessing extra resources such as having conversations with the developers as they run a demo of the product ahead of testing, can be highly useful. Development and QA working close by each other can be beneficial because daily integration allows each discipline to have a more natural grounding in how the other side works.

2. Sharing and Discussion

Now that various data on the software to be tested has been gathered and internalized, the next step is to consolidate and prioritize the information into usable components ready for use in creating test cases and test scenarios. The types of testing to perform, as well as the scope of testing and time available, must also be considered. The aim at this point is for QA to understand the software thoroughly, so sharing and discussing the state of play with different stakeholders can help to reveal untapped sources of data or useful lines of inquiry.

Having a visual snapshot of the software testing project that shows the full extent and minutiae of the situation can make the job of comprehension much easier for all involved. Across business in general, and increasingly so in software testing, mind maps are being used for creating basic route maps and reminders for this purpose. When trying to get to grips with overwhelm in everyday life, commonly heard advice is to write it all down. Mind maps are a more structured way of doing precisely this. For team leaders, mind maps can be valuable for sharing the overview with the team, who can also regularly update their testing status there as the project progresses. Mind maps do not replace proper test documentation and test status updates, but rather serve as a lightweight notebook to help with test planning and accountability.

3. Test Environment and Resources Setup

Because manual testing simulates the end-user experience, testing in a dedicated and well set up testing environment standardizes the product’s performance under lab conditions. It supports the discovery of bugs for rectification before the product is released.

Once the requirements are understood, and a basic framework of how to proceed is taking shape, the test environment can be prepared. By setting up well in advance, enough time can be factored in for obtaining and setting up manual testing tools, hardware, and other subsidiary materials and assets needed for the test runs. Planning also includes appointing those who need to be involved, making sure they have been notified, and that they calendarize the necessary time. Having everything in place and available at the start of testing in this way reduces the possibility of delays because of missing items or people.

4. Creating Test Scenarios and Test Cases

Following the analysis of requirements and user stories, understanding what and how to test will have become clear. For projects that adhere to process, documentation is necessary, which usually includes writing test cases. When test planning starts and documents have been shared with the team, testers review the specification documents in detail, gather in-depth knowledge about the scope of testing, and then create high-level test scenarios and detailed level test cases. Test cases provide instructional information on how and what to test, which data to use, and the expected output.

5. Test Execution and Defect Reporting

The pivotal activity in software testing is test execution. In manual testing, each test case is performed by one or more people who take action based on the instructions laid out in the test cases. The tester’s focus is to achieve the stated objective while noting any deviation between the expected and actual. Anything noticed that does not conform to the requirements will be recorded as a bug in the report, to be conveyed to the developers and the test case status for this item marked as fail.

6. Defect Retesting and Closure

Every failed test will be associated with a defect. The purpose of testing is not limited to identifying and reporting found defects, but also to ensure that all reported problems have been acknowledged, fixed, and then retested for confirmation. Once the developers have returned a fixed issue, it is the tester’s responsibility to retest the reported defect to confirm the fix so the ticket can be legitimately marked as closed. Testers are accountable for verifying any fixes, so once a returned defect is proven to have been fixed, it is the tester’s responsibility to update the status of the test cases. Before a test team can sign-off the product under test, all the test cases must be marked as passed.

7. Feedback and Recommendation

A system is tested before launch so all parties can learn about the overall quality of the product. The manual testing process concludes on the delivery of a test report to all shareholders. Before testing can be signed off, the results go through a feedback and recommendations process, which starts with testers self-checking their work for errors. It is advisable then for each tester to submit their work for peer and team leader review before all the results are consolidated into a test summary document. At this point, the team may make recommendations on any areas for improvement if needed.

The test report should contain all information about the testing status of the product tested, along with different testing metrics, a list of the areas tested, mention of any areas out of scope, and the non-testable items. The test report is then delivered to the Business Analyst (BA), and based on their understanding of the product from the customer’s viewpoint, they may offer feedback and make recommendations for how the testing or product could be improved.

8. Product Release, Test Cases and Repository Maintenance

Once it has been proved that the product functions successfully according to the requirements of the business owner, the item can be transferred to a release manager and scheduled for release. Although the product has now passed beyond QA, it may be returned if something fails after reaching the market place, or if any updates have been made to the product following review.

9. Updating test cases

In readiness for a possible round of regression testing, it is good practice to update and maintain the test cases on file in case the possibility should arise. This means exercising good version control so no obsolete test cases are run by mistake, or previously logged bug reintroduced.

Finally

Manual Testing Process can be relatively easy for testers to perform, but the quality and output of manual testing depends a lot on the thought process of the testers. The written coverage of test cases relies on their understanding of the requirement and how well user behavior is personified.