How UI Automation Works

An automated UI test is a program pretending to be a user: it finds the date field, types dates, clicks Book, and checks the total. Understanding how it does each of those — without writing a line of code — demystifies automation completely. It also explains the one word that haunts every automation team on earth: flaky. By page's end, you'll be able to look at a failing automated test and ask the question that matters: is the product broken, or is the test lying?

Keep a player piano in mind. The roll encodes the same keystrokes a pianist would make, replayed identically every time. Punch the roll wrong, and the music fails though the song is fine. Play it on a piano still being tuned, and same. Both failures will matter shortly.

Find, Act, Assert

Every automated UI step is one of three moves, looped. Find an element on the page — the promo field, the Book button. Act on it — type into it, click it. Assert — check that something is now true: the total reads $255.00. Here's TC-118's automated skeleton as a readable artifact (read, don't memorize — the prose after it carries everything):

open("/search?nights=3")
find(property "Juniper Inn").click()
find(promo field).type("SUMMER15")
find("Apply").click()
assert total == "$255.00"

In words: open the search page with a 3-night stay, find and click the Juniper Inn, find the promo field and type the code, click Apply, then assert — insist, with a pass/fail consequence — that the total equals exactly $255.00. Five lines, and every one is a find, an act, or an assert. That's the entire genre; everything else is detail on those three moves.

Locators: How a Program Finds a Button

The find move hides the craft. A program has no eyes — it locates elements by the page's underlying structure: by visible text ("the button labeled Apply"), by an identifier a developer attached, or by position in the page's structure ("the second button inside the third panel"). These recipes are called locators, and their quality decides a test's lifespan. Position-based locators are Chapter 5's brittle steps reborn: Lucy redesigns the checkout, the third panel becomes the fourth, and forty tests fail with nothing wrong. The professional fix is teamwork you can drive without coding: developers attach stable test IDs — invisible name tags on important elements, promised not to change — and tests find by tag. "Can we get test IDs on the checkout elements?" is a sentence a manual tester says in refinement, and automation engineers will love you for it.

Assertions: the Expected Result, Executable

The assert move is Chapter 5's law with the shrug removed. A machine cannot evaluate "the discount is applied correctly" — it can only compare values: total equals $255.00, error message contains "minimum 3 nights," booking status is pending. Every vague expectation that would have made a human test case weak makes an automated one impossible — which is why well-written manual cases automate smoothly and sloppy ones don't automate at all. Your Chapter 5 discipline was also, secretly, automation-readiness.

Waiting — and Why Tests Lie

Now the haunted word. Pages load in unpredictable time: the total appears after Paylane answers, after the page recalculates — 300 milliseconds usually, 3 seconds on a slow Tuesday. A test that asserts before the total updates fails — with nothing wrong with the product. Run it again: passes. That's a flaky test: one that fails sometimes without a product defect, usually from timing. The cure is waiting strategies — "wait until the total element updates, up to 10 seconds, then assert" — built into modern tools but still needing thought at every step that depends on something asynchronous. Flakiness matters beyond annoyance: a suite that cries wolf trains the team to ignore it, and an ignored suite catches nothing. "Just re-run it until it's green" is the road to that cliff — because the re-run habit also swallows real intermittent bugs, the timing and race-condition family from Chapter 6, which look exactly like flakiness until someone investigates.

The Tuesday Test

Fernway's first automated test — the TC-118 skeleton above — passes all week, then fails every Tuesday. Tuesday is deploy day; the staging environment is briefly slow; the test asserts before the recalculated total lands. Classic flake: the fix is a wait-until-updated, not a bug report. But notice what diagnosing it required: knowing deploy days (environment awareness, Chapter 2), reading the failure's pattern (it correlates with staging load, not with product changes), and re-testing manually to confirm the product was fine. That triage — real, flaky, or impostor — is a daily junior task on teams with automation, and it's manual-tester work: the machine reports red; a human decides what red means. You now know how to be that human.