Topic 9 — An introduction to automation and APIs

Goal: Understand where automation fits and grasp basic technical concepts for growth.

Lesson 9.1 — The Friday that ate Nadia's afternoon

Every Friday afternoon, FreshCart pushes its weekly release, and every Friday afternoon Nadia runs the same 80 checks by hand before it goes live. Add to cart. Apply FRESH10. Check the total. Pay with a test card. Watch the live tracking map load. Then again with a different cart, a different promo, a different card. By 4pm her eyes are glazing and she's terrified she's clicked past something.

Dev Okafor, the team's automation engineer, leans over her desk one of these Fridays. "You know a machine could do most of that in about four minutes, right?"

What he's describing is test automation: writing scripts — short pieces of code — that perform a test for you. The script opens the app, clicks the same buttons Nadia clicks, types the same inputs, and checks that the result matches what was expected. Press go, and it does in minutes what takes her a glazed-over afternoon. Better still, it can run every single time a developer changes the code, instead of only on Fridays.

Nadia isn't being asked to become a coder today. But the moment she understands what automation actually is, two things change: she stops dreading the repetitive part of her week, and she can finally follow what Dev and Priya are talking about in standup.

A manual tester decides what to check. An automation script just does the checking, fast, over and over, without getting bored.

Lesson 9.2 — What's worth automating (and what really isn't)

Dev offers to automate "all your testing." Marcus, Nadia's mentor, shakes his head before she can answer. "Not all of it. The boring, stable stuff. Leave Nadia the parts that need a brain."

That line is the whole skill of this lesson. Automation has a clear sweet spot: repetitive checks on features that don't change much — above all, regression testing (Topic 4), re-verifying that things that already worked still work after every new change. Nadia's Friday ritual is regression, and regression is exactly what a script does well: same steps, same expected answer, run a hundred times without complaint.

Now the other half, the part that gets new testers in trouble. Automation is not a magic replacement for a human tester, for three real reasons:

• It only checks what you told it to check. If the "Pay" button turns out neon green and overlaps the price, a script that was told "click Pay, confirm total = $24.30" will pass happily. It can't notice "that looks weird." Nadia can, in a glance.
• It's expensive to write and to maintain. Each script takes real time to build, and when the product changes — Priya renames a button, redesigns checkout — the script breaks and someone has to fix it. Unmaintained automation rots fast.
• It's poor at anything new, exploratory, or judgment-based. A brand-new feature with no settled behavior, a "does this feel right?" usability question, a hunch worth chasing — none of that fits a script.

So good teams automate the boring, stable checks and free the humans for exploratory testing, usability, and new features — the work that needs a person. Knowing which bucket a given test belongs in is itself a prized QA skill. When Nadia says "automate the 80 regression checks, but I'll keep hand-testing the new split-payment flow until it settles," she's thinking like a senior tester, no code required.

Lesson 9.3 — Meeting the tools (without writing a line of code)

Nadia doesn't need to use an automation tool this week. She does need to recognize the names, because they fly around every QA job ad and every standup.

The main UI automation tools all do the same core thing: they drive a real web browser — opening pages, clicking, typing, and checking what appears — the automated twin of the manual UI testing Nadia already does by hand. Three names dominate:

Tool	Where it stands today	Languages
Playwright	Fastest-growing and now the most-adopted — used by roughly 40–45% of teams in recent industry surveys (e.g. State of Testing 2026), with job postings up sharply year over year	JavaScript / TypeScript, Python, others
Cypress	Popular with JavaScript developer teams; great experience, narrower browser support	JavaScript / TypeScript
Selenium	The long-standing veteran with a huge enterprise install base; supports many languages	Java, Python, C#, and more

Two things to take from the table. First, these tools run on programming languages like JavaScript/TypeScript or Python — which is why the single biggest step from manual QA toward an automation or SDET (Software Development Engineer in Test) role is learning the basics of one language. Second, some tools offer low-code / no-code options: you record your clicks and the tool replays them, no typing of code required. That's a friendly on-ramp, and a fine place for a manual tester to dip a toe.

