QA / Test Engineer Interview Prep
Manual and automated testing. Catches bugs before they hit production.
General tips for this role
- Bring a real bug report from your past work. Demonstrating quality over quantity matters.
- Know one E2E framework deeply (Playwright is hottest in 2026, Cypress still strong).
- Mention API testing — it separates juniors from mid-level QA.
- Talk about the testing pyramid unprompted. Shows you understand strategy.
- Be ready to test something live. 'Test this calculator' is a common interview exercise.
What is the difference between functional and non-functional testing?
Show model answer
Functional testing: does the system do what it should? (login works, payment processes). Non-functional testing: HOW WELL does it do it? (performance, security, usability, scalability). Both are essential. Functional bugs are obvious; non-functional bugs are sneakier (slow APIs, security holes).
Explain the difference between black-box and white-box testing.
Show model answer
Black-box: testing without knowledge of the code. Test inputs and outputs. Focus on behaviour. White-box: testing with full knowledge of the code. Aims to cover all paths and branches. QA engineers mostly do black-box. Developers do white-box (unit tests). Many real teams do a mix.
Walk me through how you would test a login form.
Show model answer
Happy path: valid email, valid password — works. Negative: invalid email, missing password, wrong password — clear error messages. Edge cases: very long inputs, special characters, SQL injection attempts (do nothing bad), unicode in email. Security: too many failed attempts triggers rate limiting. Cross-browser: works on Chrome, Safari, Firefox, mobile. Accessibility: keyboard navigation works, screen reader announces errors. Performance: loads quickly even on slow connections.
Always cover happy + negative + edge + security + accessibility. Most candidates only cover happy path.
What is regression testing and when do you run it?
Show model answer
Regression testing: re-running tests after a code change to make sure existing functionality still works. New bug fixes can sometimes break old features. Should run automatically on every PR (CI). For larger suites, run nightly. Manual regression for things automation cannot cover yet (e.g. specific UX flows on multiple browsers).
What is your approach to test automation?
Show model answer
Pyramid: most tests at the unit level (fast, narrow), fewer at the integration level (medium speed), fewer still at the end-to-end level (slow, broad). End-to-end tests should be reserved for critical user flows (login, checkout). Tools: unit (Jest, Pytest), integration (TestContainers), E2E (Playwright, Cypress). Run unit on every commit, E2E nightly or pre-deploy.
How do you handle flaky tests?
Show model answer
First understand WHY flaky. Common causes: race conditions (test depends on timing), shared state between tests, network calls to real services, time-of-day dependent code, browser quirks in E2E. Fixes: use waits (waitFor in Cypress/Playwright), mock external services, isolate state per test, fix root causes — do NOT just retry forever. Track flaky tests in a 'quarantine' but make sure they get fixed within 2 weeks.
What is a good bug report?
Show model answer
A good bug report has: 1) Clear title (specific, not 'doesn't work'). 2) Steps to reproduce, numbered, exact. 3) Expected result. 4) Actual result. 5) Environment (browser, OS, version). 6) Screenshots or video if visual. 7) Severity (blocker / major / minor / cosmetic). 8) Frequency (every time / sometimes / once).
What's the difference between API testing and UI testing?
Show model answer
API testing: hits the backend directly. Fast, stable, easier to automate. Tools: Postman, REST-assured, supertest. UI testing: drives a real browser. Closer to user experience but slower and flakier. Tools: Cypress, Playwright, Selenium. Rule: test as much as possible at the API level, only test critical flows through the UI.
Tell me about a critical bug you found.
Show model answer
STAR. What was the bug, how you found it, who was affected, your communication, the fix. Bonus: how you prevented it from happening again (new automated test, new monitoring).
Pick a bug that had business impact. 'I prevented £50k loss' beats 'I found a typo'.
How do you handle a developer who disagrees with your bug report?
Show model answer
Stay factual. Show the steps to reproduce on a screen share. If they still disagree, escalate to the PM or tech lead for a decision — don't push it personally. Ultimately, the user-impact decides. Show empathy: devs feel ownership of their code. The goal is a better product, not 'being right'.
You're given a new feature to test in 2 days. How do you prioritise?
Show model answer
(1) Read the spec. (2) Identify the critical user flows and risks. (3) Test happy path first — if that breaks, ship date slips. (4) Test edge cases and negative paths. (5) Cross-browser/device for user-facing features. (6) Skip nice-to-have testing if time runs out. (7) Document what was NOT tested so the team can decide whether to ship anyway. Communication > completeness.