Walk me through how you would design a test automation strategy for a new product.

Strategy question, scored on practicality and pyramid sense. Strong answers describe the test pyramid: heavy unit-test layer (developers own, fast feedback), focused integration-test layer (API contract tests, repository tests), thin and selective end-to-end layer (critical user flows only — login, checkout, payment), with visual regression and accessibility checks where they pay off. Mention specific tooling (Playwright for E2E in 2026, Cypress on the wane, Postman/Newman or Pact for contract). Mention CI gating policy and the maintenance cost of E2E tests. Weak candidates describe E2E-heavy strategy. The kill-shot is recommending a Selenium-only stack in 2026. UK senior QA panels expect modern tooling fluency.

How do you decide what to automate vs what to test manually?

Judgement question. Strong answers cover: automate the repetitive (regression, smoke, critical paths), keep manual for exploratory testing, accessibility verification with real assistive tech, visual judgement, edge-case discovery, and any test where the cost of automation exceeds the cost of manual. Mention that exploratory testing is a senior-skill activity, not a fallback. Weak candidates describe 'automate everything' or 'we do manual testing'. The kill-shot is recommending automation for tests that change every sprint or for tests where the assertion is subjective. UK panels in 2026 want QA Engineers who think about cost, not just coverage.

Walk me through how you would test a payment integration.

Domain-specific question. Strong answers cover: contract testing against the payment provider's sandbox API, idempotency-key handling (replay the same request, expect single side-effect), failure-mode coverage (network timeout, gateway error, 3DS challenge, declined card, insufficient funds, card-not-supported), edge cases (currency rounding, partial-refund, capture-after-authorise), reconciliation between your ledger and the provider's, and compliance/PCI scope considerations. Mention test-data discipline (synthetic cards only, never real cards in test). Weak candidates describe happy-path testing. The kill-shot is forgetting idempotency. UK fintech panels test this scenario constantly.

How do you approach test data management?

Practical question that exposes seniority. Strong answers cover: synthetic-data generation (Faker, custom factories), seed strategies for predictable test scenarios, data masking for production-restored datasets, isolation per test run (transactional rollback or per-test database), GDPR-aware test data (no real PII in non-prod), and reset strategy in CI. Mention that test-data flakiness is the leading cause of CI noise. Weak candidates describe 'we use a shared test database'. The kill-shot is recommending production data in test environments without masking. UK panels in regulated sectors disqualify on this.

Tell me about a time you found a critical bug late in the release cycle.

Behavioural with stakeholder-management focus. Strong answers describe the bug, how you found it (exploratory test, customer report, monitoring), the severity assessment, the communication (escalating clearly without panic), the decision (delay vs hotfix vs feature-flag-disable), and the post-mortem learning. Mention that QA Engineers who escalate well get promoted; QA Engineers who hide bugs do not. Weak answers describe finding bugs without resolution. The kill-shot is bad-mouthing developers. UK senior QA hires are stakeholder partners; the question filters for whether you understand that.

How do you handle flaky tests?

This is the QA discipline question. Strong answers cover: investigate root cause (race condition, test isolation, test-data pollution, timing/animation, network flake), do not retry-to-pass without diagnosis, quarantine flaky tests with a deadline to fix or delete, monitor flake rate as a first-class metric, and prevent flake at source through better test design. Mention that retry-to-pass is a code smell that hides real bugs. Weak candidates describe adding retry logic. The kill-shot is treating flakes as acceptable noise. UK senior QA panels disqualify on this question alone.

Walk me through how you would test an LLM-powered feature.

AI testing is a 2026-current topic that distinguishes senior from mid QA Engineers. Strong answers cover: deterministic-input tests (golden datasets with expected output), property-based tests (output should always include X, never include Y), eval engineering (LLM-as-judge for subjective quality, with human spot-checks), prompt-injection testing as a security concern, hallucination detection through fact-checking against ground truth, regression testing for prompt changes, and cost monitoring as part of test runs. Mention that traditional unit tests fail on non-deterministic outputs; you need probabilistic assertions. Weak candidates describe 'we click around and see if it looks right'. The kill-shot is not knowing what eval engineering is. UK panels at AI-product companies test this scenario constantly.

