Software Tester interview questions and practice.
Executes manual and exploratory tests against software, logs defects clearly and verifies fixes before release.
No card for the taster. Full interviews are paid one at a time. Nothing renews.
Last reviewed
This page is still being written: no authored question bank for this competency family. The role is fully supported in the interview itself; only the published question bank is outstanding.
What interviewers for Software Tester actually ask
The question bank for this role is still being written. These are the first three competencies in the model the interview is scored against.
Decides what to test, how deeply and at which level based on risk, change impact and user value, rather than testing everything equally.
Designs tests that find real defects using techniques like boundary analysis, state models and equivalence classes, and explores beyond the specification.
Builds automated tests that are reliable, maintainable and fast, at the right layer, and keeps flaky tests from eroding trust in the suite.
What they are really assessing
Interviewers rarely score whether you seemed nice. They score against a model like this one, usually without telling you it exists. Each competency has a weak, adequate and strong shape, and the difference is almost always the level of specific detail you volunteer without being asked.
Test strategy & risk-based prioritisation
Decides what to test, how deeply and at which level based on risk, change impact and user value, rather than testing everything equally.
- Weak
- Testing is running the same regression suite every time; cannot explain how they decide what not to test, or link test effort to risk or business impact.
- Adequate
- Prioritises by feature criticality and recent changes and has a documented strategy, but coverage decisions are not revisited using escaped-defect data.
- Strong
- Explains a risk-based strategy for a real release with the test levels chosen for each area, what was deliberately left untested and why, and how escaped defects fed back into the strategy.
Test design & exploratory testing
Designs tests that find real defects using techniques like boundary analysis, state models and equivalence classes, and explores beyond the specification.
- Weak
- Tests are the acceptance criteria restated as steps; cannot name a test design technique or a defect found outside the spec; exploratory testing means 'clicking around'.
- Adequate
- Uses boundary and equivalence techniques and runs charter-based exploratory sessions, and can name defects found this way, but session notes and coverage of states are patchy.
- Strong
- Gives a specific defect found through a technique (state transition, pairwise, negative path) that the spec missed, explains the charter and heuristics used, and how findings changed the acceptance criteria.
Test automation engineering
Builds automated tests that are reliable, maintainable and fast, at the right layer, and keeps flaky tests from eroding trust in the suite.
- Weak
- Automation is record-and-playback UI scripts that break on every change; flaky tests are retried until green; cannot explain page objects, test data isolation or API-level testing.
- Adequate
- Writes maintainable UI and API tests with a framework and stable selectors, and has reduced flakiness, but suite runtime and reliability are not measured or targeted.
- Strong
- Describes a suite with measured pass rate and runtime, how they pushed tests down the pyramid, isolated test data and quarantined flaky tests, and a regression the suite caught before release.
Defect investigation & reporting
Isolates defects to reproducible steps, gathers logs and evidence, assesses severity honestly and writes reports developers can act on immediately.
- Weak
- Bug reports say 'it doesn't work' with a screenshot; severity is always high; cannot describe narrowing a bug down or checking logs before filing.
- Adequate
- Writes reproducible reports with environment, steps, expected/actual and logs, and assigns severity sensibly, but rarely investigates root cause or checks for duplicates and patterns.
- Strong
- Gives an example of isolating an intermittent bug (varying data, timing, environment) to a minimal repro with logs, and of a pattern spotted across bugs that led to a design or process fix.
Quality advocacy & shift-left
Influences quality before code is written by reviewing requirements, pairing with developers and challenging release decisions with evidence.
- Weak
- Sees QA as a gate at the end; does not attend refinement or review requirements; cannot describe a release they argued against or a requirement they improved.
- Adequate
- Reviews stories for testability and raises gaps in refinement, and has flagged release risk, but the flag was overridden and they cannot say how they made the case.
- Strong
- Describes a specific requirement ambiguity caught before development, a release recommendation made with defect and coverage data, and how they got developers to write more of their own tests.
Performance, security & compatibility testing
Tests beyond functionality: load and performance, basic security checks, accessibility and cross-browser or device compatibility, with meaningful targets.
- Weak
- Only functional testing; performance means 'it felt fast'; has never run a load test, an accessibility check or a security scan.
- Adequate
- Has run load tests with a tool and basic security or accessibility scans, and reported findings, but targets were arbitrary and results were not tied to production behaviour.
- Strong
- Describes a load test designed from production traffic patterns with clear thresholds, a bottleneck it found and the fix verified, plus accessibility or security findings that changed the release.
Release judgement under deadline pressure
Gives honest, evidence-based go/no-go input when deadlines are tight, and negotiates scope or risk acceptance rather than quietly cutting testing.
- Weak
- Signs off because the date was fixed; cannot describe what was skipped or who accepted the risk; frames release problems as the developers' fault.
- Adequate
- Documented what was not tested and told the manager, but the risk was not framed in business terms and there was no explicit risk acceptance.
- Strong
- Gives a case where they presented untested areas with likely user impact, got an explicit risk decision from the product owner, and what happened after release including what they changed next time.
Reading the questions is the easy half. Try answering three of them out loud, to someone who follows up.
Try 5 minutes freeWhat your 30 minutes covers
The same shape as a real first-round interview, pitched at mid-level Software Tester and scored throughout.
Warm-up, then Motivation & fit
Build rapport, settle nerves, and get a short walk-through of your background. Why this role, why this employer, and what you are actually looking for.
Your experience
Two or three real situations from your CV in depth: context, what you did, what happened, what you would change.
Pitched at mid-level scope: owns the test approach for a product area including automation and release recommendations; accountable for escaped defects in that area.
Role-specific questions
The core competencies and domain knowledge for the role, with follow-ups on anything vague.
Drawn from this role's domain: building a risk-based test plan for a release with limited time, applying boundary, equivalence and state-transition techniques to a feature and designing a maintainable UI automation framework and choosing selectors, and the rest of the competency model.
Your questions, then Wrap-up
Your questions for the interviewer, and yes, they are assessed. Next steps and a clean finish.
What changes with seniority
The questions barely change between levels. What changes is the answer they will accept.
| Junior | Mid | Senior | |
|---|---|---|---|
| Scope of ownership | Owns test execution and defect reporting for features, writes and maintains test cases, starts contributing to automation with review. | Owns the test approach for a product area including automation and release recommendations; accountable for escaped defects in that area. | Owns quality strategy and automation architecture across multiple teams; accountable for the effectiveness and cost of the test approach. |
| Tolerance for ambiguity | Handles stories with some gaps by asking targeted questions in refinement. | Builds a test strategy from a rough feature description and identifies risks the team has not considered. | Defines quality goals from business risk; makes tooling and process decisions with incomplete information and owns the results. |
| People leadership | None formally. | Mentors juniors, reviews test code, may coordinate testing across a small team. | Technical lead for testers, sets standards, coaches developers on testing, drives shift-left practices. |
| Who they deal with | Own team, developers, product owner. | Developers, product owners, release managers, support. | Engineering managers, product leadership, DevOps, compliance where relevant. |
What your report would say
Every competency above scored from your own answers, the sentence that cost you quoted back, and your weakest answers rewritten the way a strong Software Tester would have said them.
- Describes a suite with measured pass rate and runtime, how they pushed tests down the pyramid, isolated test data and quarantined flaky tests, and a regression the suite caught before release.
The format, not a result. Scores on your report come from what you actually said.
Is the AI interviewer realistic? See a full sample report