82 functional testing interview questions with answers

What they are assessing

Basic orientation.

Model answer

Testing that verifies the system does what it is supposed to do, by supplying inputs and checking the outputs and behaviour against the specification or the agreed acceptance criteria. It is concerned with what the system does rather than how well it does it, so response time, security and usability sit outside it. In practice it covers everything from a single field validation through to a complete business journey across several screens.

What they are assessing

The defining boundary, asked in almost every interview.

Model answer

Functional testing asks whether the system does the right thing. Non functional testing asks how well it does it: performance, security, usability, reliability, compatibility, accessibility and maintainability. The practical difference is that functional tests usually have a clear expected result you can compare against, while non functional ones measure a quality against a threshold. A transfer that moves the right money is a functional pass; one that takes forty seconds is a non functional failure of the same feature.

Likely follow-up

Can a test be both? Give an example.

What they are assessing

Basic vocabulary.

Model answer

Testing based on the specification and external behaviour without reference to the internal implementation. The tester supplies inputs and checks outputs, treating the system as opaque. Most functional testing is black box, and the main design techniques such as equivalence partitioning and boundary value analysis are black box techniques. The complement is white box testing, which uses knowledge of the code structure, and grey box, which uses partial internal knowledge such as the database schema or API contracts.

What they are assessing

Coverage thinking.

Model answer

Positive testing uses valid inputs to confirm the system does what it should. Negative testing uses invalid, unexpected or malicious inputs to confirm it fails safely: rejecting them, giving a meaningful message, and leaving data in a consistent state. Negative testing usually finds more defects, because the happy path has normally been exercised by the developer while the error paths have not. It is also where the costly defects live, since an unhandled error is how data gets corrupted.

Trap to avoid

Treating negative testing as only invalid field values. It also covers interruption, concurrency, missing permissions and dependency failure, which are where the serious defects are.

What they are assessing

A distinction frequently stated backwards.

Model answer

Verification asks whether we are building the product right: does it conform to the specification, the design and the standards. It includes reviews, walkthroughs and inspections as well as testing against the spec. Validation asks whether we are building the right product: does it actually meet the user need. A system can pass verification completely and fail validation, because the specification itself was wrong, which is exactly what user acceptance testing exists to catch.

Likely follow-up

Which one does UAT belong to, and why?

What they are assessing

Conceptual honesty, which interviewers value at senior level.

Model answer

No. Testing shows the presence of defects, not their absence, which is one of the core testing principles. Exhaustive testing is impossible for any non trivial system, because the input space and the sequence space are effectively infinite. What testing provides is evidence to support a risk judgement: we exercised these conditions and found these results, so the remaining risk is of this shape. A candidate who claims testing proves correctness is signalling that they have not thought about coverage seriously.

What they are assessing

Standard structure.

Model answer

Unit testing of individual components, usually by developers. Integration testing of the interactions between components or services. System testing of the complete integrated system against its requirements, which is where most functional testing by a QA team happens. And acceptance testing, where the business or users confirm it meets their needs. Each level has a different scope, a different owner and finds a different class of defect, which is why they are not substitutes for one another.

What they are assessing

Depth on the level most often skipped.

Model answer

Testing that components work together correctly, focusing on the interfaces between them rather than the logic inside. The approaches are big bang, integrating everything at once, which makes defect isolation very hard. Top down, starting at the highest level using stubs for what is not built yet. Bottom up, starting with low level components using drivers. And incremental or sandwich approaches combining them. In modern service based systems the practical form is contract testing between services, which gives most of the value without needing everything deployed together.

Likely follow-up

What is a stub and what is a driver?

What they are assessing

Purpose rather than just position in the sequence.

Model answer

System testing verifies the complete system against the specified requirements, and it is performed by the testing team in a controlled environment. User acceptance testing validates that the system meets the business need, and it is performed by or with the business users using realistic scenarios and often their own data. The purposes differ: system testing asks whether it was built as specified, UAT asks whether it is usable and useful for the work it was bought to do. UAT finding a lot of defects usually means the earlier levels were weak, but UAT finding requirement misunderstandings is it working correctly.

What they are assessing

Strategy, with room for a considered opinion.

Model answer

The model says to have many fast unit tests, fewer integration tests and a small number of end to end tests, because the cost and fragility of a test rises as its scope grows. I agree with the principle, which is to push each check to the lowest level that can meaningfully verify it. Where I would qualify it is that the pyramid describes automated tests and says nothing about exploratory testing, which does not fit the shape at all, and that for systems which are mostly integration, such as a thin service orchestrating several others, the middle layer is legitimately the widest. Teams that invert it, with hundreds of end to end tests, invariably end up with a slow suite nobody trusts.

Likely follow-up

What does the shape look like for a system that is mostly integration glue?

What they are assessing

A very common pairing.

Model answer

Smoke testing is a broad, shallow check that the build is stable enough to test at all, covering the critical paths across the whole application, and it is usually scripted and often automated. Sanity testing is narrow and deep, verifying that a specific fix or change works and has not obviously broken its immediate area, and it is usually unscripted and done after a targeted change. Smoke answers should we accept this build, sanity answers did this particular change do what it claimed.

