When a system changes, the business needs confidence that it still works. Should people check it manually, should software run the tests, or should the project use both?
The answer depends on the risks, how often the checks will be repeated and the effort needed to keep them useful. Automation can reduce repetitive work, but it also creates something the team must maintain.
What is the difference?
In manual testing, a person performs actions, observes the outcome and records what happened. They might follow a prepared script or explore the system to investigate unexpected behaviour.
In automated testing, software performs defined checks and compares the outcome with an expected result. These checks can run against individual business rules, interfaces between systems or a complete journey through the screen.
Both approaches need clear requirements and meaningful expected results. Repeating an incorrect check more quickly does not make it useful.
Where manual testing helps
People can ask questions as they test. Does a warning make sense? Can a warehouse colleague recover from an error? Does the process work when the delivery paperwork is incomplete?
This flexibility helps when requirements are still developing, the workflow is unfamiliar or the team needs feedback from operational users. Exploratory testing and usability reviews can reveal problems outside a prepared list of checks. These human activities remain valuable alongside automation. Ham Vocke’s Practical Test Pyramid describes this complementary role.
The drawback is repetition. Running the same checks after every release takes people’s time. Execution and record keeping can vary, and a large test pack can become difficult to complete within the available window. Manual scripts also need updating when the process changes.
Where automation helps
Automation is particularly useful for regression testing: repeating checks to see whether a change has damaged behaviour that previously worked. A project delivering frequent changes may benefit from running a dependable set of checks after each update.
It can also make it practical to check many combinations of input data and provide quicker feedback. However, a passing result only confirms the conditions and outcomes the test actually checks.
ISTQB’s guidance identifies reduced repetitive effort and faster test cycles as potential benefits, while also requiring consideration of initial and recurring costs. See its guidance on tool selection and return on investment.
The costs and concerns to allow for
Automated tests need design, suitable tools, test data and a reliable environment. Someone must investigate failures and update checks when screens, interfaces or business rules change. Open-source tools can avoid licence fees, but the people and infrastructure still cost money.
A failed test may indicate a product defect, an obsolete check or an environment problem. Repeated unreliable failures consume time and can reduce confidence in the results. Selenium’s own testing guidance stresses that browser automation tools do not themselves provide a well-designed test suite.
An industrial study of visual interface testing found that maintenance costs could be considerable and that the time to recover the investment depended partly on existing manual testing effort. Its findings concern a particular testing approach and two companies, rather than a universal savings figure. Alégroth, Feldt and Kolström, 2016.
A warehouse receiving example
Consider a project changing how supplier dispatch notices create expected receipts in a warehouse management system.
Useful automated checks might confirm that a valid notice creates the correct receipt, an unknown purchase order is rejected and importing the same notice twice does not create a duplicate. Repeating these checks after later changes could protect important business rules.
Operational users could then test whether the receiving screen is understandable, whether exception messages support the right decision and whether the process fits the work at goods-in.
This is an illustrative division of effort. It should follow the actual system, operational risks and agreed acceptance criteria.
Start with a small, measurable choice
A practical approach is to automate a few important, repeatable checks first. Compare the effort saved over the expected number of runs with the effort spent building, running, investigating and maintaining them. Include manual test preparation and maintenance in the comparison too.
Frequent releases and stable, valuable checks can strengthen the case for automation. A short-lived change with few repeat runs may favour manual execution. Rapidly changing screens may favour automating underlying rules or interfaces while people review the changing user journey.
The aim is a proportionate mix that provides useful evidence. Automated results support the acceptance decision; responsible people still decide whether the change is ready for business use.
Explore how requirements link to test cases and executable test scripts →