Testing Roles and Core Principles

Friday night the checkout page breaks for every customer paying with a saved card. On Monday the support queue holds 40 tickets, and the retro opens with the question every QA engineer answers at some point, in some form, in a job interview: what did QA own here, and where was that ownership when the build went out? The answer is not a job title. Three activities define the work, and each has a different boundary.

Verification asks whether the software matches its requirements. Did the saved-card flow charge the right amount, write the correct order record, and land the user on the confirmation page? Validation asks something harder: whether the requirements describe what users actually need. Maybe the flow behaves exactly as specified, but the spec never accounted for expired saved cards — the software is verified and still wrong. Defect prevention is the highest-leverage of the three: reviewing requirements for ambiguity before code exists, pushing for tests that run on every commit, and treating a bug caught in a pull request as an order of magnitude cheaper than one caught in a release candidate.

ISTQB draws a line that interviewers like to probe: testing is the activity of executing software to find defects, while quality assurance is the process-improvement work around it — standards, reviews, metrics, and process change. A working QA engineer does both, and the distinction matters when someone asks whether you are a tester or an advocate for quality. The honest answer is that you verify and validate the product, prevent what you can, and improve the process that produced the last defect.

Equally important is what the role does not own. You do not write the production fix. You do not unilaterally decide release scope. And — the misconception that burns out juniors — you are not the team's quality police. If quality were yours alone, the other four engineers on the team would have no reason to care about it, and every defect would funnel through one person. Quality is a team responsibility: the developer who unit-tests the payment service, the product owner who writes testable acceptance criteria, and the QA engineer who designs the suite each hold a different piece of the same outcome.

In the day-to-day this shows up as sitting in refinement and asking how a story would be tested while the cost of a change is still a comment in a document. It shows up in defect reviews where you bring reproduction steps and logs instead of blame. And it shows up in three numbers you should be able to defend in any status meeting: escaped defects per release (bugs users found that you did not), requirement coverage percentage (requirements with at least one passing test), and mean time from report to fix. Those metrics make the role legible to people who have never written a test case in their lives.

When you interview for a QA role, expect scenario questions built on exactly this boundary: a developer says a bug is not reproducible, a product owner wants to ship without regression testing, a support engineer reports something nobody can trigger. All three are ownership questions in disguise, and the strong answer always starts from the three activities above rather than from the title on your badge.

A team has one week of test time and a release with 40 changed files. Which files get tested first, how deeply, and what do you skip? The ISTQB testing principles are the standard answer set, and they show up by name in interviews — learn them as operating rules, not as a list to recite.

1. Testing shows the presence of defects, not their absence. Executing tests and finding nothing proves only that the inputs you tried worked. It cannot prove the software is defect-free, which is why release language matters: say 'no known critical defects at 95% requirement coverage', never 'the product is bug-free'. Passing tests reduce risk; they do not certify perfection.

2. Exhaustive testing is impossible. A single numeric field accepts billions of values; two fields multiply; add time, state, locale, and network conditions and the space explodes. A login form with a 20-character password field has roughly 95^20 input combinations before you count browsers. You cope with techniques — equivalence partitioning, boundaries, pairwise combinations — that sample the space where defects concentrate. That is the entire justification for the test design techniques you will study later in this phase.

3. Early testing saves time and money. The commonly cited cost curve is that a requirement ambiguity caught in review costs minutes, while the same ambiguity implemented, integrated, and deployed can cost 30 to 100 times more to repair, because it now drags along design documents, code, tests, documentation, and a release. This is the argument behind shift-left: testing a story during refinement, not after the code freeze.

4. Defects cluster. The Pareto observation holds across almost every real project: a minority of modules — often the payment logic, the importer, the concurrency-heavy scheduler — produce the majority of defects. Practical consequence: when your week runs out, spend it where past defects live. Read the last three releases' defect lists and weight your effort accordingly.

5. Tests wear out. A suite that caught everything in release 2.1 catches proportionally less in release 4.0 because the product changed underneath it. Regression suites need maintenance the same way production code does: retire cases for removed features, add cases for changed behavior, and treat a flaky or always-green test as a candidate for deletion or rewrite.

6. The test context matters. Testing a banking transfer and testing a meme generator deserve different rigor even with identical code quality. Risk profile, user trust, regulatory exposure, and release cadence all change what 'enough testing' means. Context is why a test strategy must be written per project — copying one from a previous employer is malpractice.

7. The absence-of-defects fallacy. You can ship a defect-free product that nobody wants because it solves the wrong problem. Testing that only hunts bugs never raises this; testing that validates against real user needs does. This is the principle that justifies exploratory testing and user-acceptance sessions over pure scripted regression.

An interviewer who asks 'which testing principle do you consider most important and why?' is not testing recall — they want to hear you tie a principle to a decision you made. The best answers name one principle, give a real example where it changed your plan, and admit what it cost you to apply it.

You have six testing days, three environments, and a release containing changes to checkout, search ranking, the footer, and an internal admin tool. Testing all four equally is not thoroughness — it is a failure to prioritize, and it is how critical paths ship untested while decorative CSS gets a full regression pass. Risk-based thinking is the skill that turns 'test everything' into 'test this first'.

The working formula is simple enough to do on a whiteboard:

risk(feature) = likelihood(failure) × impact(if it fails)

Likelihood is informed by evidence, not vibes: how new is the code, how complex is the logic, how many developers touched it, does it have history of defects, is it concurrency-heavy or dependent on third-party services. A rewritten payment router in its first release is high likelihood. A static footer untouched for two years is low.

Impact is a business judgment you make with other people: what happens to revenue, to users, to data integrity, and to the team's reputation if it fails. Checkout failing is total — no orders, no money, immediate tickets. Search ranking degrading is partial — users still buy, but conversion drops measurably. The admin tool failing affects five internal users during business hours. Footer rendering wrong on one browser affects nobody's ability to purchase.

Score each on a 1-to-3 or 1-to-5 scale and multiply. The matrix below uses the classic three-band scale:

The honest part of this exercise is the last column: you are writing down what you will not test. That is the deliverable. A plan that says 'we tested 100% of the application' without naming the exclusions is hiding a decision; a plan that says 'footer and admin tool received smoke coverage only, because impact is low and both were unchanged for four releases' is a decision you can defend in a retro or an interview.

The scoring itself is a team sport. Run a short risk workshop — 45 to 60 minutes, with one developer, the product owner, someone from support, and you. Support brings the failure modes users actually hit; the developer brings the modules where the code is fragile; the product owner brings the revenue view; you bring the historical defect data. Disagreement is the point: if you score checkout risk 9 and the developer scores it 2, one of you has information the other lacks, and surfacing that gap before the release is worth the meeting alone.

Two traps to avoid. First, anchoring: scoring everything 3×3 because nobody wants to own a low number destroys the ranking — force the spread, or the matrix is decoration. Second, staleness: risk scores are a per-release activity. The admin tool that was safe last quarter may sit on top of the new permissions model this quarter, and the safest way to find that out is to rescore at planning.

Practice the mindset with a small exercise: take the last release your team shipped, list its changed areas, score them in five minutes without looking at the actual defect list, then compare with what really failed. When your high-risk picks match the real defects, your instinct is calibrated; when they miss, that miss is your next risk-workshop talking point.

This is also your interview story. Expect questions like 'you have two days to test a release — walk me through how you spend them', and the answer that scores highest always starts with impact and likelihood, names what gets cut, and ends with how you would communicate the accepted risk upward. For how that risk discussion becomes a written plan, continue to SDLC and the Test Lifecycle.