How do you approach performance and load testing?

Performance question, scored on realism. Strong answers cover: define SLOs first (target p50, p95, p99 latency, target throughput, error budget), build realistic load profiles based on production traffic (k6 or Locust in 2026, JMeter on the wane), test at expected and peak loads, soak-test for memory leaks and resource exhaustion, monitor downstream services not just the system under test, and compare results against SLOs not arbitrary numbers. Mention chaos engineering as a complementary discipline. Weak candidates describe load testing as 'simulate 10000 users'. The kill-shot is having no SLO baseline. UK senior QA hires at fintech are expected to be performance-fluent.

Tell me about a time you improved CI/CD pipeline speed or reliability.

Behavioural with engineering depth. Strong answers are specific: 'CI was 28 minutes per PR with 6 percent flake rate. I parallelised the test suite across 4 runners, moved E2E tests to a nightly job with smoke-tests-only on PR, fixed 12 flaky tests at root cause, and migrated from Selenium to Playwright cutting E2E run time by 40 percent. CI dropped to 9 minutes per PR with 0.4 percent flake rate.' Weak answers describe no specifics. The kill-shot is having no CI improvement story; senior UK QA Engineers are CI/CD partners with engineering, not test-only specialists.

How do you handle accessibility testing?

Practical question. Strong answers cover: automated accessibility checks (axe-core, jest-axe, Lighthouse) catch about 30 percent of issues, the rest require manual testing with real assistive tech (NVDA, VoiceOver, TalkBack), keyboard-only navigation testing, focus-management verification, colour contrast checking against actual rendered output, and screen-reader announcement testing. Mention WCAG 2.2 AA as the UK target. Weak candidates describe 'we use Lighthouse'. The kill-shot is admitting you have never used a screen reader. UK regulated-sector panels test accessibility QA depth specifically.

How do you approach test code as production code?

Maturity question. Strong answers cover: tests are versioned, code-reviewed, refactored, and treated as a first-class deliverable; they should follow the same naming, structure and lint rules as production code; tests should be DRY but readable (over-abstraction hurts diagnosability); page-object pattern for E2E; and that test code rotting is a leading cause of CI flake. Mention that test code is a recruit-ability signal — strong test code attracts strong engineers. Weak candidates treat tests as throwaway scripts. The kill-shot is admitting your team does not code-review tests. UK senior QA hires care about test-code quality; the question filters for that.

Why are you leaving your current role?

Standard closer. Strong answers are forward-looking: you want a more automation-heavy QA function, you want to own test infrastructure (SDET-style), you want a 2026-current stack (Playwright over Selenium, modern eval pattern for AI features), you want a regulated-environment challenge if your current is unregulated. Weak answers attack your current employer. The kill-shot is criticising specific developers or QA leads by name. UK QA is a small community; everyone interviewing you knows the engineer you are complaining about. Stay forward-looking. The panel wants reassurance you will not have the same complaint about them in 18 months.

Interview Q's · Tech · UK 2026

QA Engineer Interview Questions UK

QA Engineer interviews in UK 2026 have shifted significantly. The pure-manual-tester role has compressed; the thriving role is QA Engineer with shipped automation, CI/CD pipeline ownership, and product instinct. Senior QA Engineers in London earn £70-100k base, more at SDET-titled roles with strong automation. The 12 questions below are the ones I see in real UK loops at fintech, e-commerce and AI-product scale-ups. I have written each answer from the recruiter's side: what the panel is testing for, what a strong response looks like, and what mistake immediately ends the conversation. Read this even if you are confident — QA hiring in 2026 weights automation depth more heavily than candidates expect.

By Alex · 12-year UK recruiter · 12 questions + recruiter answers

Question 1

Walk me through how you would design a test automation strategy for a new product.

