Priya found four bugs that mattered. Real ones, the kind that would have hit a payments flow in production: a rounding error in partial refunds, a timeout that left a transaction in limbo, two others that had been sitting in the system for months. She found them by doing one week of deep exploratory testing instead of writing new automation.
Her manager’s first question in the next 1:1 was not about the bugs. It was whether she was moving away from automation now.
Those two facts should have had nothing to do with each other. A person found critical defects. A person’s career trajectory came under quiet review. Yet in most testing organizations, those two things are tightly, almost automatically, connected. Why.
Organizations promote what they can see
Automation leaves evidence behind. A test suite, a pipeline, a framework other people adopt and point to. Someone can look at it in a sprint review, a performance packet, a GitHub profile, and immediately understand what was built.
Exploratory judgment does not leave the same trail. When it works, what you get is an absence. A bug that never shipped. An incident that never happened. Nobody writes a Jira ticket for the outage that did not occur because someone spent two days poking at an edge case out of a bad feeling. The work is real, the value is real, but it becomes visible mainly in the moment it is missing.
So when a team has to decide, often without meaning to, what growth looks like, it defaults to the thing it can point at. Not because leadership sat down and decided exploratory testing matters less. Because code is easy to measure and judgment mostly is not, until it fails.
That same week Priya was hunting timeout bugs, a teammate spent the sprint reducing CI runtime from forty minutes to nine. Nobody asked him where his career was headed. His work was visible by design.
One job title, one direction
Here is where it gets structural rather than personal. Most organizations do not actually have four or five distinct testing disciplines with their own ladders. They have one job called tester, sometimes split into junior and senior, and inside that single bucket, progress has to be represented somehow.
Proximity to code becomes the default measuring stick, not because anyone decided functional testing is worth less, but because a single ladder can only encode one kind of movement clearly.
Risk analysis, exploratory depth, the instinct for where a system is about to break, none of that fits neatly onto the same axis as commits and pipeline ownership. So it does not show up on the axis at all.
Priya was not choosing to step backward. She was doing work that had no lane built for it.
The part that stays invisible even in the roles built to fix this
A lot of organizations think they have already solved this by creating hybrid roles, people who write automation and also do exploratory testing depending on what the week needs.
In practice, the hybrid role often does not rebalance anything. It just absorbs the imbalance quietly.
The person is doing more. They are being recognized for less of it.
The automation half of their week shows up in the metrics. The exploratory half, the part where they catch the thing the suite would have missed, gets folded into “other duties” or vanishes into general competence. Nothing about the underlying structure changes. The ladder still only rewards the visible half of the job.
Why organizations understand this and still do not fix it
Ask most engineering leaders directly and they will agree the incentive structure is lopsided.
Very few will actually build a real parallel track for exploratory and risk focused testing, with its own seniority levels and its own comp band.
Not because they cannot see the problem. Because fixing it costs something specific. It means paying invisible work at parity with visible work, which is a harder argument to win internally than it sounds. It means giving that track real standing on the org chart instead of a consolation title. It means building performance metrics for judgment calls that, by their nature, resist quantification, the same way “prevented an incident” does.
Avoiding all of that is the easier choice. Most organizations take it. Not out of malice. Out of the ordinary gravity that pulls any system toward what it can already measure.
This is bigger than testing
Once you see the pattern, it stops being a testing problem specifically. It shows up anywhere visible output and invisible judgment compete for the same recognition. The engineer who ships a feature gets noticed. The engineer who spent a week arguing the feature was the wrong one to build, and was right, rarely does. The designer who ships a screen is visible. The designer who prevented five bad screens from ever reaching a sprint is not.
Testing just happens to make the pattern unusually easy to see, because the two kinds of work sit right next to each other on the same team, doing the same job, under the same title.
Priya did not stop being an automation engineer. She simply did the kind of testing the product needed that particular week. The surprising part was never the work she chose. It was that the work immediately raised a question about her career. That says very little about testing. It says a great deal about how organizations quietly decide what counts as progress.
Top comments (0)