Growing Past the Page Object

There comes a point in every SDET’s career where the muscle memory has set in. You can spin up a new Playwright project before lunch. You can fix a broken locator in your sleep. You wrote the team’s page object pattern and people still mostly follow it. The framework hums. The suite is green. You are, by any measure, good at this.

And you’ve been at the same level for three years.

If that feels familiar, this post is for you.

In my last post, I argued that you should never become a software engineer who happens to test — you should be a tester who happens to code. That advice is for people stepping into the role. The problem is, once you’re a few years in and the day-to-day has stabilized into “write UI tests, fix UI tests, occasionally update the framework,” it is very easy to coast there indefinitely. The work is real. The work is also a plateau.

Getting past the plateau means getting past the page object. Here’s what’s been on the other side, for me.

Keep getting better at code

Yes, even though I just spent a whole post telling you not to over-index on this. Hear me out.

Coding skill compounds in a non-obvious way for testers. The better you get at code, the more of the application you can read — which means you can stop treating the system under test as a black box. You can crack open the controller, follow the service call, look at the data model, and ask questions nobody else on your team is asking. Why does this method swallow that exception? Why does this query not have an index? Why is this state being held in three places?

That’s not “writing more tests.” That’s understanding the thing well enough to know what to test. It’s the upgrade from “running the test suite” to “having an opinion about the architecture.” Devs notice the difference, and they start treating you accordingly.

Read the codebase you test. Not all of it — the parts that fail most often, the parts your team is shipping next, the parts that scare people. Twenty minutes of reading source per day will change your career within a year.

Test beyond the UI

The single biggest skill ceiling on most SDETs is that everything they know how to test happens through a browser.

UI tests have their place — In previous roles, I’ve written them daily (in fact, I’ll be giving a conference talk built around them soon) — but a senior SDET doesn’t only have a hammer. The layers below and around the UI are where the highest-leverage testing usually lives, and where most teams are under-invested.

Some directions to grow into:

• API and contract testing. The fastest, cheapest, most stable layer most teams under-use. Postman gets you started; Pact takes you further. If you can validate behavior at the API layer, you should — every time.
• Performance and load testing. Even baseline familiarity sets you apart. JMeter, Artillery, Gatling — pick one, run a test, learn what “p95” actually means in your application’s context.
• Accessibility testing. Both automated checks (axe-core, Lighthouse) and a manual screen reader pass. Most teams don’t have anyone who owns this. Be that person.
• Observability and synthetic monitoring. Tests that run forever, in production, against real infrastructure. If you’ve never written a synthetic check or read a Datadog dashboard during an incident, that’s a whole literacy waiting to be picked up.
• Analytics and data validation. Segment events, GA tags, data pipelines. Nobody owns testing this, which means it’s a layer where you can quietly become indispensable.

You don’t need to master all of them. Pick one that’s relevant to your product and go deep enough to be the team’s go-to.

Mine the postmortems

This is one of the highest-leverage habits I know, and almost nobody does it.

Every postmortem is a gift-wrapped test gap. Something broke in production. Someone wrote up what happened. The whole org reads it, nods, and moves on.

You read it differently. You read it asking: could a test have caught this? At what layer? Why didn’t it? Did we have one and turn it off? Did we have one and not trust it? Was this catchable at all?

Half the time the answer is “yes, and a unit test the dev didn’t write would’ve caught it” — which is a coaching opportunity for the next pull request. The other half, the answer is “no, this only shows up in production, and we need a better synthetic monitor or a better feature flag rollout strategy” — which is a strategy conversation you now get to lead.

Senior engineers are pattern-matchers. Reading postmortems is how you build the pattern library. Make a habit of it.

The ISTQB take

I am not, generally, a “get the cert” person. Certifications for the sake of certifications are a tax on your time and a credential I’ve never once cared about when interviewing.

But I’ll defend the ISTQB CTFL — the foundation-level syllabus — for one specific reason: it forces you to learn the vocabulary of testing. Equivalence partitioning, boundary value analysis, decision tables, state transition testing, error guessing, exploratory charters, the test pyramid, severity vs. priority, the difference between verification and validation. There’s gold in there, buried under a lot of dry exam prose.

You don’t need the cert. You need the syllabus. Download it. Read it cover to cover. Skim the parts you already know. Read the parts you don’t know slowly, twice. The reason these terms exist is that smart people noticed the same testing problems over and over and gave them names so we could talk about them. You don’t have to use the formal vocabulary in conversation, but you do have to know what it’s pointing at.

A senior SDET who can articulate why a test design uses boundary value analysis sounds different from one who can’t. Even if the syllabus reads like it was written by the world’s most committee-driven committee.

Get into the rooms where decisions are made

If you’re not already in your team’s architectural and design discussions, change that.

Ask your manager. Ask the developers’ manager. Ask the product manager or the business analyst. Phrase it however you want — “I’d like to weigh in on testability earlier” works fine. Most managers will say yes immediately. The only reason you’re not in those meetings is that nobody thought to invite you.

Once you’re in the room, your job is not to nitpick. Your job is to ask questions about testability and observability that nobody else is going to ask. How will we know if this works in production? What’s the failure mode if this third-party API is slow? Can we test this without spinning up the entire stack? Is there a feature flag we can roll back if this goes wrong? These are not gotcha questions. These are the questions that make designs better.

You will, over time, build a reputation as the person who catches problems at the design level rather than at the test level. That is a senior-shaped reputation, and it costs nothing to start building it on Monday.

Build the things that aren’t tests

The last move I’ll mention is the one that took me longest to learn: sometimes the right answer isn’t a test.

It’s a dashboard that shows the team’s flake rate over time. It’s a custom JUnit extension that shards tests sensibly across machines. It’s a small REST service that logs every test run so you can actually see patterns. It’s a linter rule that catches a class of mistake before code review. It’s an IntelliJ plugin that injects environment variables into run configs so the team stops tripping over the same setup mistake.

Senior SDETs build these things. They get cited in design docs. They show up in retrospectives as “the reason we caught X.” They make the org better in a way that one more UI test cannot.

When you spot one of those moments — we keep losing time to this same friction — that’s not a test. That’s a tool. Build it.

Past the page object

Coast or grow. Those are the two paths once your skills have stabilized.

The coasting path is comfortable. Writing more UI tests is fine work, and the work is real. But three years from now you’ll be a slightly more efficient version of who you were today, and the seat you sit in will look the same.

The growth path is harder, mostly because nobody hands it to you. You have to crack open code that isn’t yours, sit in meetings nobody invited you to, read documents nobody asked you to read, and build things that don’t show up in the test count.

That’s where the senior SDETs live. That’s the seat worth growing into.