What they are assessing

Another pairing candidates routinely blur.

Model answer

Retesting is running the exact test that failed, against the fixed build, to confirm the defect is resolved. It uses the same data and steps, and it is never automated speculatively because you only know what to rerun once the defect exists. Regression testing is running other tests to confirm the fix has not broken anything that previously worked. Retesting is mandatory for every fix; regression scope is a judgement based on the risk and reach of the change.

Trap to avoid

Saying regression testing means running everything. Running the full suite is one strategy, and on most systems an impractical one, so the interviewer usually wants to hear how you select.

What they are assessing

Practical judgement, asked constantly.

Model answer

By impact analysis rather than by habit. I would look at what the change touches directly, what shares code or data with it, what calls it and what it calls, and what historically breaks when that area changes, since defect history is a strong predictor. Then I weight by business criticality, so the payment path gets covered even on a change that looks unrelated. The output is a tiered set: always run the critical path, run the impacted area in depth, and sample the rest. Where the change is architectural or touches shared infrastructure, that reasoning fails and a full regression is the honest answer.

Likely follow-up

How would you handle a change to a shared utility used in forty places?

What they are assessing

Scope understanding.

Model answer

Testing a complete business process across all the components and systems it touches, in conditions close to production, to verify the flow works as a whole. It typically spans several applications, interfaces and data stores, so it finds integration and data flow defects that component level testing cannot. It is valuable and expensive, so the discipline is to keep the number of end to end tests small and reserved for journeys that genuinely matter, because they are the slowest to run and the most fragile to maintain.

What they are assessing

Acceptance variants.

Model answer

Alpha testing is acceptance testing performed in house, at the developing organisation, usually by staff who were not involved in building it, in a controlled environment. Beta testing is performed by real users in their own environment, outside the organisation, before general release. Beta is valuable precisely because it uses conditions you cannot reproduce: real devices, real networks, real data and real workflows. Its weakness is that feedback is unstructured and reproduction information is usually poor.

What they are assessing

Precision about a term people use loosely.

Model answer

The happy path is the ideal flow with valid input and no errors. The critical path is the journey that matters most to the business, which usually includes the happy path but also its important variations and failure handling. They are not the same, and the distinction matters for prioritisation: a smoke suite built only of happy paths will pass on a build where every error case is broken, which is a build you would not want to ship. When I define a critical path set I include at least the main failure branch for each, because that is where users actually get stuck.

What they are assessing

The foundational technique.

Model answer

Dividing the input space into groups where every value in a group should be handled identically by the system, then testing one value from each group rather than all of them. If a field accepts ages 18 to 65, the partitions are below 18, 18 to 65, and above 65, so three tests cover the behaviour rather than eighty. The assumption is that if one value in a partition works, the others will too, which is why the partitions must be chosen on how the system actually treats the values rather than on how they look.

Likely follow-up

When does the equivalence assumption break down?

What they are assessing

The technique that finds the most defects per test.

Model answer

Testing at and around the edges of each partition, because that is where off by one errors live. For a field accepting 18 to 65 that means 17, 18, 19, 64, 65 and 66, or in the two value form just the values either side of each boundary. It is used alongside equivalence partitioning rather than instead of it: partitioning tells you where the boundaries are, boundary analysis tests them. Developers write conditions with greater than and greater than or equal, and this is the technique that catches which one they chose wrongly.

What they are assessing

Combinatorial technique.

Model answer

A table of condition combinations and the action expected for each, used when behaviour depends on several conditions interacting rather than on one input at a time. Business rules such as discount eligibility, insurance pricing or access permissions are the classic case. The value is that constructing the table forces every combination to be considered, which surfaces the combinations the specification never addressed. Those gaps are usually the real find: not a defect in the code but a decision nobody had made.

Likely follow-up

What do you do when the table has 64 combinations?

What they are assessing

Technique for stateful behaviour.

Model answer

Modelling the system as states and the events that move between them, then designing tests to cover the transitions. It applies wherever an entity has a lifecycle: an order moving through placed, paid, dispatched and delivered, or an account through active, suspended and closed. The valuable part is testing invalid transitions, meaning attempting an event the current state should not allow, such as cancelling an order already delivered. Those are routinely unhandled, because the developer implemented the paths in the diagram and not the ones outside it.

Trap to avoid

Only testing the valid transitions. The diagram shows what should happen; the defects are in what happens when someone tries what should not.

What they are assessing

Handling combinatorial explosion.

Model answer

A technique that generates a set of combinations covering every pair of parameter values at least once, rather than every full combination. It is based on the empirical finding that most defects are triggered by a single parameter or an interaction between two, so pairwise coverage finds the large majority of combination defects with a small fraction of the tests. It is appropriate for configuration testing, compatibility matrices and forms with many independent options. It is not appropriate where a specific three way interaction is known to be risky, which should be tested explicitly regardless.

Likely follow-up

What does pairwise testing miss?

What they are assessing

Whether the candidate values experience as well as formality.

Model answer

