The discipline of finding out whether software works before customers do, and of saying how much confidence you have and why. It spans exploratory craft, automation engineering, API and performance testing, and the judgement to articulate release risk.
High demand24 min readQA engineer, SDET / test automation engineer, Quality engineer, Performance test engineer, QA lead / test manager, Exploratory and domain testerUpdated 2026-07-27
Assumes you know: Enough programming in one language to write loops, functions and classes, How an HTTP request and response are shaped, Comfort reading someone else's application from the outside
Overview
What this area actually covers
Testing is the practice of building an evidence-based opinion about whether a system does
what it is supposed to, and of saying honestly where that opinion is thin. The work divides
into designing what to check, executing checks by hand where a human's judgement is the
instrument, encoding checks as software so they can run on every change, exercising the
system under load, and reporting all of it in a form someone can act on.
Two things are worth separating early, because the interview separates them. Testing is
investigation: you learn something you did not know. Checking is confirmation: you assert
something you already expected. Automation is very good at checking and cannot do the
investigating, which is why an automated suite of two thousand assertions and a tester with
an afternoon and a curious mind find different classes of bug.
What gets wrongly bundled in is a long list. Writing unit tests is a developer responsibility
and should stay one; a QA function that owns unit tests has usually absorbed work that belongs
beside the code. Security testing beyond obvious input handling is its own discipline.
Accessibility conformance overlaps but has its own standards and specialists. And "QA" as a
gate that inspects finished work at the end is an organisational model, not a definition of
the field, and a declining one.
The most useful reframing for anyone entering the discipline is that the deliverable is not
defects. Defects are a by-product. The deliverable is information about risk, delivered early
enough and clearly enough that somebody can act on it. A tester who finds forty low-severity
issues and cannot say whether the release is safe has produced less value than one who found
three and can. Holding on to that distinction is what stops a career here from becoming a
queue of tickets.
This section is unusually wide because the discipline genuinely is. The first three
subsections are the thinking: vocabulary, test design and strategy. The next four are
automation, taken from principles through the two tool families that dominate hiring. The
next two are performance, split between running the test and interpreting the result. Then
mobile, then the coding round automation engineers face, then quality inside the pipeline, and
finally the judgement scenarios.
Subsection
What it is for
Testing Fundamentals
The shared vocabulary interviewers ask for verbatim
Manual & Functional Testing
Designing and running checks where a human is the instrument
Test Strategy & Planning
Deciding what to test, what not to, and when you are done
Automation Fundamentals
The principles that decide whether a suite is trusted or muted
Selenium & WebDriver
The long-established browser automation stack and its framework patterns
Playwright & Cypress
The modern browser tools and what their design changes
API Testing
Testing below the interface, where most defects actually live
Performance Testing
Modelling and applying load, and choosing the right kind of load
Performance Analysis & Tuning
Turning numbers into a named bottleneck rather than a complaint
Mobile Testing
Fragmentation, devices and the defects that only exist on a phone
SDET Coding Rounds
The programming interview automation engineers actually get
QA in CI/CD
Making quality signals part of the pipeline rather than a separate activity
QA Scenarios
Judgement under awkward constraints, which is most of the job
Testing Fundamentals covers the test pyramid, black-box against white-box testing,
severity against priority, and the software testing life cycle vocabulary. It is first because
a surprising share of QA interviews open with terminology asked word for word, and because
having precise definitions prevents the muddles that follow - severity is how bad the defect
is, priority is how soon it should be fixed, and the interesting cases are the ones where they
diverge.
Manual & Functional Testing covers test case design, equivalence partitioning and boundary
value analysis, exploratory charters, and defect reporting. It exists on its own because
designing a good set of cases is a formal skill with named techniques, not a matter of trying
things, and because a defect report that a developer can reproduce without asking a question is
a craft with a definite shape.
Test Strategy & Planning covers risk-based scoping, entry and exit criteria, estimation,
traceability and release sign-off judgement. This is the subsection that most distinguishes
senior candidates, because a strategy is an argument about where risk lives rather than an
inventory of what you will check. Expect material on how to justify not testing something.
Automation Fundamentals covers what to automate and what to leave alone, page objects,
locator strategy, waiting properly, and the root causes of flakiness. It is separated from the
specific tools because these principles decide whether a suite survives: teams rarely abandon a
suite because they chose the wrong library, they abandon it because it became unreliable.
Selenium & WebDriver covers driver architecture, synchronisation, framework design, grid
and parallel execution, and reporting. It remains a subsection of its own because an enormous
number of existing suites are built on it and interviews still probe it in depth, including
mechanics like the difference between implicit and explicit waits that cause real problems when
mixed.
Playwright & Cypress covers auto-waiting, fixtures and isolation, network interception,
tracing and what to consider when migrating. It is separate because these tools changed the
default ergonomics rather than just the syntax: auto-waiting removes a whole category of
flakiness, network interception makes deterministic tests possible without a full environment,
and trace viewers change how you debug a failure in CI.
API Testing covers contract and schema validation, authentication handling, data setup and
teardown, and the practical workflows around tools such as REST Assured and Postman. It gets
weight here because it is the level at which most functional checking belongs - faster, more
stable, and able to reach states a user interface cannot easily produce.
Performance Testing covers load against stress against soak testing, workload modelling,
the common tools including JMeter, k6 and Gatling, and reading percentiles honestly. It is its
own subsection because the hard part is deciding what load to apply and why, and because a test
that does not resemble real usage produces numbers that are precise and meaningless.
Performance Analysis & Tuning covers correlating client-side measurements with server,
database and runtime evidence to locate a bottleneck. It is deliberately split from running the
test, because these are different skills and the second is far rarer: plenty of people can
produce a report showing response times rose, and few can say which resource saturated and why.
Mobile Testing covers device and operating system fragmentation, Appium, the trade-off
between real devices and emulators, and the defects that only appear on a phone -
interruptions, permissions, network transitions, background termination. It is separate because
none of those failure modes exist on a desktop browser.
SDET Coding Rounds covers the data structures and algorithms questions and the code design
exercises that automation engineers are given, plus framework build-out tasks. It exists as a
subsection because the SDET interview is a developer interview with a testing flavour, and
candidates who prepare only testing material are surprised by it.
QA in CI/CD covers gating pipelines, test data management, parallelisation, environment
strategy and quality metrics. It is here because a test that runs nightly and is looked at
weekly is not a feedback loop, and because the operational questions - how tests get data, how
they run in parallel without colliding, what makes a build red - determine whether the suite has
any effect on behaviour.
QA Scenarios covers judgement situations: no requirements, no time, a suite everyone
distrusts, a production escape, a development team that does not want you there. It closes the
section because this is what the senior interview actually consists of, and because each
scenario has a defensible answer that is neither heroics nor refusal.
Where it sits in a real system
Quality information is only useful when it arrives in time to change a decision, so the layout
of this discipline is really a layout of feedback loops.
Where it happens
What it answers
How long you wait
Requirements and design review
Is this specifiable and testable at all
Minutes, before code exists
Unit and component tests, developer-owned
Does this function behave as its author intended
Seconds
API and integration tests
Do these services agree on the contract
Seconds to minutes
End-to-end tests in CI
Does a real user journey still complete
Minutes, and the most fragile signal
Exploratory session
What did nobody think to specify
An hour of a skilled person's attention
Performance test
Does it hold up at expected and unreasonable load
Hours, on an environment that resembles production
Production monitoring and escapes
What did we get wrong
After the fact, and the loop that closes the process
The cheapest bug to fix is the one caught in a requirements conversation, and the most expensive
is the one a customer reports, which is why the earliest row in that table is often the most
valuable and almost never the one an advertisement asks about. Notice too that the last row
belongs to this discipline. A production escape is data: it tells you which of your assumptions
about risk was wrong, and a team that never examines its escapes keeps testing the wrong things
carefully.
Choosing the level a check belongs at
The single most consequential routine decision in this discipline is which level a given check
belongs at, and it can be reduced to a short set of questions asked in order.
Loading diagram…
The branch that gets ignored is the last one. Not every risk deserves an automated test, and
routing something to monitoring or to a human session is a legitimate outcome rather than a
failure to automate.
The reason this matters so much is cost asymmetry. A check at the unit level runs in
milliseconds, fails for exactly one reason, and points at the line responsible. The same check at
the end-to-end level runs in tens of seconds, can fail for a dozen environmental reasons that
have nothing to do with the behaviour, and tells you only that a journey broke somewhere. Teams
that push checks upward accumulate a suite that is slow, noisy and eventually ignored, and the
damage is not the runtime - it is that a suite nobody trusts stops changing anyone's behaviour.
Test design, worked rather than named
Equivalence partitioning and boundary value analysis get recited in interviews far more
often than they get applied, so it is worth carrying one worked example. Suppose a
discount applies to orders of 5 to 20 items inclusive, and the field accepts an integer
between 1 and 99.
Partitioning divides the input space into groups where you believe the behaviour is
identical, so that testing one member of a group stands in for all of them. Here the
partitions are 1 to 4 with no discount, 5 to 20 with the discount, 21 to 99 with no
discount, and the invalid group of zero, negatives, values above 99 and non-numeric input.
That is four tests instead of ninety-nine, and the assumption you are making - that
behaviour really is uniform inside each group - is exactly the assumption exploratory
testing later goes hunting for.
Boundary analysis then adds the values at the edges, because that is where off-by-one
errors live.
Value
Partition
Why it is worth a test
4
Just below the discount band
Catches a boundary written as greater than 4 versus 5
5
First value in the band
The inclusive lower edge
20
Last value in the band
The inclusive upper edge
21
Just above the band
Catches an off-by-one at the top
0 and 100
Invalid
Validation boundaries, separate from the discount rule
Nine or ten cases derived this way give better coverage of the rule than fifty chosen by
intuition, and the derivation is something you can narrate. That narration is the point: an
interviewer asking you to design tests for a field is checking whether your cases come from
a method or from a list you remembered.
The life of a defect
Defect workflow is asked about constantly, partly because it is easy to ask and partly because
the transitions reveal whether someone has worked in a real team. The states themselves are
unremarkable; the interesting content is in the edges that are not the happy path.
Loading diagram…
The two transitions worth discussing in an interview are Rejected and Deferred, because both are
decisions about risk dressed up as workflow states, and a tester who accepts either without
recording the reasoning has lost the information.
A reopened defect is also a signal rather than an annoyance. A high reopen rate usually means
either that reports lack the environment and steps needed to reproduce reliably, or that fixes
are being made against symptoms rather than causes. Either way it is measurable and actionable,
which makes it a better metric than the raw defect count that organisations more commonly track.
The report itself has a definite shape, and it is worth writing out because "write a good defect
report" is a common practical exercise:
The line that most reports get wrong is Steps, because the author starts from the state their
browser happened to be in. A report that begins from a known starting state and assumes nothing
is the difference between a developer reproducing it in two minutes and sending it back with a
question.
Who does this work
A manual and exploratory tester is the person who knows the product and the domain better than
anyone building it. Their day is spent working through a change with a purpose in mind, following
the odd behaviour that appears halfway, and writing defect reports that a developer can reproduce
without asking a question. In a regulated setting they also carry traceability, evidence and
sign-off, where the record matters as much as the finding.
An SDET, or test automation engineer, is a software engineer whose product is the test suite and
the harness around it. They design framework structure, locator and page-object strategy, test
data setup and teardown, parallel execution, and the reporting that makes a red build
interpretable. They are interviewed like developers, with coding rounds, because that is what the
job is.
A quality engineer sits closer to the team and works on how quality is produced rather than only
measured: pairing on testability, arguing for a feature flag so a release can be de-risked,
improving the pipeline, reducing the time between a commit and a trustworthy signal.
A performance engineer models workload, runs load, stress and soak tests, and, crucially,
correlates client-side numbers against server, database and runtime evidence to name a bottleneck
instead of reporting that the system is slow.
Alongside them, product owners and business analysts specify acceptance criteria you will test
against, and support teams hold the escape data that should be shaping your priorities.
Role
Primary output
Interviewed with
Failure mode of the role
Exploratory tester
Findings and risk judgement
Scenario and test-design questions
Becomes a manual regression runner
SDET
A trusted suite and its harness
Coding rounds and framework design
Builds a suite nobody else can maintain
Quality engineer
Improved testability and faster feedback
Process and collaboration scenarios
Influence without authority, quietly ignored
Performance engineer
A named bottleneck with evidence
System and analysis questions
Reports numbers, never a cause
QA lead
A strategy and a release recommendation
Judgement and stakeholder scenarios
Signs off to keep the schedule
Demand, adoption and how that is changing
Demand is high and its composition is shifting sharply, and it does nobody a favour to be vague
about this. Roles defined purely as manual script execution are contracting: continuous delivery
makes a human regression pass at the end of every sprint arithmetically impossible, and
organisations respond by automating the repetitive confirmation. At the same time, roles that
combine testing judgement with the ability to write code, whether titled SDET, quality engineer or
automation engineer, are growing, and the salary and seniority ceiling sits there.
This is not a claim that manual testing is unskilled or obsolete, and anyone who tells you so is
describing script execution and calling it testing. Skilled exploratory testing is a genuine
expertise that automation cannot replace, because automation only asks questions you already knew
to ask. A tester who understands a domain, forms a hypothesis about where a change is likely to
have broken something and then goes hunting, finds the defects no assertion was written for. What
has contracted is the volume of undifferentiated repeat execution, not the value of investigation.
The practical consequence for a career is that the sustainable positions are exploratory depth plus
domain knowledge, or automation engineering, and often both.
Two further pressures are worth naming. Shift-left has genuinely moved a share of testing into
development, which reduces the number of people testing at the end while raising the bar for the
ones who remain. And AI tooling now generates test code and suggests cases readily, which lowers
the cost of producing checks without touching the harder questions: which checks are worth having,
whether the oracle they assert against is correct, and what the resulting suite means about release
risk.
That last point deserves expanding, because it changes what is scarce. When producing a check
becomes cheap, the constraint moves to maintaining and trusting the resulting suite. A thousand
generated assertions that nobody has reasoned about is not a thousand times the confidence of one
considered assertion; it is a maintenance liability with an unknown relationship to risk. The
skills that hold their value are deciding what deserves a check at all, knowing whether the
expected value being asserted is genuinely correct, and being able to say what a green build does
and does not prove.
What makes it hard
A test strategy is not a test suite, and confusing them is the most common gap in interviews. A
suite is an inventory of what you check. A strategy is an argument: this is where the risk lives,
this is how each risk is covered and at which level, this is what we are deliberately not testing
and why, these are the entry and exit criteria, and this is the residual risk we are accepting at
release. The reasoning about what not to test is the part that requires judgement, and it is the
part missing from most candidates' answers. If your strategy does not exclude anything, it is a
wish list.
Flakiness is the defining operational problem of automated testing. A flaky test is one that
passes and fails on unchanged code, and the harm is not the wasted rerun but the destruction of
trust: once a team learns to re-run red builds, the suite has stopped being a signal and become a
ritual. The causes are structural rather than mysterious, and each has a real fix:
Cause
Wrong fix
Actual fix
Race with an async UI update
Add a sleep
Wait on the condition, not the clock
Tests sharing mutable data
Run serially
Own your data; create and destroy per test
Order dependency between tests
Pin the order
Make each test independently valid
Brittle locator tied to layout
Broader XPath
Stable test-id or role-based selector
Time or timezone assumption
Rerun tomorrow
Inject a clock; never assert on wall time
Shared environment mutated by others
Ask people to stop
Isolate per run, or stub the shared dependency
Genuinely intermittent product bug
Retry the test
Report the bug; the test is right
The last row is why blanket automatic retries are dangerous. A retry policy quietly converts a real
intermittent defect into a green build, and the only honest way to run one is to record every retry
and treat a rising retry rate as a defect in itself.
Choosing the level of a test is a skill that takes years. Anything checkable through an API
should be, because it is faster, more stable and localises failure; the end-to-end layer should hold
only the few journeys whose value is in the integration itself. Teams get this wrong in both
directions, and the expensive version, a large end-to-end suite duplicating logic that a unit test
already covers, takes forty minutes to run, fails weekly for environmental reasons and eventually
gets muted.
Test data is the unglamorous problem that sinks suites. Every non-trivial test needs a system in
a particular state, and the four available strategies each fail differently: a shared seeded dataset
drifts and creates order dependencies, building state through the user interface is slow and
fragile, building it through the API is usually right but couples your tests to another team's
contract, and inserting directly into the database is fast and lets you create states the
application itself would never produce. Most mature suites use the API route for setup and reserve
direct insertion for edge cases, and being able to discuss that trade-off is a strong senior signal.
Performance and API testing are where testers differentiate themselves, precisely because they
are less crowded. Both need a mental model of the system rather than the interface. API testing
demands fluency in contracts, schema validation, authentication flows and data lifecycle, and it is
where you find the defects that never surface through a screen.
Articulating risk to a room is the highest-value skill in the discipline and the least practised.
At some point a release decision is made in a meeting, and the tester's job is to convert findings
into a form that non-testers can act on: what works, what does not, what was not covered, which
specific customer-visible consequence follows from shipping anyway, and what the fallback is if it
goes wrong. "It is not ready" is not information. "Payment by stored card works; new-card checkout
fails for one issuer, roughly four per cent of transactions; we have not tested refunds at all; I
would ship with new-card entry behind a flag" is. The best testers are the people who can do that
under pressure, without either over-claiming safety or hedging so heavily that nobody can decide.
Reading performance numbers honestly
Performance work is mostly workload modelling and honest statistics, and both halves are places
where confident people go wrong in ways that are easy to demonstrate.
Start with the statistics, because a mean response time hides exactly the population you care about.
Consider a hundred requests where ninety-five take 100 milliseconds and five take 4 seconds. The mean
is about 295 milliseconds, which sounds acceptable and describes nobody: no request took anything
close to it. The 95th percentile is 100 milliseconds and the 99th is 4 seconds, and the second number
is the one your largest customer experiences on their busiest page. This is why percentiles are
reported and means are not, and why a p99 quoted from a run of ten requests is meaningless - a
percentile needs enough samples for the tail to be populated at all.
Two more statistical traps come up in interviews. Percentiles do not average: taking the mean of the
p99 from each of five machines does not give you the system's p99, because the slow requests are not
evenly distributed. And a percentile measured per service is not the percentile a user experiences,
because a page that makes ten backend calls will hit somebody's tail on most page loads. The
arithmetic is worth doing once: if each of ten independent calls exceeds its p99 threshold one time in
a hundred, the probability that at least one of them does so is close to one in ten.
Then the workload. The distinction between the test types is not pedantry, because each answers a
different question:
Test type
Question it answers
Typical shape
Load
Does it meet its targets at expected volume
Realistic mix, held at target for a sustained period
Stress
Where does it break, and how
Ramp beyond expected until something fails
Soak
Does it degrade over time
Moderate load held for many hours
Spike
Does it survive a sudden arrival
Step change from low to very high and back
Soak deserves attention because it catches what the others cannot: memory that grows slowly, a
connection pool that leaks one connection per hour, a log partition that fills on day three, a cache
that never evicts. Those are the defects that produce a Sunday-morning incident three weeks after a
release that passed every load test.
Finally, the two mistakes that invalidate an entire run. The first is a load generator that saturates
its own CPU or network, which produces beautiful, worthless numbers describing the test harness rather
than the system. The second is a test environment that differs from production in a way that matters -
a smaller database, a different instance type, no realistic data volume, a cache that is warm because
the same hundred records are requested every time. Both are worth checking before you interpret
anything, and saying so unprompted is a mark of someone who has been burned.
Why study it
The honest case is that testing teaches a way of thinking about systems that is rare and valuable
anywhere: how software actually fails, where assumptions hide, how to reason about what evidence you do
and do not have. Developers who have done this work write better code, because they have seen what
breaks. Skilled testers also get unusual breadth, touching every part of a product and every team, and
domain knowledge accumulated this way compounds in a way framework knowledge does not.
There is also a practical route in. Testing remains one of the more open entry points into software, and
the path from testing to automation engineering, and from there to development or SRE, is well travelled.
Be clear about who should not bother. If you want to be a product developer, aim there directly rather
than routing through QA and hoping to move sideways, because the move is possible but not automatic and
some organisations will keep you in the box you arrived in. If you dislike being the bearer of unwelcome
news, or need work whose success is visible, be warned that this discipline is measured largely by
absence: nothing went wrong, and nobody thanks you for it. And if you are drawn only to the
automation-tooling side, you may be happier as a developer building test infrastructure than as a tester.
Your first hour
Pick a small application you did not write, ideally one with a real API, and spend fifteen minutes only
on paper. Write down five ways it could fail that would matter to whoever depends on it, ordered by how
bad each would be, and beside each write the level at which you would catch it: unit, API, end-to-end,
exploratory, or monitoring in production.
Then spend the rest of the hour testing the highest-ranked risk by hand, taking notes as you go. Do not
write a test script first; take a charter, one sentence stating what you are exploring and why, and
follow what you find. Keep a running list of questions the product could not answer.
A charter is worth getting right because it is the difference between exploration and clicking around.
It names a target, a purpose and sometimes a tool, and it fits in a sentence: "Explore the password
reset flow with expired and reused tokens to discover whether an old link can still be used." Time-box
it, take notes as you go rather than afterwards, and record the questions you could not answer alongside
the defects you found. Those questions are frequently more valuable than the defects, because each one
is a place where nobody has decided what correct means.
Your artefact is one page containing three things: that ranked risk list with levels attached, one defect
report good enough for a stranger to reproduce, with steps, expected, actual and environment, and three
sentences stating what you would tell a release meeting about this application's readiness. If the third
part feels harder than the second, you have just found the skill that separates senior testers from
everyone else.
What this is not
It is not a phase at the end of a project. Treating it that way is the model that produces adversarial
hand-offs, testers with no time and defects found at their most expensive.
It is not the same as knowing a tool. Selenium, Playwright, Cypress, JMeter and Postman are how the work
is carried out, and a candidate who can only name them, in a field where the interview asks how you would
test a feature with no requirements, has nothing to say. Nor is it a certification: a foundation syllabus
gives you shared vocabulary, which is genuinely useful because interviewers ask for those terms verbatim,
but it does not confer judgement.
It is not quality assurance in the literal sense either, despite the name. A tester does not assure
quality; the people who design and build the product determine it, and testing supplies the information
that lets them and their management decide. Believing otherwise leads to the position where a tester is
held responsible for an escape from a decision they advised against, which is worth noticing before you
accept a role framed that way.
Finally, automation is not a replacement for testing and coverage is not a measure of it. A hundred per
cent line coverage tells you every line ran, not that any of them was checked against a correct
expectation, and a suite full of assertions nobody has questioned can be green while the product is wrong.
Nobody can tell you a system is bug-free, so the useful question is never "did it pass" but "what do you
know, what do you not know, and what would it cost us if you are wrong".