QA engineers
A QA engineer owns quality as a discipline rather than as a checkpoint at the end of a sprint. The work starts with questioning requirements before anything is built, continues through deciding what is worth testing at all, and ends in a defensible view on whether a release is fit to reach users. This guide explains the scope of the work, the pressures that make it necessary, and how to distinguish a candidate who thinks about risk from one who follows a script.
What does a QA engineer do?
A QA engineer works out how a software product can fail and makes sure the team learns about those failures before its users do. The work covers reviewing requirements and acceptance criteria for ambiguity before development starts, designing tests around where risk actually sits, exploring the product to surface problems that no scripted check would have looked for, reporting defects clearly enough that they are understood and prioritised correctly, and advising on whether a release is ready. It is fundamentally a judgement role: the defining skill is deciding what deserves attention, and what does not, within the time available.
The hardest part of the job is subtraction. Exhaustive testing is not merely impractical, it is arithmetically impossible — a form with ten fields and a handful of valid states each produces more combinations than any team could execute in a lifetime. Every testing decision is therefore an allocation decision, and two people can run the same number of cases while producing entirely different amounts of information. This is also why full coverage is a poor target: code coverage records which lines executed while tests ran, not whether the resulting behaviour is correct, whether the assertions were meaningful, or whether the requirement was right in the first place.
Much of the highest-value work happens before code exists. Defects overwhelmingly originate in misunderstanding rather than in mistyping — an acceptance criterion that does not say what happens when the input is empty, a business rule two people read differently, an integration whose failure behaviour was never discussed. Asking what happens at the boundary while a specification is still being written removes a defect that would otherwise be found, reported, triaged, fixed, reviewed and retested. Finding bugs is the visible part of the role; preventing them is the more valuable part, and it is largely invisible, which is why it has to be recognised explicitly as part of the job.
There is a persistent organisational trap around this role. Where quality is treated as a department rather than as a shared property of the team, QA becomes a gate that work is thrown over: engineers test less carefully because somebody else will, unverified work accumulates at the end of every sprint, and the person meant to be improving quality spends their time processing a queue. The productive arrangement is the opposite — raising the whole team’s testing ability, making risk visible early, and doing the exploration and analysis nobody else has the time or the frame of mind for.
When teams need this capability
Most teams test their own work adequately for a while. These are the pressures that usually reveal the limits of that arrangement.
Escaped defects keep tracing back to the requirement
Post-release problems turn out not to be coding errors but disagreements about what was supposed to happen. Nobody is interrogating specifications for ambiguity before they reach a sprint, so the same misunderstanding is discovered repeatedly at the most expensive point in the cycle.
Nobody can say whether a release is safe to ship
The decision is made on a feeling, on whether the pipeline is green, or on whoever sounds most confident in the stand-up. When something goes wrong afterwards there is no record of what was known and what was assumed, so the same conversation happens again at the next release.
Failures cluster where features meet
Each feature works when examined alone and the problems appear in the interactions between them — a permissions change that alters what an export contains, a currency setting that reaches one screen and not another. Engineers testing their own work rarely cross those boundaries, because the boundary belongs to nobody.
Bug reports are costing more than the bugs
Reports arrive without reproduction steps, without environment detail, without an actual-versus-expected statement, and sometimes without agreement that the behaviour is wrong at all. Engineers spend a substantial share of their time reconstructing reports rather than fixing what they describe.
The product has obligations beyond working correctly
Accessibility conformance, regulatory requirements, data-handling rules or contractual service commitments create categories of failure that functional tests do not look for and that developers are not positioned to notice while building.
The team is only ever confirming its own expectations
People test what they intended to build. That is a cognitive limit rather than a discipline problem, and it is why an engineer can test their own work thoroughly and still miss the case they never imagined. Someone whose professional habit is looking for the unexpected finds a different class of defect entirely.
Core capabilities
Risk analysis
Working out which parts of a product would hurt most if they broke, how likely each is to break, and directing effort accordingly. It depends on understanding the business as well as the software — the technically fragile component and the commercially critical one are frequently not the same thing.
Test strategy
Deciding what is checked automatically, what is examined by a person, what is verified in production through monitoring, and what is knowingly left untested. A strategy that does not say what will not be tested is a wish list rather than a plan.
Requirements and acceptance criteria analysis
Reading a specification for what it fails to say: missing boundary conditions, undefined error behaviour, implicit assumptions about ordering or state, and rules two readers interpret differently. The questions asked at this stage remove defects rather than detect them.
Test design technique
Applying equivalence partitioning, boundary value analysis, decision tables, state transition modelling and pairwise combination to reduce an impossible input space to a defensible set of cases. This is the difference between coverage that is argued for and coverage that is asserted.
Exploratory testing
Structured investigation in which designing, executing and learning happen together, usually organised into time-boxed sessions with an explicit charter. Done well it is disciplined and documented, and it finds defects that predetermined scripts cannot, because a script only looks for what somebody already thought of.
Defect reporting and advocacy
Writing a report a stranger can reproduce, and then making the case for why the problem matters. Advocacy is the underrated half: a correctly reported defect filed at the wrong severity, or described in a way that obscures its user impact, is quietly deprioritised and shipped.
Triage and severity judgement
Separating severity from priority, recognising when several reports describe one underlying cause, and identifying the report that looks cosmetic but indicates something structurally wrong. Reliable triage keeps the defect backlog a decision-making instrument rather than a graveyard.
Release readiness judgement
Assembling what is known and what is not into a statement a decision-maker can act on: which risks were examined, which were accepted, what was not covered, and what should be watched after deployment. The role is to inform the release decision with evidence, not to hold a veto.
Usability and accessibility observation
Noticing behaviour that is technically correct and practically wrong — a destructive action without confirmation, an error message that tells the user nothing actionable, a flow that cannot be completed with a keyboard. Specialist auditing is its own field, but a great deal is caught before an auditor ever sees it.
Domain understanding
Knowing what the software is for and who depends on it. Domain knowledge turns "the total is not what I expected" into "this rounds tax the wrong way for orders shipped to a second jurisdiction", and it is generally the fastest-appreciating asset a QA engineer holds.
Technology ecosystem
Common technologies in quality assurance are listed below. This describes the landscape of the discipline as it is practised, not a claim about any particular engineer’s toolkit. Tools matter less here than in most engineering roles, because the substance of the work is analysis and judgement rather than operating a particular product.
Test management and tracking
- Jira
- TestRail
- Xray
- Zephyr
- Azure Test Plans
Inspection and exploration
- Browser developer tools
- Postman
- Charles Proxy
- Fiddler
- SQL clients
- Feature flag consoles
Specification and collaboration
- Gherkin
- Example mapping
- Confluence
- Notion
- Miro
Accessibility and usability checks
- axe DevTools
- WAVE
- NVDA
- VoiceOver
- Lighthouse
Production signals
- Sentry
- Datadog
- Grafana
- Kibana
- Session replay tools
Device and platform coverage
- BrowserStack
- Sauce Labs
- Xcode Simulator
- Android Emulator
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- Product
- Business priorities
- Roadmap
- Architecture
- Sprint priorities
- Engineering standards
- Day-to-day technical collaboration
Talent.ID handles
- Employment relationship
- Payroll
- Employee benefits
- Talent administration
- Ongoing employee relationship
What to look for when hiring
QA candidates are commonly assessed on the wrong axis. Tool familiarity and certification are easy to verify and weakly predictive; the qualities that separate a strong QA engineer from a competent one are analytical and communicative, and they surface only if you ask for specifics.
Risk reasoning
Present a product area and ask what they would test first and what they would leave alone. The answer exposes whether they think in terms of consequence and likelihood or in terms of covering everything they can see. Candidates who cannot name something they would deliberately not test have usually not worked to a real deadline.
- Distinguishes what is likely to break from what would be costly if it did
- Asks about users, transaction value or regulatory exposure before proposing tests
- Can name a risk they accepted, and explain how they made that visible to others
Requirements interrogation
Hand over a short, deliberately incomplete acceptance criterion and watch what they ask. This is the most informative exercise available for the role, because prevention is where the return on it is concentrated and the skill is impossible to fake in real time.
- Goes straight to boundaries, empty inputs and failure behaviour
- Notices what the criterion does not say rather than only checking what it does
- Raises questions in a way an author would find useful rather than adversarial
Exploratory testing skill
Ask them to describe a session in detail: what they set out to learn, how they varied their approach when nothing surfaced, and what they recorded. Weak candidates describe clicking around; strong ones describe a method with a purpose and a record of what was covered.
- Works from a charter or an explicit question rather than a general look
- Can describe how one observation redirected the rest of the session
- Leaves behind notes another person could act on
Defect communication
Ask for a defect they had to argue for, and one they decided not to raise. The first shows whether they can make impact legible to people who are not looking at the software; the second shows whether they exercise judgement or simply file everything they notice.
- Describes user or commercial impact rather than only the incorrect behaviour
- Separates severity from priority without treating the distinction as academic
- Has changed a mind about a defect with evidence rather than persistence
Release judgement
Ask how they would advise on shipping when something is still unresolved. It shows whether they think of the role as a gate or as a source of information. Someone who reports a residual risk clearly and lets the accountable person decide is more useful than someone who blocks, or who waves things through.
- Reports what is unknown alongside what was verified
- Proposes post-release monitoring as an alternative to further pre-release testing
- Does not treat an open defect as automatically disqualifying
Relationship with engineers
Quality work fails when it becomes adversarial. Ask how they handled a disagreement with a developer, and how they help a team test its own work better. Someone who raises everyone else’s standard is worth considerably more than someone who personally finds more defects.
- Talks about improving the team’s testing rather than only their own output
- Gets involved before implementation rather than after a handover
- Can disagree about a defect without it becoming a matter of position
Curiosity about the product
The best diagnostic question is often simply what the product does and who uses it. Candidates who understand the domain describe testing in terms of consequences for users; candidates who do not describe it in terms of screens and buttons. The gap between those two answers is large and persistent.
- Explains a previous product’s purpose before describing how they tested it
- Has learned a domain rule deeply enough to have caught a subtle error with it
- Asks who is harmed when a given behaviour goes wrong
Interview questions worth asking
Questions that surface reasoning rather than terminology. They are set out here for use inside your own selection process — you interview each candidate, and you decide who joins your team.
You have two days before a release and far more than two days of testing you could do. How do you decide what to test?
What a strong answer shows
Whether prioritisation is a practised habit or an improvised one. Strong answers reason from change, consequence and likelihood, name what they would consciously skip, and describe how the residual risk would be communicated rather than quietly absorbed.
Here is an acceptance criterion for a feature. What questions would you ask before development starts?
What a strong answer shows
Preventive instinct. Listen for boundaries, empty and maximum values, concurrent access, failure of a dependency, and what should happen to data already in the system. The number of questions matters less than whether they are the ones that would have caused a rewrite.
Tell me about a defect that everything passed through. What let it out, and what changed afterwards?
What a strong answer shows
Whether they analyse escapes systemically or treat them as bad luck. The strongest answers identify the point at which the defect could first have been caught, and describe a change to that point rather than the addition of one more test case.
Is 100% test coverage a goal worth pursuing? Why, or why not?
What a strong answer shows
Whether they understand what coverage measures. A candidate who wants full coverage has usually not maintained a suite; one who dismisses coverage entirely may not use it at all. The best answers treat it as a signal for finding untested areas, never as a target to be met.
A developer says a defect you raised is not worth fixing. How do you handle it?
What a strong answer shows
Advocacy and proportion together. Look for someone who restates the impact in terms the developer or product owner cares about, who accepts a reasoned decision, and who knows when a disagreement should be escalated rather than repeated.
How do you test something you do not understand — an unfamiliar domain, or a feature nobody has documented?
What a strong answer shows
Method under uncertainty, which is the ordinary condition of the job. Strong answers describe finding out who the users are, reading whatever exists, building a model of the intended behaviour and then testing the software against that model.
What have you done that improved quality without you personally finding a defect?
What a strong answer shows
Whether they understand where the role pays off most. Answers might involve rewriting acceptance criteria, introducing an example-mapping session, or improving how defects are triaged. Candidates who measure themselves only by defect count rarely have an answer.
Describe a time you decided something was ready to release despite an open problem.
What a strong answer shows
Comfort with judgement rather than rules. Look for a clear statement of the risk, who made the call, what monitoring was arranged, and whether the outcome was reviewed. An unwillingness to ever accept a known problem is a warning sign in its own right.
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- A team is moving to a more frequent release cadence and finds that its quality process does not survive the change. Verification has been happening in a block at the end of each cycle, defects surface too late to fix without slipping the date, and nobody can give the product owner a clear account of what has and has not been examined before a deployment.
- Approach
- Additional quality capacity works inside the team’s existing delivery process — their ticket workflow, their definition of done, their release cadence and their quality standards. The client’s engineers and product owner continue to set priorities and decide what ships; the additional capacity contributes risk analysis, test design and exploratory work alongside them rather than operating as a separate stage the work must pass through.
- What this adds to the team
- The team gains quality capacity while keeping ownership of its product decisions and its engineering standards. What counts as ready to release remains the client’s judgement.
Related disciplines
Frequently asked questions
- What is the difference between a QA engineer and a test automation engineer?
- A QA engineer is accountable for quality as a discipline: which risks matter, what a specification leaves undefined, what scripted checks would never think to look for, and whether a release should go out. A test automation engineer is accountable for the automated testing system itself — framework design, test data, environment control, keeping results deterministic, and making execution fast enough to be worth waiting for. The first role is defined by breadth of judgement; the second is an engineering role whose deliverable is the suite. The two are complementary rather than interchangeable: a suite built without quality judgement will check the wrong things very reliably.
- Do QA engineers need to write code?
- Enough to be effective, which is usually less than job adverts imply. Reading the codebase, querying a database, calling an API directly, following a stack trace and inspecting network traffic all raise the quality of the work substantially. Building and maintaining an automation framework is a different job with a different centre of gravity, and requiring strong programming ability in a QA role tends to filter out the analytical and communicative candidates the role most depends on.
- Does having a QA engineer slow the team down?
- It does when quality is arranged as a gate: work is completed, handed over, queued, returned and reworked, and the handover itself becomes the constraint. It generally does not when the QA engineer is involved from the point requirements are written, because the defects that never get built are the ones that would have cost the most time. If adding quality capacity has slowed a team down, the arrangement is usually the cause rather than the person.
- Can developers just test their own work?
- They should, and it is not sufficient on its own. Developers testing their own work verify that it does what they meant it to do, which leaves the cases they never considered untouched — and no amount of diligence fully removes that limit, because it is a property of having built the thing. A QA engineer brings an independent model of what the software is supposed to do, and habits aimed at the unexpected rather than the intended.
- Should QA report into engineering or sit as a separate function?
- Embedding QA engineers in delivery teams generally works better, because proximity is what makes prevention possible and distance is what turns quality into a handover. A separate reporting line can help maintain professional standards across a larger organisation, but where quality assurance becomes an independent department that receives finished work, the familiar failure follows: engineers test less carefully, the queue lengthens, and quality becomes something the team believes it has outsourced.
- What seniority does quality work need?
- It depends on how much is unsettled. Executing an established approach against well-specified features can be done well at mid level. Establishing what a team should test at all, negotiating risk with a product owner, or building a quality practice where none exists needs someone who has seen how those decisions play out over time — and the cost of weak judgement here appears months later, in the shape of what the team stopped noticing.
- How do QA engineers work with an existing engineering team?
- Embedded in your team, a QA engineer follows your existing delivery process — your workflow, your definition of done, your engineering standards and your release cadence. This is a staff augmentation arrangement, so day-to-day priorities, product direction and the decision to ship all remain yours. Talent.ID’s side of it is talent administration, payroll, employee benefits and the continuing relationship with the employee.
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.