QA and Testing

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.

The thirteen areas underneath

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.

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.

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.

flowchart TD
    A[A behaviour worth checking] --> B{Pure logic with no dependencies}
    B -- Yes --> C[Unit test, owned by the developer]
    B -- No --> D{Reachable through an API}
    D -- Yes --> E[API or integration test]
    D -- No --> F{Value is in the integration itself}
    F -- Yes --> G[End to end, and keep the set small]
    F -- No --> H[Exploratory session or production monitoring]

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.

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.

stateDiagram-v2
    [*] --> New
    New --> Assigned: triaged and accepted
    New --> Rejected: not a defect or duplicate
    Assigned --> Fixed: developer completes the change
    Fixed --> Retest: available in a test build
    Retest --> Closed: verified
    Retest --> Reopened: still present
    Reopened --> Assigned
    Assigned --> Deferred: real but not now

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:

Title       One line, specific: what fails, where, under what condition
Environment Build, browser or device, OS, environment name, account or role
Steps       Numbered, from a known starting state, no assumed context
Expected    What the requirement or reasonable behaviour says should happen
Actual      What happened, quoted exactly, including any error text
Evidence    Screenshot, video, log excerpt, request and response, trace id
Severity    Impact if it reaches a customer
Priority    A recommendation on when it should be fixed, and why

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.

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:

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:

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".