Designing tests based on experience of where defects tend to occur: empty inputs, zero, nulls, maximum lengths, special characters, duplicate submissions, back button behaviour, concurrent edits, timezone and daylight saving boundaries. It is legitimate and it is one of the highest yield techniques per unit of effort, which is precisely why it is unreliable as a primary method: it depends entirely on the individual, it is not repeatable between testers, and it gives no coverage measure. So I treat it as a layer on top of systematic techniques rather than a replacement, and where it repeatedly finds things I turn those into a checklist so the knowledge is not held by one person.

What they are assessing

Practical application of technique to an open input.

Model answer

By partitioning on how the system treats the content rather than on the content itself. Length boundaries including empty, one character, maximum and maximum plus one. Character classes: alphanumeric, spaces, leading and trailing whitespace, punctuation, unicode including emoji and right to left scripts, and accented characters. Strings with meaning to downstream layers, meaning quotes, angle brackets and script fragments, which tests escaping and is the boundary where functional testing meets security. Then persistence and display, since a value that saves correctly and renders broken is a defect the save test will not find.

What they are assessing

Scenario based design.

Model answer

Designing tests from use cases, which describe how an actor achieves a goal through the system, including the main flow and the alternative and exception flows. It is valuable because it tests the system the way it will actually be used, across components, rather than testing features in isolation. It finds integration and workflow defects that field level testing cannot, and it tends to surface missing requirements, because writing out the exception flows exposes the cases nobody specified.

What they are assessing

Review skill, which is prevention rather than detection.

Model answer

That it is specific, unambiguous and has an observable outcome you could demonstrate. A requirement saying the system should be user friendly is untestable because two people would disagree about whether it was met. One saying the user can complete checkout in no more than four steps is testable. The practical test I apply when reviewing is to ask what I would do to prove this is met, and if I cannot describe that in a sentence the requirement needs work. Catching this at review is far cheaper than discovering it when the build arrives.

Likely follow-up

What do you do when a requirement is ambiguous and the deadline is close?

What they are assessing

Coverage management.

Model answer

The ability to link requirements to the tests that verify them, and to the defects raised against them, in both directions. Forward traceability shows every requirement has coverage. Backward traceability shows every test exists for a reason. It matters because it is the only way to answer what have we not tested, which is the question that actually determines release risk, and because when a requirement changes it tells you which tests to revisit. In regulated sectors it is mandatory; everywhere else it is the difference between knowing your coverage and guessing it.

What they are assessing

A situation most testers meet, handled badly by most candidates.

Model answer

By building the specification from the sources that do exist, and making the gaps visible rather than stopping. Those sources are the existing system behaviour, which becomes a de facto baseline, conversations with the product owner and support team, user documentation, analytics showing what users actually do, and comparable products. I would write down what I believe the expected behaviour to be, circulate it, and treat silence as agreement after a stated point, because that turns my assumption into a shared one. Exploratory testing carries much more of the load in this situation, and I would be explicit in reporting that findings are against assumed behaviour.

Trap to avoid

Saying you cannot test without requirements. It is technically defensible and tells the interviewer you will be blocked by a situation that is extremely common.

What they are assessing

Static testing contribution.

Model answer

A structured review of requirements before implementation, where testers add particular value because they read for what is missing rather than for what is written. I look for ambiguity, especially words like appropriate, fast and intuitive. Missing error and exception behaviour, which is absent from most requirements. Undefined boundaries, since a range without stated inclusivity will be implemented arbitrarily. Conflicts with existing behaviour. Missing non functional expectations. And untestable statements. Finding these at review costs a conversation, while finding the same thing in test costs a rebuild.

What they are assessing

The basic deliverable.

Model answer

A clear identifier and title stating what is being verified. Preconditions, including the required data and state. Numbered steps that are unambiguous. Test data, or a reference to it. An expected result for each step that needs one, stated specifically rather than as works correctly. And the postcondition if the test leaves state behind. The standard I apply is whether someone unfamiliar with the feature could execute it and reach the same conclusion I would, because a test case only one person can run is a note rather than a test case.

What they are assessing

Judgement about a genuine trade off.

Model answer

It depends on who runs it and how often. Highly detailed steps are appropriate when the executor is unfamiliar with the system, when the process is regulated and must be evidenced, or when it is a candidate for automation. Less detail is better for experienced testers on familiar areas, because over-specified steps stop people thinking and they only look at what the script tells them to look at, which actively reduces defect detection. My default is to specify the intent and the data precisely and leave the mechanics loose, unless there is a reason not to.

Likely follow-up

What is the risk of a very detailed script for an experienced tester?

What they are assessing

Vocabulary precision.

Model answer

A test scenario is a high level statement of what to test, such as verify password reset, often one line. A test case is the detailed specification of one way to test it, with steps, data and expected results. A test script usually means the automated implementation, though in some organisations it means a detailed manual procedure. One scenario typically yields several test cases. Teams use these words inconsistently, so in a new organisation I would confirm the local meaning rather than assume.

What they are assessing

Dealing with the most common legacy situation.

Model answer

