A script that has been running fine reports an error one morning. You spend a long time in the code and find nothing wrong. In the end the app has shipped an update, and a button has moved.
On a team that uses scripts, this almost has to happen. Someone else maintains the app. You do not control when it changes.
An update moves the targeting, and a silent update is harder to trace
The business logic is still there. What breaks is the set of coordinates the script uses to find its target.
Scripts usually locate by two things: position and an identifier.
Position is which row and which column, measured off a screenshot and written into the script. Move the interface and every coordinate is useless.
An identifier is a control ID or a control path. In principle it is steadier than coordinates, but an update often regenerates those as well. When the front-end framework is upgraded, control IDs change in batches.
The failure is often sudden. Fine yesterday, all of it down today. Nobody edited the script in between. The environment it runs in changed.
Harder than knowing it updated is not knowing.
Many apps update quietly. The phone upgrades on its own overnight once it is on Wi-Fi. The next day the script runs as usual, reports an error, and you go looking for a change you did not know had happened.
You cannot tell where the problem came from by asking whether there was a recent update. You have to work back from the error.
Reading the screen, and when you still have to edit
iEasyRun does not record coordinates. It reads what is on the screen.
Before each step, it reads the current page: which elements are there, and what text each one shows. It decides which one is the target, then taps it.
When an app changes, the two approaches differ here:
| Kind of change | Script with fixed coordinates | Reading the screen |
|---|---|---|
| A button moves | Breaks, needs setting up again | Fine |
| A menu gains or loses a level | Breaks, needs setting up again | Fine |
| Control IDs are regenerated | Breaks, needs setting up again | Fine |
| The page gains a dialog | Likely to get stuck | Usually closes it on its own |
| The button label changes | Unaffected | Add one line to the description |
| The flow itself gains a step | Breaks | Edit the flow |
The first four rows are the common cases in an update. The last two are the ones that need you, and they are much rarer.
Two cases need a hand.
The label changed. A button goes from “Export” to “Download”, or a menu goes from “Me” to “Profile”. It finds things by the text, and it does not recognise the new wording. Add the new wording to the description, for example “tap Export (some versions call it Download)”.
The flow itself changed. Export used to download straight away. Now there is an extra “choose format” confirmation. The text was read correctly. The business gained a step, and that stretch has to be added to the description.
Once those two are edited, they are done. They do not come back the way coordinates do, where every interface change means setting the whole thing up again.
After an upgrade, run it once on purpose. It will probably need no change, and the run confirms that. Low-frequency work especially needs the run. It might only run once every two months. Leave it unchecked and the problem shows up at the least convenient time.
The old scripts can stay.
Judge by how often things change:
- It runs every day, the flow has not changed in two years, and speed matters: a script uses fewer resources, so keep using it
- The interface iterates quickly, or you would rather not maintain it: run it from a description
- Somewhere between the two: leave it, and decide the next time it breaks
A lot of teams mix them. Core high-frequency flows stay on scripts. The surrounding work, the work that changes easily, and the low-frequency work run from a description. Both can run on the same phone. They do not conflict.
Less rework, and how to look when it fails
Two habits block most of the maintenance.
Describe the entry as what it does, not where it is. “Open my orders” holds up better than “tap the icon at the bottom right”. The first states the purpose. The second states a position, and positions change.
Turn the parts that change easily into parameters. The sentence shape, the keywords, and the target shop can differ every time. Make them values you fill in when you call the flow. Do not write them into the flow. On an update you only change the place that moved. You do not have to read the whole flow.
Look first at the screenshot of that step in Execution History.
That is more useful than reading the error text. The error usually only says “element not found”. The screenshot shows which page it was sitting on. When an update causes the problem, eight times out of ten it is sitting on a new page you have never seen.
Once you see that page, you know which line to add. For example, “if the XX page appears, tap skip first”.
The software is completely free and runs on your own computer. After an update, maintenance goes from retuning the whole thing every time to adding a sentence now and then. For more of this, see mobile UI automation testing and phone automation without writing code.
Frequently asked questions
- What is the most common cause of a failing script?
- Interface updates, by a wide margin. A button moves, a menu gains a level, an extra dialog appears, or control IDs get regenerated. None of it touches your business logic, but all of it breaks scripts that rely on fixed coordinates and control paths.
- Why does reading the screen avoid this?
- Because it identifies targets by meaning rather than position. A script knows the pixel at row 320, column 65. It knows the button labelled Export. Move the button and the meaning is unchanged, so it still finds it.
- When does it fail too?
- Two cases. The label changes, so Export becomes Download. Or the flow itself changes, such as an extra confirmation step. The first needs one added line, the second needs the flow edited.
- Should I re-verify after an app update?
- Worth doing. It will probably need no changes, but a confirmation run is cheaper than discovering the problem when business is affected. This matters most for low-frequency work that only runs every couple of months.
- Should the old scripts be deleted?
- No. High-frequency work with a completely stable flow and a need for speed is still more efficient as a script. Both approaches coexist on the same phone.
- The error just says element not found. How do I diagnose it?
- Look at the screenshot of that step in the execution history first. Where it actually stopped tells you more than the error text. Update-related failures usually look the same: it is sitting on a page you have never seen.
- Do silent app updates matter?
- Yes, and they are the harder case. Many apps update quietly in the background, so you may not know anything changed. That is precisely where position-based targeting suffers, because the change happened while you were not looking.
- How do I cut down on update-related rework?
- Two habits. Describe entry points as what they do rather than where they are. And make the volatile parts fillable parameters. Do both and a typical update costs one or two lines.
Script broken again?
Switch to a method that ignores coordinates
Software is completely free and runs on your own computer.