Here's the encouraging part Marcus keeps repeating to Nadia. The hard part of test automation was never the code — it's knowing what to test, which case matters, which edge to push. She already has that from eight years of catching prescription errors and a year of manual QA at FreshCart. Learning a language is real work, but she's bringing the rarer skill with her.

You can teach a tester to code far more easily than you can teach a coder to test well.

Lesson 9.4 — APIs, explained with a waiter

In her third standup, Priya says checkout "broke because the payment API returned a 500." Nadia nods along and quietly has no idea what an API is. By the end of this lesson she will, and so will you.

An API (Application Programming Interface) is simply how two pieces of software talk to each other. FreshCart's app doesn't run its own bank, and it doesn't draw its own maps. When you pay, the app asks a payment company's API to charge the card. When you track your order, it asks a maps API where the driver is. The app hands off the work and waits for an answer.

The picture that makes it click is a restaurant. You are the app. The waiter is the API. The kitchen is the other system. You don't walk into the kitchen and cook — you give your order to the waiter, who carries it to the kitchen and brings back your food. You never see the kitchen; you just get a reliable way to ask for things and receive them. That's all an API is: a defined way to send a request and get a response.

So when the payment API "returned a 500," the kitchen (the payment system) tried to fill FreshCart's order and something went wrong on their end. Nadia now knows that's not a button bug she can fix by clicking differently — it's a conversation between two systems that failed. That alone makes her more useful in the room.

Lesson 9.5 — Testing beneath the screen

Marcus pulls up a tool called Postman on his screen. "Watch. I'm going to test FreshCart's promo logic without opening the app at all."

He's about to do API testing: sending a request straight to the system and checking the response, beneath the visual interface — no buttons, no screens. Most web APIs work with a small, learnable vocabulary:

• Methods — the kind of request. GET fetches data (get me this order's status); POST sends data (here's a new order, create it).
• Status codes — the short answer that comes back. 200 OK means success. 404 Not Found means the thing you asked for does not exist. 500 Server Error means a server errored while handling the request: sometimes a third-party API like Priya's payment system, sometimes FreshCart's own backend. Either way it's a server-side fault, not your click.

Marcus sends a POST with cart total $30 and promo FRESH10, and reads the response: the API returns a total of $27.00 and a 200. The discount math is correct, and he never touched the app. He tries promo EXPIRED5 and gets back a clean 404 — exactly right, the code doesn't exist.

Why bother, when Nadia could just click through checkout? Three honest advantages. API testing is usually faster (no waiting for pages to paint), more stable (it doesn't break every time the button moves or gets restyled), and it catches problems closer to the source — if the discount is wrong in the API's answer, you've found the bug in the logic itself, not three screens deep in the UI. And Postman makes it approachable: you fill in a request and read what comes back, with no heavy coding required. Nadia leaves the desk having watched real testing happen one full layer below the screen she usually stares at.

Worked example — FreshCart's new same-day delivery promo

FreshCart launches SAMEDAY — 15% off any same-day order. Tom Reyes, the PM, writes the spec; the whole team has to make sure it ships clean. Watch automation and APIs each take their natural slot.

First, the what-to-automate call. The existing checkout regression — the 80 boring Friday checks Nadia used to grind through — is stable and repetitive, so Dev's Playwright suite owns it and reruns it on every code change in minutes. The brand-new SAMEDAY flow, though, is fresh and unsettled, so Nadia keeps it by hand for now: she's watching for "that looks weird," the thing no script would flag.

Next, the fast logic check. Rather than click through checkout a dozen times, Marcus opens Postman and hits the promo API directly. A POST with a same-day cart returns 200 and a 15%-off total — correct. A POST with SAMEDAY on a next-day cart should be rejected; the API returns it cleanly, no discount — correct. He's verified the rule beneath the screen in two minutes.

Then Nadia does what only a human can. She runs the real UI and spots that SAMEDAY stacks on top of FRESH10 for a double discount Tom never intended — a judgment catch, not a checklist item. She files it; Priya fixes the logic; Marcus adds an API test for the stacking rule so it can't silently come back.

One promo. A regression suite a machine guards, a logic rule checked at the API level, and a weird-looking edge a person caught. That blend — knowing which tool fits which job — is what this topic was built to give you.