Treat the suite as a liability to be reduced rather than an asset to be preserved. I would first find out which cases have actually been executed and which have ever found a defect, since usually a minority carry all the value. Then classify: duplicates, cases for features that no longer exist, cases that are really one case with different data and should be a single parameterised test, and cases testing implementation detail rather than behaviour. Most of that can be deleted or merged. What remains gets prioritised by risk, with the high value stable ones becoming automation candidates. The important part is that a suite nobody runs provides no coverage while consuming maintenance, so keeping it is worse than cutting it.

What they are assessing

Long term thinking.

Model answer

Write them against behaviour rather than against the interface, so a redesign that keeps the behaviour does not invalidate them. Avoid duplicating the same preconditions in fifty cases by extracting shared setup. Keep data references rather than embedded values where the data is shared. Link cases to requirements so a requirement change identifies what to revisit. And review the suite regularly rather than only adding to it, because test suites grow monotonically unless someone is given explicit responsibility for removal, and an unmaintained suite loses credibility faster than it loses accuracy.

What they are assessing

A practical constraint that limits most testing.

Model answer

I identify what states the tests need rather than what records exist, which is the usual mistake. Then the sources: generated data where the shape is known, masked production data where realistic variety matters, and crafted edge case data which must be created deliberately because it never occurs naturally in a sample. The hard part is lifecycle, meaning how data is reset between runs and how tests avoid consuming each other’s records. A suite that passes on Monday and fails on Thursday because the eligible accounts have all been used is a test data problem rather than a product one.

Likely follow-up

What are the risks of using production data in a test environment?

What they are assessing

Awareness beyond the convenience.

Model answer

Data protection is the main one: real personal data in a lower environment with weaker access control is a breach waiting to be discovered, and under GDPR and similar regimes it is unlawful without a basis. So it must be masked or synthesised, and masking must preserve referential integrity or the data becomes unusable. Beyond compliance, production copies are large and slow to refresh, they go stale, and they carry an oddly shaped distribution with few edge cases, since production contains what users actually did rather than what the system permits. The strongest pattern is masked production data for realism combined with crafted data for the edges.

What they are assessing

A classically awkward case.

Model answer

In order of preference: make the system clock injectable so the test can set the date, which is the cleanest and usually needs a developer change worth asking for. Otherwise create data with dates relative to now, so a record expiring tomorrow is generated as today plus one rather than hardcoded, which keeps the test working next month. Changing the server clock works and is disruptive, since it affects everything else on that environment including other testers. And I would always include the boundaries explicitly: the day before, the day of, and the day after expiry, plus month and year ends where the logic involves periods.

Trap to avoid

Hardcoding future dates in test data. It works for a year and then the suite begins failing for reasons nobody connects to the original choice.

What they are assessing

Standard terminology.

Model answer

An error is the human mistake, such as a developer misreading a requirement. A defect or fault is the resulting flaw in the code or document. A failure is what happens when that defect is executed and the system behaves incorrectly. The chain matters because a defect can exist for years without ever causing a failure, if the conditions that trigger it never occur, which is exactly why a change in usage patterns can suddenly surface long standing defects.

What they are assessing

A testing principle with a practical consequence.

Model answer

The observation that a small number of modules usually contain most of the defects, following the Pareto pattern. The implication is that testing effort should follow the defects rather than being spread evenly, so areas with a history of problems, high complexity or recent heavy change deserve disproportionate attention. The counterweight is the pesticide paradox: repeatedly running the same tests in those areas stops finding new defects, so the tests themselves must keep evolving.

Likely follow-up

How do you identify the clusters on a system you have just joined?

What they are assessing

Conduct under disagreement.

Model answer

I check first, because sometimes they are right and I have misread the specification, and conceding quickly builds the credibility I need when I am right. If the behaviour genuinely does match the design, the defect is still real if the design produces a bad outcome for users, so I would reclassify it as a change request with the user impact stated rather than arguing the category. If it does not match, I show the specific clause and the observed behaviour side by side, factually. Where the specification is silent, which is the most common case, I escalate it as a decision for the product owner rather than a dispute between us.

What they are assessing

Judgement with a consistent basis.

Model answer

By impact on the user and the business if it reached production, assessed on three axes: how bad the outcome is, how many users are affected, and whether a workaround exists. Data loss or corruption is the highest, because it is often irreversible, followed by loss of a critical function with no workaround, then degraded function with a workaround, then cosmetic. The discipline that matters is applying the same basis consistently, since severity is only useful as a prioritisation signal if everyone means the same thing by it, and that is achieved through calibration against real examples rather than through a definitions document.

What they are assessing

The main prioritisation framework.

Model answer

Prioritising test effort by the risk each area carries, where risk combines the likelihood of a defect and the impact if one occurs in production. Likelihood is driven by complexity, how recently and heavily it changed, how new the technology is, and defect history. Impact is driven by business criticality, user volume, financial and regulatory exposure. The result is that testing is deepest where risk is highest and shallow or absent where it is not, which is a conscious decision rather than an accident of what fitted in the time available.

Likely follow-up

How do you identify likelihood on a system you do not know well?

What they are assessing

The most common senior scenario question.

Model answer