Strategy question, scored on practicality and pyramid sense. Strong answers describe the test pyramid: heavy unit-test layer (developers own, fast feedback), focused integration-test layer (API contract tests, repository tests), thin and selective end-to-end layer (critical user flows only — login, checkout, payment), with visual regression and accessibility checks where they pay off. Mention specific tooling (Playwright for E2E in 2026, Cypress on the wane, Postman/Newman or Pact for contract). Mention CI gating policy and the maintenance cost of E2E tests. Weak candidates describe E2E-heavy strategy. The kill-shot is recommending a Selenium-only stack in 2026. UK senior QA panels expect modern tooling fluency.
Question 2

How do you decide what to automate vs what to test manually?

Judgement question. Strong answers cover: automate the repetitive (regression, smoke, critical paths), keep manual for exploratory testing, accessibility verification with real assistive tech, visual judgement, edge-case discovery, and any test where the cost of automation exceeds the cost of manual. Mention that exploratory testing is a senior-skill activity, not a fallback. Weak candidates describe 'automate everything' or 'we do manual testing'. The kill-shot is recommending automation for tests that change every sprint or for tests where the assertion is subjective. UK panels in 2026 want QA Engineers who think about cost, not just coverage.
Question 3

Walk me through how you would test a payment integration.

Domain-specific question. Strong answers cover: contract testing against the payment provider's sandbox API, idempotency-key handling (replay the same request, expect single side-effect), failure-mode coverage (network timeout, gateway error, 3DS challenge, declined card, insufficient funds, card-not-supported), edge cases (currency rounding, partial-refund, capture-after-authorise), reconciliation between your ledger and the provider's, and compliance/PCI scope considerations. Mention test-data discipline (synthetic cards only, never real cards in test). Weak candidates describe happy-path testing. The kill-shot is forgetting idempotency. UK fintech panels test this scenario constantly.
Question 4

How do you approach test data management?

Practical question that exposes seniority. Strong answers cover: synthetic-data generation (Faker, custom factories), seed strategies for predictable test scenarios, data masking for production-restored datasets, isolation per test run (transactional rollback or per-test database), GDPR-aware test data (no real PII in non-prod), and reset strategy in CI. Mention that test-data flakiness is the leading cause of CI noise. Weak candidates describe 'we use a shared test database'. The kill-shot is recommending production data in test environments without masking. UK panels in regulated sectors disqualify on this.
Question 5

Tell me about a time you found a critical bug late in the release cycle.

Behavioural with stakeholder-management focus. Strong answers describe the bug, how you found it (exploratory test, customer report, monitoring), the severity assessment, the communication (escalating clearly without panic), the decision (delay vs hotfix vs feature-flag-disable), and the post-mortem learning. Mention that QA Engineers who escalate well get promoted; QA Engineers who hide bugs do not. Weak answers describe finding bugs without resolution. The kill-shot is bad-mouthing developers. UK senior QA hires are stakeholder partners; the question filters for whether you understand that.
Question 6

How do you handle flaky tests?

This is the QA discipline question. Strong answers cover: investigate root cause (race condition, test isolation, test-data pollution, timing/animation, network flake), do not retry-to-pass without diagnosis, quarantine flaky tests with a deadline to fix or delete, monitor flake rate as a first-class metric, and prevent flake at source through better test design. Mention that retry-to-pass is a code smell that hides real bugs. Weak candidates describe adding retry logic. The kill-shot is treating flakes as acceptable noise. UK senior QA panels disqualify on this question alone.
Question 7

Walk me through how you would test an LLM-powered feature.

AI testing is a 2026-current topic that distinguishes senior from mid QA Engineers. Strong answers cover: deterministic-input tests (golden datasets with expected output), property-based tests (output should always include X, never include Y), eval engineering (LLM-as-judge for subjective quality, with human spot-checks), prompt-injection testing as a security concern, hallucination detection through fact-checking against ground truth, regression testing for prompt changes, and cost monitoring as part of test runs. Mention that traditional unit tests fail on non-deterministic outputs; you need probabilistic assertions. Weak candidates describe 'we click around and see if it looks right'. The kill-shot is not knowing what eval engineering is. UK panels at AI-product companies test this scenario constantly.
Question 8

