Manual and Automated Testing
Manual testing catches what a script cannot judge; automation repeats stable checks reliably at low cost. GullySystem decides the split feature by feature, so effort is not wasted automating what will change again next sprint.
Two Different Jobs, Not Two Tiers of Quality
Manual testing is a person deliberately working against the intended path, judging whether a layout looks right, an error message makes sense, or an edge case matters. Automated testing is a script repeating an exact sequence of steps and comparing the result to an expected value, at a speed and frequency no person can sustain. Neither replaces the other — the question is always which job a given check actually is.
How the Split Goes Wrong Without a Decision
- A screen still being redesigned gets an automated script that is rewritten as often as the screen itself
- Judgement-based checks — does this read clearly, does this look broken — get left to a script that cannot see either
- A team buys an automation tool and then has nobody free to write or maintain the scripts
- The same regression set is run by hand every release, costing the same hours each time for no extra insight
- Nobody decides, so testing defaults to whichever is easier that week rather than what the feature actually needs
How We Decide Which Is Which
Stability of the Screen
Automation is built for features that have settled. A screen still changing weekly is tested manually until it stops moving.
How Often the Check Repeats
A check run once, for one release, rarely earns back the cost of scripting it. A check run every release usually does.
Whether Judgement Is Required
Visual quality, tone of an error message, and anything requiring a human read stay manual regardless of how often it repeats.
Cost to Build Against Cost to Repeat
We estimate the effort to script a check against the hours it saves over the releases you actually expect, and show that working before recommending automation.
A Fitness Studio Chain, as an Example
A fitness studio chain rolling out class booking across locations has a booking screen changing weekly as new class types are added, alongside a login and payment flow that has not changed in months. The booking screen stays on manual and exploratory testing while it keeps changing. The login and payment flow — checked every release regardless — is where automation is built first, because it is the one part of the system that has stopped moving.
What You Are Left With
You receive both a manual test record for what was checked by a person, and automation scripts with the source and instructions to run and extend them, so the choice of what stays manual and what gets scripted remains visible and adjustable as your product settles.
Frequently asked questions
Should we automate everything to save money long-term?
No — automating a feature that keeps changing costs more than it saves, because the scripts are rewritten as fast as the screen is redesigned. Automation earns its cost on stable, repeated, high-value checks. We will tell you when a feature is not there yet rather than automate it anyway.
Can you start with manual testing and add automation later?
Yes, and this is the usual order. Manual and exploratory testing runs first while the product is still settling, and the checks that keep proving useful release after release become the candidates for automation once the screens they cover have stopped changing.
What drives the cost of a mixed manual and automated engagement?
For manual work, the number of journeys, roles and devices in scope. For automation, how many checks are being scripted, how complex the flows are, and whether the framework needs to be built from scratch or extends one you already have.
What decides how long each approach takes?
Manual testing depends on how many journeys and combinations are in scope and how quickly defects are fixed for retesting. Automation depends on how much the framework needs from scratch, how stable the underlying screens are, and how much needs wiring into your release pipeline.
Do we need our own automation tool license first?
No. We can work inside an open-source framework that carries no licensing cost, or inside a commercial tool you already hold a license for. The choice is made during scoping based on your team's familiarity and what you intend to maintain afterwards.
Who maintains the automated scripts after the engagement ends?
You do, if you choose to. Scripts are handed over with the source, the framework structure and written instructions to run and extend them. We can also continue maintaining them under an ongoing arrangement if your team would rather not take that on.
Tell us what you need.
Send a short brief and one of our engineers will come back to you — usually the same day.
- No obligation
- We reply the same working day
- Your details stay private