I would not try to do three weeks of work badly, which is what spreading thin amounts to. I would rank by risk, cover the highest risk areas properly, and be explicit about what is not being covered. Then I would state that clearly in writing before starting, so the decision to accept the gap is made knowingly by the people who own it rather than discovered afterwards. I would also look for compression rather than reduction: parallel execution across the team, reusing automated regression, and testing in the environment as components become available rather than waiting for a complete build. The deliverable at the end is a statement of what was tested, what was not, and what risk remains.

Trap to avoid

Promising to get it done. It fails and it removes the only opportunity for the business to make an informed decision about scope or date.

What they are assessing

Reporting integrity.

Model answer

By describing coverage in terms of areas and depth rather than a number, because a percentage implies a denominator that does not exist for functional testing. I would say which features were tested and to what depth, which were smoke tested only, which were not touched, and what the known gaps mean in terms of user impact. Stakeholders routinely ask for a percentage, and the honest reply is that I can give requirement coverage or test execution percentage, both of which are real numbers, while neither means the system is eighty percent tested. Making that distinction explicit is usually welcomed once explained.

What they are assessing

A discipline frequently mischaracterised.

Model answer

Simultaneous learning, test design and execution, where what the tester learns in one test shapes the next. It is structured rather than random: it is normally time boxed into sessions with a charter stating what is being explored, and the findings are recorded. It is effective because it adapts, so it finds the defects nobody anticipated, which scripted testing cannot by definition. It complements scripted testing rather than replacing it, since scripted tests give repeatability and evidence while exploratory testing gives discovery.

Trap to avoid

Describing it as unscripted or ad hoc testing. Ad hoc testing is unstructured; exploratory testing has a charter, a time box and an output, and conflating them is how the practice gets dismissed as unprofessional.

What they are assessing

How exploratory testing is made accountable.

Model answer

A way of structuring exploratory testing so it can be planned and reported. Testing happens in time boxed sessions, typically sixty to ninety minutes, each with a charter stating the mission. The tester records notes, defects and questions, and classifies time spent on testing against setup and investigation. A short debrief follows. The value is that it converts exploratory testing from something that looks like unaccountable poking into something with a plan, a record and a coverage statement, which is what makes it defensible to managers who want to know what was done.

What they are assessing

Strategy with a reasoned position.

Model answer

It depends on the context rather than a fixed ratio. Scripted testing earns its place where repeatability and evidence matter: regulated environments, regression of stable areas, and anything that will be automated. Exploratory earns its place on new features, complex areas, and anywhere the requirements are thin, which is where its discovery rate is highest. On a typical product team I would aim for the regression layer to be automated, with manual effort weighted heavily toward exploratory testing of what is new, because manually re-executing scripted regression is the lowest value use of a skilled tester and the highest value use of a machine.

What they are assessing

Modern delivery context.

Model answer

Continuously rather than as a phase. Testers are involved from refinement, questioning acceptance criteria before code exists, which prevents more than it detects. Testing happens within the sprint as stories become available rather than at the end, which requires developers to deliver stories throughout the sprint rather than all on the final day. Automated regression runs continuously so the previously working functionality is protected without manual effort. And the definition of done includes testing, which is what stops a story being called complete before it is verified.

Likely follow-up

What happens when all the stories arrive for testing on day nine of a ten day sprint?

What they are assessing

The agile equivalent of a specification.

Model answer

Conditions a story must satisfy to be accepted, written before development and agreed between the product owner, developer and tester. For a tester they are the primary source of expected behaviour, and reviewing them is the highest leverage activity available because a criterion that is ambiguous at that point costs a conversation and the same ambiguity found in testing costs a rebuild. They are necessarily incomplete, covering the intent rather than every case, so they are the starting point for test design rather than the full set of tests.

What they are assessing

Prevention through the specific questions a tester brings.

Model answer

The ones nobody else asks. What happens when this fails partway through, since the error path is almost never in the description. What are the boundaries on each input and are they inclusive. What should happen with no data, with maximum data, and with data created before this feature existed. Who is allowed to do this and what happens when someone else tries. What else changes as a result, meaning the downstream effects nobody listed. And how we would demonstrate it works, because a story nobody can describe a verification for is not ready. Each of those costs a sentence to ask and a rebuild to discover later.

Likely follow-up

Which of those questions most often changes the story?

What they are assessing

A genuine practical tension.

Model answer

Automation is the only sustainable answer, because manual regression grows with every sprint while the sprint length stays fixed, so manual regression mathematically consumes the team eventually. Practically that means the regression suite is automated and runs on every build, manual effort in the sprint goes to the new functionality and exploratory testing, and the automation is maintained as part of the story rather than as a later task. Where automation is not yet in place, risk based selection of a manual regression subset is the interim answer, with the explicit understanding that it is interim and the coverage is partial.

What they are assessing

Selection judgement.

Model answer

Tests that are run repeatedly, that are stable, that are objective in their pass criteria, and where the cost of automating is recovered by the frequency of execution. Regression suites, smoke tests, data driven validation across many combinations, and anything needed on every build. What should not be automated is anything run once, anything whose expected result requires human judgement such as visual design or usability, anything against a feature still changing shape, and anything where the setup cost exceeds any plausible saving. The question to ask is not can this be automated but should it be.

Likely follow-up