How do you approach performance and load testing?

Performance question, scored on realism. Strong answers cover: define SLOs first (target p50, p95, p99 latency, target throughput, error budget), build realistic load profiles based on production traffic (k6 or Locust in 2026, JMeter on the wane), test at expected and peak loads, soak-test for memory leaks and resource exhaustion, monitor downstream services not just the system under test, and compare results against SLOs not arbitrary numbers. Mention chaos engineering as a complementary discipline. Weak candidates describe load testing as 'simulate 10000 users'. The kill-shot is having no SLO baseline. UK senior QA hires at fintech are expected to be performance-fluent.
Question 9

Tell me about a time you improved CI/CD pipeline speed or reliability.

Behavioural with engineering depth. Strong answers are specific: 'CI was 28 minutes per PR with 6 percent flake rate. I parallelised the test suite across 4 runners, moved E2E tests to a nightly job with smoke-tests-only on PR, fixed 12 flaky tests at root cause, and migrated from Selenium to Playwright cutting E2E run time by 40 percent. CI dropped to 9 minutes per PR with 0.4 percent flake rate.' Weak answers describe no specifics. The kill-shot is having no CI improvement story; senior UK QA Engineers are CI/CD partners with engineering, not test-only specialists.
Question 10

How do you handle accessibility testing?

Practical question. Strong answers cover: automated accessibility checks (axe-core, jest-axe, Lighthouse) catch about 30 percent of issues, the rest require manual testing with real assistive tech (NVDA, VoiceOver, TalkBack), keyboard-only navigation testing, focus-management verification, colour contrast checking against actual rendered output, and screen-reader announcement testing. Mention WCAG 2.2 AA as the UK target. Weak candidates describe 'we use Lighthouse'. The kill-shot is admitting you have never used a screen reader. UK regulated-sector panels test accessibility QA depth specifically.
Question 11

How do you approach test code as production code?

Maturity question. Strong answers cover: tests are versioned, code-reviewed, refactored, and treated as a first-class deliverable; they should follow the same naming, structure and lint rules as production code; tests should be DRY but readable (over-abstraction hurts diagnosability); page-object pattern for E2E; and that test code rotting is a leading cause of CI flake. Mention that test code is a recruit-ability signal — strong test code attracts strong engineers. Weak candidates treat tests as throwaway scripts. The kill-shot is admitting your team does not code-review tests. UK senior QA hires care about test-code quality; the question filters for that.
Question 12

Why are you leaving your current role?

Standard closer. Strong answers are forward-looking: you want a more automation-heavy QA function, you want to own test infrastructure (SDET-style), you want a 2026-current stack (Playwright over Selenium, modern eval pattern for AI features), you want a regulated-environment challenge if your current is unregulated. Weak answers attack your current employer. The kill-shot is criticising specific developers or QA leads by name. UK QA is a small community; everyone interviewing you knows the engineer you are complaining about. Stay forward-looking. The panel wants reassurance you will not have the same complaint about them in 18 months.

How to use these answers

QA Engineer interviews in UK 2026 weight automation depth, CI/CD pipeline ownership, performance/load fluency, and AI-feature testing instinct. The single biggest mistake I see is candidates with manual-only experience trying to interview for SDET-grade roles; the role has shifted, and the salary premium reflects the engineering depth required. Prep with three real shipped automation projects you can talk through end-to-end (the strategy, the trade-offs, the maintenance story). Practise the strategy rounds on real product scenarios (payment integration, AI-feature testing, performance under load). UK senior QA hires get the salary premium because they earn it on engineering depth and product instinct, not test-case-writing volume.

Related across UK Rights & Guides

Keep reading

Browse the JobLabs UK careers reference →

Pillars + free tools

Related job-search guides + calculators

Pillars

→ UK Career Change — first-move pillar — sector-switch playbook
→ UK CV ATS-format reference — CV format + ATS-safe AI prompts
→ UK Interview Prep cluster index — STAR + 4-stage UK process
→ UK Cover Letter — buzzword-free pillar — five UK opening patterns

Free recruiter-built tools