Cohesyve · Practice for candidates
Going for a QA Engineer role? Find out how you'd actually score.
Run a QA Engineer simulation built the same way employers build theirs, and get a full report showing exactly where you lost marks — before it counts.
5
free assessments a month
$0
no card required
Full
scored report every run
Every
question type included
5 free assessments a month · No card required · Pro from $16/mo
Overview
QA assessments look for a specific instinct: the ability to find the case nobody thought about. Rather than asking what testing is, they hand you a feature, a spec, or a bug report and score how systematically you break it down. This page covers what those tasks look like and how they are marked.
Why employers assess this role
Testing skill is close to impossible to read off a résumé — everyone lists the same tools. What separates strong QA candidates is coverage thinking and the discipline to write a defect report someone can act on, and both show up immediately in a practical task.
What gets tested
The format
Duration
45–75 minutes
Question types
- Design test cases for a described feature
- Find defects in a working application
- Write a defect report from a scenario
- Prioritise a backlog of issues with justification
Levels
Entry · Mid · Senior
What you'll be asked to do
Design coverage for a feature
Given a specification, produce the test cases. Scored on systematic coverage rather than volume — twenty well-chosen cases beat eighty overlapping ones.
- •Write the test cases for a password reset flow
- •Cover a discount code field that has rules about stacking and expiry
- •Test a file upload with constraints on size and type
Find what the spec left out
The highest-signal section. Specifications are deliberately incomplete and assessors watch for the candidate who notices and asks.
- •Identify every ambiguity in a short requirements document
- •State what happens on the boundary the spec does not mention
- •List the assumptions you would confirm before testing begins
Report a defect properly
You are scored on whether a developer could reproduce and fix the issue from your report alone, without asking a follow-up question.
- •Turn a vague user complaint into an actionable ticket
- •Write up an intermittent failure with the information needed to chase it
- •Assign severity and priority, and justify the difference between them
Prioritise under constraint
Given more to test than time allows, decide what gets covered. Reasoning matters more than the specific answer.
- •You have two hours before a release; what do you test and why
- •Rank five open defects for a release decision
- •Decide what to automate first given a limited budget
Cohesyve for candidates
Practise a QA Engineer assessment before the real one
Run the same AI job simulations companies use to evaluate applicants. You get a scored report showing where you're strong and where you're not, plus what to work on.
Sample tasks — and what strong looks like
Design the test cases for a login form with email, password, and a "remember me" checkbox.
EntryWhat strong looks like: Goes well beyond valid and invalid credentials — boundary lengths, whitespace and case handling in the email, rate limiting and lockout, session behaviour with and without "remember me", concurrent sessions, and password manager interaction. Weak answers list five happy-path cases.
A user reports "the app is broken sometimes". Turn this into something a developer can act on.
MidWhat strong looks like: Asks the narrowing questions first — which action, which platform, how often, since when — then produces reproduction steps, expected versus actual behaviour, environment, and evidence. Weak answers file the complaint as written.
Here is a spec for a shopping basket. List everything it fails to specify.
MidWhat strong looks like: Identifies genuinely undefined behaviour — what happens at zero quantity, when stock changes mid-session, when a currency or price updates between adding and checkout — rather than asking cosmetic questions.
You have a fixed automation budget. Decide what to automate and defend the choice.
SeniorWhat strong looks like: Weighs execution frequency, failure cost and stability, avoids automating the things that change constantly, and explicitly names what will stay manual and why.
How to prepare
- #1
Practise boundary and equivalence analysis until it is automatic. It is the single highest-yield technique in these assessments.
- #2
Write defect reports for bugs you encounter in everyday software, then reread them the next day and ask whether a stranger could reproduce the issue.
- #3
Train yourself to read a spec looking for what is missing rather than what is written.
- #4
Rehearse explaining severity versus priority — it comes up frequently and is often answered vaguely.
- #5
Time yourself producing coverage for an unfamiliar feature. Breadth under time pressure is what is being measured.
- #6
Run a full scored simulation so you find out whether your coverage instinct holds up when it is marked.
Common mistakes
Listing many similar happy-path cases and calling it coverage.
Writing defect reports without reproduction steps or expected behaviour.
Testing only what the spec states and never questioning what it omits.
Treating severity and priority as the same thing.
Proposing automation for everything without regard to cost or stability.
Failing to prioritise when explicitly asked to work under a time constraint.
How it's scored
| Criterion | What strong looks like |
|---|---|
| Coverage thinking | Cases are organised by a visible technique — boundaries, equivalence classes, state transitions — rather than produced ad hoc. |
| Finding the unstated case | Identifies ambiguity and undefined behaviour in the specification and raises it rather than quietly assuming. |
| Defect report quality | Reproducible from the report alone, with expected versus actual, environment, and evidence attached. |
| Prioritisation | Decisions are tied to risk and impact and the reasoning is stated, not just the ranking. |
| Communication | Written clearly enough that a developer or product manager could act without a follow-up conversation. |
Frequently Asked Questions
Do I need automation experience to pass a QA assessment?
For manual and hybrid roles, usually not — coverage design and defect reporting carry most of the weight. Automation-specific roles will test it directly, and that is normally stated in the job description.
How many test cases should I write?
Enough to show a system, not as many as possible. A structured set covering boundaries, error paths and state transitions scores better than a long list of near-duplicates.
Will I be asked to write code?
Sometimes, for automation-focused roles. Where code appears in a general QA assessment it is usually reading rather than writing — spotting what a snippet fails to handle.
What is the most common reason people fail?
Shallow coverage. Candidates test what the feature is supposed to do and never systematically test what happens when it is used incorrectly, concurrently, or at a boundary.
Can I practise a scored QA assessment first?
Yes. Cohesyve gives you five free assessments a month with a full report, so you can see how your coverage is actually marked before it matters.
Practise another role
Cohesyve · Practice for candidates
Practise a QA Engineer assessment now — free.
Five scored assessments a month, a full report on every run, and a learning pathway built from what you got wrong. No card required.
5
free assessments a month
$0
no card required
Full
scored report every run
Every
question type included
5 free assessments a month · No card required · Pro from $16/mo
For hiring teams
Hiring for a QA Engineer role? See how your applicants perform before you spend interview time.