What is the cost of automating a test that changes every sprint?

What they are assessing

A question with a confident wrong answer available.

Model answer

No, and the framing is wrong. Automation executes checks that someone already knew to write, so it confirms known expectations very efficiently and discovers nothing. Finding the unexpected, judging whether behaviour is reasonable, noticing that something is technically correct and unusable, and testing anything requiring human perception all remain manual. What automation replaces is the repetitive re-execution of known checks, which frees skilled testers for the work that needs judgement. A team that automates and then reduces its testers proportionally usually finds defect escape rates rise within a few releases.

Trap to avoid

Saying yes, or saying automation is the goal. Interviewers asking this want to hear what automation does not do.

What they are assessing

Efficient test placement.

Model answer

Anything that is business logic rather than presentation belongs at API level, because the tests are faster, far more stable and give more precise failures. That includes validation rules, calculations, permissions, data transformation and error handling, all of which are commonly tested through the UI out of habit. What genuinely needs the UI is the presentation layer itself, the wiring between the interface and the service, and the journey as a user experiences it. The practical result is a small number of UI tests over a much larger API layer, which is the same principle as the test pyramid applied within functional testing.

What they are assessing

Documentation vocabulary.

Model answer

A test strategy is the high level approach, usually organisational or programme wide and relatively stable: the levels and types of testing performed, the tools, environments, entry and exit criteria, and roles. A test plan is specific to a project or release and describes what will be done this time: scope, schedule, resources, risks and deliverables. In practice many organisations merge them, and in agile teams both are often reduced to a short living document, which is fine provided the decisions they record have actually been made somewhere.

What they are assessing

Process control.

Model answer

Entry criteria are the conditions that must hold before a test phase begins: the build deployed, smoke test passed, environment available, test data ready, requirements baselined. Exit criteria are the conditions for declaring it complete: planned tests executed, defects of a given severity resolved, coverage achieved, remaining risk accepted. They matter because without entry criteria testing starts against a build that cannot be tested and the time is lost, and without exit criteria testing ends when the date arrives rather than when a defensible state is reached.

Likely follow-up

What do you do when entry criteria are not met but the schedule says start?

What they are assessing

Metrics with judgement.

Model answer

Defect escape rate is the primary one: the proportion of defects found in production rather than in testing, because that measures the outcome the function exists to produce. Alongside it, defect removal efficiency per phase, the severity distribution of escaped defects since one critical escape matters more than twenty cosmetic ones, and reopen rate as a signal of fix and verification quality. What I would avoid is defects found as a measure of tester performance, because it rewards volume, punishes prevention, and falls when quality genuinely improves, so it makes success look like failure.

What they are assessing

Diagnosing and fixing a systemic problem.

Model answer

First establish where defects are being found and where they originate, since late detection is a symptom with several causes. If they are requirement misunderstandings, the fix is upstream involvement: testers in refinement and acceptance criteria review. If they are integration defects found in system test, the fix is earlier integration and contract testing. If testing starts late in the sprint because stories arrive late, that is a flow problem and the fix is with the whole team rather than with testing. I would measure before and after, because this kind of change is easy to assert and hard to evidence, and the credibility of the next improvement depends on evidencing this one.

What they are assessing

Basic vocabulary.

Model answer

A collection of test cases grouped for a purpose, such as a smoke suite, a regression suite, or a suite covering one feature area. Grouping matters because it allows selective execution: you run the smoke suite on every build and the full regression weekly. A test case can belong to several suites, which is why suite membership is usually managed with tags rather than by physically organising cases into folders.

What they are assessing

A standard practical exercise that rewards structure.

Model answer

I would work through it systematically. Valid credentials for each user role. Invalid combinations: wrong password, unknown username, empty fields, and whether the error message distinguishes them, since a message saying unknown username enables account enumeration. Boundaries on field length and character handling. Case sensitivity on both fields. Lockout after repeated failures, and whether it is enforced server side. Session behaviour after login, including concurrent sessions and session fixation. Password reset and remember me. Browser back after logout. And the non functional edges that matter here: credentials in transit, autocomplete behaviour, and whether the password is masked and excluded from logs.

Likely follow-up

Why does the wording of the failure message matter?

What they are assessing

Another standard exercise.

Model answer

Exact matches, partial matches and no results, confirming the empty state is handled rather than showing a broken list. Case and accent insensitivity. Leading and trailing whitespace. Special characters, including those with meaning to the query layer, which tests escaping. Very long inputs. Pagination, including the last page and boundary counts. Sorting and its stability. Relevance ordering, which needs a judgement call rather than an exact assertion. Performance on common and rare terms. And behaviour against an empty data set, which is the case that is never set up and frequently broken.

What they are assessing

A feature with an unusually wide risk surface.

Model answer

Valid files of each accepted type and a range of sizes including the stated maximum and one byte over. Rejected types, and crucially whether rejection is enforced server side rather than only by the browser file picker, since that is the security boundary. Files with a mismatched extension and content type. Zero byte files. Files with unusual or very long names, unicode names, and names containing path separators, which tests for directory traversal. Interrupted uploads and what state is left behind. Concurrent uploads of the same name. Then what happens downstream: storage, virus scanning if present, and whether the file is served back in a way that could execute.

What they are assessing

Prevention mindset.

Model answer

Determining why a defect occurred rather than only what it was, usually by asking why repeatedly until reaching a process cause rather than a code cause. A tester does it because the answer changes what should improve: if defects keep arising from misread requirements, the fix is in refinement; if from regression, the fix is in automated coverage; if from environment differences, the fix is in configuration management. Without it, teams fix defects individually forever and the rate never falls, which is the difference between finding defects and improving quality.

What they are assessing

Investigation under difficult conditions.

Model answer

Start from the evidence rather than from attempts to reproduce: logs, monitoring, error tracking and the specific user reports with their timestamps, account and actions. Then look for what differs between production and test, which is usually the answer. The common candidates are data volume and shape, configuration, scale and concurrency, integrations pointing at real third parties, and genuine user behaviour that no test script would attempt. I would try to reproduce in a lower environment by importing the triggering data state, and where that fails, controlled investigation in production with monitoring. The outcome should include a test that would have caught it, so the gap closes.

Likely follow-up

What would you add to the test environment to stop this class of defect recurring?

What they are assessing

A specific deliverable.

Model answer

A table mapping requirements to the test cases that cover them, and often onward to the defects raised and the execution status. Its value is answering two questions directly: which requirements have no coverage, and if this requirement changes, which tests are affected. In regulated environments it is a required artefact. Elsewhere it is worth maintaining in some form, though a full manual matrix on a large project is expensive enough that it is usually better derived from links in the test management tool than maintained as a separate document.

What they are assessing

Getting productive in an unfamiliar codebase.

Model answer

I would build a map before trying to test comprehensively. Use the application as a user to learn the main journeys and record them. Read the defect history, which tells you where the problems are and implicitly what the system does. Talk to support, who know the real failure modes better than anyone. Look at analytics for what users actually use, since effort should follow usage. Check the database schema and the API surface, which describe the domain model better than most documentation would. Within a week or two that produces a risk ranked picture, and I would write it down as the documentation that did not exist.

What they are assessing

A boundary case in the classification.

Model answer

Verifying the system works across the browsers, devices, operating systems and screen sizes it must support. It sits on the boundary: the checks performed are functional, since you are verifying features work, but the dimension being varied is environmental, so it is often classified as non functional. The classification matters less than the approach, which is to define the supported matrix from actual user analytics rather than testing everything, and to test the full journey on the highest traffic combinations while sampling the rest.

What they are assessing

A popular concept, tested for depth.

Model answer

Moving testing activity earlier: reviewing requirements, contributing to acceptance criteria, testing components as they are built, and automating checks that run on commit. It works because defects cost more the later they are found, and because prevention is cheaper than detection. Its limits are real though: some defects only appear in an integrated system with production-like data, so shifting left does not remove the need for system level testing, and a team that treats shift left as a reason to cut late stage testing usually discovers the gap in production. It is an addition to the lifecycle rather than a redistribution of a fixed amount of effort.

What they are assessing

Practical application.

Model answer

A charter states the mission in a sentence or two: what area, with what resources, to discover what information. A common format is to explore a target, with some resource or technique, to discover something specific. For instance: explore the bulk upload feature with malformed CSV files to discover how validation failures are reported and whether partial imports leave consistent data. The value of writing it is focus, since an unfocused session drifts across the whole application, and it gives a coverage statement afterwards that an undirected session cannot.

What they are assessing

A constant practical friction.

Model answer

Through isolation rather than coordination, because coordination fails as soon as people are busy. The strongest approach is for each test to create the data it needs and clean up after itself, so there is no shared pool to collide over. Where that is not possible, namespacing by team or by run, so records are identifiable and separable. Reserved data sets that are documented as owned and not to be modified. And a reset schedule that is known rather than ad hoc, since the worst version of this problem is someone restoring the database mid-run without telling anyone.

What they are assessing

A testing principle with a practical consequence.

Model answer

That running the same tests repeatedly stops finding new defects, because the defects those tests can detect have already been found and fixed. The consequence is that a test suite needs to keep evolving: adding cases, varying data, and exploring areas the existing tests do not reach. It is an argument against treating a regression suite as finished, and it is one of the main justifications for exploratory testing alongside automated regression, since the automated suite by its nature only ever asks the questions it was written to ask.

What they are assessing

Flake discipline.

Model answer

Investigate rather than rerun, because the default response of rerunning until green is how a suite loses credibility. The cause is usually a race between the test and the application, shared state from another test, test data that varies, or an environment issue. Occasionally it is a genuine product defect that only manifests under timing, and those are the most valuable findings in the suite, so dismissing intermittent failures as flake is how a real concurrency bug reaches production. If it cannot be fixed quickly I would quarantine it out of the blocking pipeline with an owner and a date, rather than leaving it to erode trust in every other result.

What they are assessing

A design question with a defensible answer either way.

Model answer

One logical verification per test, which is not the same as one assertion statement. A test verifying an order is created may legitimately assert on several fields of that order, because they are one outcome. What it should not do is verify order creation, then email dispatch, then inventory adjustment, because when it fails you do not know which part broke and the later checks never run. For manual test cases the same principle applies with more tolerance, since the setup cost is higher and splitting too finely wastes a tester’s time repeating preconditions.

What they are assessing

Influence.

Model answer

In terms of risk and cost rather than principle. I would show what was found and what it would have cost had it reached production, using their own numbers where possible: support cost, remediation cost, the cost of an incident. I would also show what is not being tested and what that exposure is, because that converts the conversation from testing is slowing us down into here is the risk we are accepting, which is a decision they can own. Where the scepticism is really about speed, I would bring proposals: more automated regression, earlier involvement, and better environments, since those genuinely reduce the duration rather than defending it.

What they are assessing

Upstream process.

Model answer

A checklist a story must satisfy before it is pulled into a sprint: acceptance criteria written, dependencies identified, designs available, sized, and testable. It helps testing because the most expensive problem in a sprint is a story that cannot be tested when it arrives, usually because nobody agreed what correct looks like. Insisting on testability at the ready stage is cheap; discovering the ambiguity on day eight is not. It is also the lever that stops stories entering a sprint with acceptance criteria written as a single sentence.

What they are assessing

Prioritisation when everything is undone.

Model answer

Learn the product and the risk picture first, because effort spent before that is guesswork. In parallel I would establish the basics that make everything else possible: a way to raise defects that people respond to, a smoke test for the critical paths so builds can be accepted or rejected quickly, and a view of what the business considers critical. Then I would cover the highest risk areas properly rather than covering everything shallowly. What I would avoid is starting with a large test case writing exercise or an automation framework, because both consume the first month and deliver nothing anyone notices, which makes the second month harder.

Likely follow-up

What would you deliberately leave undone?

What they are assessing

Release judgement.

Model answer

A defect accepted as real but consciously not fixed in this release. The handling that matters is that the decision is explicit, recorded with a reason and an owner, and visible to support so they are not blindsided by the calls. It should carry a target release or a review date rather than being deferred indefinitely, because deferred without a date is closed with extra steps. And the aggregate matters: a release with forty deferred defects has a quality problem even if each individual decision was reasonable, which is worth surfacing at the point of the fortieth.

What they are assessing

The economic argument underlying most testing practice.

Model answer

It rises sharply with each phase, and the often quoted multipliers vary by study, so I would be careful about citing a specific figure. The mechanism is what matters: a defect found at requirements costs a conversation. In development it costs a code change. In system test it costs a code change plus a rebuild, retest and regression. In production it costs all of that plus incident response, customer impact, possible data remediation, and the opportunity cost of the people pulled onto it. The curve is the justification for shift left and for prevention activities like requirement review, which is why the principle is worth understanding rather than the exact numbers.

What they are assessing

Boundary of responsibility.

Model answer

Developers write them, because they need to be written alongside the code and require internal knowledge. QA has a role, though not in writing them: reviewing what is covered to spot gaps in edge cases, which developers often under-test because they are testing what they built rather than what could break. Also in using unit test coverage as an input to risk assessment, since an area with no unit tests deserves more attention at system level. Where QA should not go is claiming ownership of unit tests, which removes the developer’s responsibility for the quality of their own code.

What they are assessing

The core judgement of the role.

Model answer

When the agreed exit criteria are met and the remaining risk is understood and accepted by the people who own it. Testing is never complete in an absolute sense, so done is a business decision informed by evidence rather than a state the testing team reaches alone. Practically I would look for: planned coverage of high risk areas executed, no open defects above the agreed severity, the defect discovery rate falling rather than rising, and a clear written statement of what has not been tested. The last of those matters most, because a release decision taken without knowing the gaps is not an informed decision.

What they are assessing

Testing across a boundary you do not own.

Model answer

By separating what I am testing. Our handling of their responses is fully testable with stubs or a virtualised service, and that is where most of the risk sits: timeouts, error codes, malformed responses, rate limits and unexpected fields. Their sandbox, if one exists, covers the contract but rarely behaves like production. I would also test the failure modes deliberately, since a third party being slow or down is a question of when rather than whether, and the behaviour then is what users will judge us on. What I cannot test is their reliability, which belongs in the risk register rather than the test plan.

What they are assessing

Terminology overlap with smoke testing.

Model answer

A set of checks run against a new build to decide whether it is worth testing further, which in most organisations is the same thing as a smoke test. It is normally automated and fast, covering the critical paths and confirming the deployment succeeded and the main integrations respond. Its purpose is economic: it prevents a team spending a day testing a build that was broken on arrival, and it gives the development team a fast signal rather than a slow one.

What they are assessing

A closing question revealing what the candidate values.

Model answer

Three things in my experience. Asking why rather than only what, so they question whether the requirement makes sense rather than only whether the build matches it, which is where the expensive defects are prevented. Thinking in terms of risk rather than completeness, so their effort lands where it matters instead of being spread evenly to feel thorough. And communicating findings so that people act on them, because a defect reported badly is a defect not fixed, and a risk stated vaguely is a risk accepted by default. The technical techniques are learnable in a few months; those three take longer and are what the role actually consists of.