Manual Testing interview questions

Severity is about impact on the product: how badly does this defect hurt the system, does it crash, does it lose data, does it block a main flow. Priority is about urgency: how soon does it need to be fixed, which is a business call driven by the release date, how visible the defect is to customers, and what it costs to leave it. They are two independent scales, so all four combinations are real. A crash on a browser version almost nobody uses is high severity and low priority. A spelling mistake in the brand name on the home page is low severity and high priority.

Give the two definitions in one line each, then win the question with the mismatched examples, because that is what the interviewer is listening for. The trap is defining both as the same thing in different words. The senior signal is being clear that they are independent scales, and being ready for the follow-up about who sets which.

How to phrase it

Severity is about impact on the product. How badly does this defect hurt the system: does it crash, does it corrupt data, does it block a main flow. Priority is about urgency. How soon does it need to be fixed, and that is a business decision driven by the release date, how visible it is to customers, and what it costs to leave it sitting there. These are two independent scales, so every combination happens. High severity with low priority: the application crashes, but only on a very old browser version that almost none of our users are on, so we log it and schedule it. Low severity with high priority: the company name is misspelt on the landing page. Technically nothing is broken, but every visitor sees it today, so it gets fixed first. On ownership, I set the severity because I have seen the failure and I know how bad it is. The product owner or project manager sets the priority. In a lot of teams I propose both and we agree them in defect triage, so I would say that too.

Key points to hit

• Severity: impact on the product, how badly it breaks things.
• Priority: urgency of the fix, a business call on when.
• Two independent scales, so all four combinations are real.
• High severity, low priority: a crash on a browser almost nobody uses.
• Low severity, high priority: the brand name misspelt on the home page.
• Tester proposes severity, product owner sets priority, both agreed in triage.

SEVERITY x PRIORITY, with a real example in each box

              | High priority (fix now)     | Low priority (fix later)
--------------+-----------------------------+---------------------------
High severity | Payment fails for everyone  | App crashes on a browser
              |                             | version almost nobody uses
--------------+-----------------------------+---------------------------
Low severity  | Brand name misspelt on the  | Tooltip text is slightly
              | home page                   | misaligned on one screen

Verification asks whether we are building the product right. It checks work products against their specification, usually without running the software: requirement reviews, design reviews, walkthroughs, static checks. Validation asks whether we built the right product. It checks the running software against what the user actually needs: functional testing, system testing, user acceptance testing. Verification is static and starts early, validation is dynamic and needs a working build. The cheapest defects in any project are the ones verification catches, because they never reach the code at all.

Use the classic one-liner (building the product right versus building the right product), then immediately make it concrete with activities, because the one-liner on its own sounds memorised. The senior signal is the cost point: verification catches defects before they are ever coded, which is the cheapest place to find them.

How to phrase it

The line everyone knows is that verification is about building the product right, and validation is about building the right product. That is correct, but on its own it sounds like something I memorised, so I would make it concrete. Verification is the static side. I am reviewing the requirement document, sitting in a design review, walking through a user story with the developer and the business analyst, checking that what we have written matches the specification. The software does not even need to exist yet. Validation is the dynamic side. The build is there, I am executing test cases, doing system testing, running user acceptance testing, and I am checking that the thing we built actually solves the user's problem. The point I like to add is about cost. A requirement that is ambiguous costs almost nothing to fix while it is still a sentence in a document. The same misunderstanding, found in production, costs a release. So verification is where a tester quietly saves the project the most money, and that is why I push to be in requirement reviews rather than waiting for a build.

Key points to hit

• Verification: are we building the product right. Static, against the specification.
• Validation: did we build the right product. Dynamic, against the user's real need.
• Verification activities: requirement reviews, design reviews, walkthroughs.
• Validation activities: functional, system and user acceptance testing.
• Verification starts before any build exists, validation needs a build.
• Defects caught in verification are the cheapest defects in the project.

Quality assurance is process focused and preventive. It defines how the team works: the standards, the review steps, the definition of done, so that defects are less likely to be created in the first place. Quality control is product focused and detective. It checks the actual build against the requirements to find the defects that did get created. Testing is one activity inside quality control, the hands-on execution part. In practice most Indian companies use QA as the job title for people doing quality control and testing work, so the words blur, and interviewers know that.

Give the clean textbook split first (process and preventive versus product and detective), then show you know real job titles do not follow it. The trap is reciting only the textbook. The senior signal is naming the overlap honestly and giving one concrete example of each, so you sound like someone who has worked in a team.

How to phrase it

The clean way to separate them is by what each one is trying to do. Quality assurance is about the process and it is preventive. It is defining how we work: the standards we follow, the review steps, the definition of done, the checklist before a story moves. The aim is that fewer defects get created at all. Quality control is about the product and it is detective. The build exists, and I am checking it against the requirements to find the defects that did get through. Testing is one activity inside quality control, it is the actual execution part. So as a nesting, testing sits inside quality control, and quality control sits inside the wider quality assurance effort. The honest part I would add is that in most companies the job title is QA engineer, and that person is doing quality control and testing all day. So I know the textbook boundary, I use it when I am asked, and I do not get precious about it in a real team. What matters is that someone is thinking about prevention and not only about detection.

Key points to hit

• QA: process focused and preventive, standards, reviews, definition of done.
• QC: product focused and detective, checking the build against requirements.
• Testing: the hands-on execution activity that sits inside QC.
• Nesting: testing inside QC, QC inside the wider QA effort.
• Real world: QA is the job title, the work is mostly QC plus testing.
• Know the textbook split, and say the overlap out loud rather than pretending.

Smoke testing is wide but shallow. On a fresh build you check that the application launches, login works and the main journeys open, so you can answer one question: is this build stable enough to spend a day testing. Sanity testing is narrow but deep. A specific area has just been changed or fixed, so you check that area and its close neighbours before committing to a full cycle. Smoke is usually a fixed set that runs on every build and is a good automation candidate; sanity is usually unscripted and decided on the spot. Worth knowing: ISTQB defines smoke testing but not sanity, so teams use the word loosely.

Use wide and shallow versus narrow and deep, then give the trigger for each, because that is what separates them in real life. The trap is a vague answer, since this pair is defined inconsistently across the industry. The senior signal is giving the expected definition confidently and then noting that teams use the terms loosely, so you name how your team used them.

How to phrase it

The shortest way I can put it is that smoke is wide and shallow, sanity is narrow and deep. Smoke testing happens when a new build lands. I check the basics across the whole application: does it launch, can I log in, do the main journeys open, does the checkout page load. I am not testing any of it properly. I am answering one question, which is whether this build is worth a full day of the team's testing time. If smoke fails, the build goes straight back. Sanity testing happens when something specific has changed, usually a defect fix or a small change. I go deep on just that area and the parts around it that could be affected, and I decide there and then whether the wider test cycle is worth starting. Smoke is normally a fixed set that runs on every build, which makes it a good first thing to automate. Sanity is normally unscripted and judgement led. One honest note I would add is that these two are defined a bit differently across companies, ISTQB does not even formally define sanity, so I always confirm what the team means by it rather than assuming.

Key points to hit

• Smoke: wide and shallow on a fresh build, is it stable enough to test.
• Sanity: narrow and deep after a specific fix or change.
• Smoke is a fixed set on every build, a strong first automation candidate.
• Sanity is usually unscripted and decided by judgement on the day.
• Failed smoke means the build is rejected, no full cycle is started.
• The terms are used loosely across companies, so confirm the team's meaning.

Retesting, also called confirmation testing, runs the exact test that failed, on the build where the defect is marked fixed, to confirm the fix actually works. Regression testing runs other tests around the change to confirm the fix has not broken something that used to work. Retesting is fully planned, because the test cases are already attached to the defect. Regression selection is a judgement call about blast radius: which areas share code, data or a screen with what changed. A myth worth correcting is that retesting cannot be automated. It can. It simply tends to be done by hand first because the fix is fresh.

Anchor each one to the question it answers: did the fix work, versus did the fix break anything else. The trap is repeating the popular claim that retesting cannot be automated, which is not true. The senior signal is explaining how you choose the regression scope instead of saying you run everything.

How to phrase it

They answer two different questions. Retesting, which is also called confirmation testing, answers did the fix actually work. The developer marks the defect fixed, I take the new build, and I run the exact steps that failed before. Nothing clever about it, the test cases are already attached to the defect, so the scope is completely known. Regression testing answers a different question: did this fix break anything that used to work. That one is a judgement call, because I have to think about blast radius. What shares code with this change, what shares the same screen, what reads the same database table. That is where I choose my regression set, and it is also why a good regression suite is the first thing worth automating, because I run it again and again. One thing I would gently correct is the claim that retesting cannot be automated. It absolutely can. It usually happens by hand first because the fix is fresh and I want to look at it properly, but there is nothing about retesting that stops you automating it once it settles.

Key points to hit

• Retesting: run the failed test again on the fixed build. Did the fix work.
• Regression: run tests around the change. Did the fix break anything else.
• Retesting scope is known, the cases are attached to the defect.
• Regression scope is chosen by blast radius: shared code, screens, data.
• Regression repeats every release, so it is the best automation candidate.
• Myth to correct: retesting can be automated too, it is simply done by hand first.

A test scenario is a single line saying what to test, at feature level: verify login with valid credentials. A test case is the executable version of that: preconditions, test data, numbered steps, expected result, and a space for the actual result. One scenario usually expands into several test cases, because valid, invalid, blank and locked-account are all different runs. Scenarios are written first and fast, to agree coverage with the business. Test cases come after, when you need repeatability and somebody other than the author has to run them.

Show the relationship (one scenario expands into many cases) rather than giving two flat definitions. The trap is treating them as alternatives. The senior signal is explaining why each exists: scenarios agree coverage quickly with the business, cases give repeatability so anyone can run them.

How to phrase it

A test scenario is a one line statement of what I am going to test, written at feature level. Something like verify login with valid credentials, or verify the user can apply a coupon at checkout. A test case is the detailed, runnable version of that: preconditions, the test data, numbered steps, the expected result, and a column for the actual result when it is executed. The relationship matters more than the definitions. One scenario normally expands into several test cases, because verify login is really valid credentials, wrong password, blank fields, locked account, and expired session. Each of those is its own case with its own data and its own expected result. On why both exist: I write scenarios first because they are fast, and I can sit with the business analyst and agree coverage in an hour without arguing about step wording. Then I write test cases, because a case has to be repeatable. Someone who has never seen the feature should be able to pick it up, follow the steps, and get the same result I would. That handover-ability is really the whole point of a test case.

Key points to hit

• Scenario: one line, what to test, written at feature level.
• Case: preconditions, data, numbered steps, expected result, actual result.
• One scenario expands into several test cases, one per condition.
• Scenarios come first and fast, to agree coverage with the business.
• Cases come after, for repeatability and handover.
• The test of a good case: a stranger can run it and get the same result.

ONE SCENARIO -> SEVERAL TEST CASES

Scenario: Verify login with valid and invalid credentials

ID     | Precondition  | Steps                       | Test data        | Expected result
-------+---------------+-----------------------------+------------------+-----------------------------
TC-01  | User is       | 1. Open login               | valid user,      | Dashboard opens, user name
       | registered    | 2. Enter creds  3. Submit   | valid password   | shown in the header
TC-02  | User is       | 1. Open login               | valid user,      | Error: Invalid credentials.
       | registered    | 2. Enter creds  3. Submit   | wrong password   | User stays on login
TC-03  | None          | 1. Open login  2. Submit    | blank, blank     | Field level messages on both
       |               |    with empty fields        |                  | username and password
TC-04  | 3 failed      | 1. Open login               | valid user,      | Account locked message with
       | attempts done | 2. Enter creds  3. Submit   | valid password   | the unlock path

A test strategy is the higher level, longer lived approach: the levels and types of testing the organisation does, entry and exit criteria, the automation stance, tooling, the defect process, the roles. It changes rarely. A test plan is specific to one project or release: scope, what is in and out, schedule, estimates, environments, test data, resources, risks and deliverables. Strategy answers how we test here, plan answers how we test this release. In practice many Agile teams merge the two into one short page, and in larger service companies the strategy sits with the QA practice while the plan sits with the test lead.

Separate them by shelf life and scope: strategy is organisation wide and stable, plan is release specific and dated. The trap is listing document sections. The senior signal is naming who owns each, and being honest that Agile teams often merge them, which shows you have worked in both setups.

How to phrase it

The easiest way to separate them is shelf life and scope. A test strategy is the long lived, organisation level document. It says how we test here in general: which levels we do, unit, integration, system, acceptance, what types we cover like functional, performance and security, our stance on automation, the tools we standardise on, how defects are raised and triaged, and who does what. It does not mention dates, and it might not change for a year. A test plan is specific to one project or one release. It has the scope, what is explicitly in and out, the schedule and estimates, the environments and test data we need, the risks, and the deliverables I will hand over. On ownership, the strategy usually sits with the QA practice or the test manager, and the plan sits with the test lead for that release. I would also be honest that in Agile teams these often collapse into a single short page, sometimes a one page test approach per epic, and that is fine. The intent is the same: agree how and how much we test before the pressure starts.

Key points to hit

• Strategy: organisation level, long lived, how we test here in general.
• Plan: project or release level, scope, schedule, estimates, environments, risks.
• Strategy has no dates. A plan is dated and specific.
• Strategy owned by the QA practice or test manager, plan by the test lead.
• Agile teams often merge both into a one page test approach, and that works.
• The purpose of both: agree how much testing is enough before the pressure starts.

Alpha testing happens in house, in a controlled environment, before the product goes outside. It is usually done by the internal test team, sometimes with a few customers invited to work alongside them. Beta testing happens with real users, on their own devices, their own network and their own data, before general release. Both are forms of acceptance testing. Alpha is the one you can control and instrument; beta is the one that surfaces the environment and usage problems no lab can reproduce. Beta feedback arrives messy, so you need a channel to collect it and a rhythm to triage it.

Split on two axes at once: who tests and where. The trap is saying only that beta is done by customers. The senior signal is naming what beta gives you that alpha cannot, real devices, real networks and real data, and mentioning that beta feedback needs a collection and triage process or it is wasted.

How to phrase it

The two things that change are who is testing and where they are testing. Alpha testing is in house. It runs in our own controlled environment, on our test data, usually with the internal test team, and sometimes we invite a handful of customers to sit with us and use it. Because it is our environment, I can instrument it, I can pull logs, I can reproduce anything quickly. Beta testing goes outside. Real users run it on their own devices, on their own network, with their own data, before we release to everyone. Both of these are types of acceptance testing, so I would group them that way. What I would stress is why beta earns its place. Beta finds the things a lab cannot: an older phone, a slow connection, a browser setting, a data pattern nobody imagined. But beta feedback arrives messy and unstructured, so it only works if we set up a proper channel to collect it, a way to ask for steps and screenshots, and a rhythm to triage what comes in. Without that, beta turns into a pile of comments nobody actions.

Key points to hit

• Alpha: in house, controlled environment, internal team, sometimes invited customers.
• Beta: real users, their own devices, network and data, before general release.
• Both are forms of acceptance testing.
• Alpha is controllable and instrumented, so reproduction is quick.
• Beta surfaces device, network and data problems a lab cannot reproduce.
• Beta needs a collection channel and a triage rhythm or the feedback is wasted.

Black box testing works from requirements and behaviour, without looking at the internal code. You supply inputs and check outputs. White box testing uses knowledge of the internal structure, code paths, branches and conditions, which is what lets you measure statement or branch coverage. Grey box sits between the two: you test through the interface, but you know something about the internals, for example the database schema or the API contract, so you can check what happened behind the screen. A manual tester lives mainly in black box and grey box, while white box is usually developer or SDET work.

Define the three by how much of the internals you can see, then place yourself honestly on that scale. The trap is claiming white box experience you do not have. The senior signal is showing what grey box lets you do, verifying the database or the API response behind a screen action, because that is where manual testers add real depth.

How to phrase it

The difference is simply how much of the inside I can see. Black box means I work from the requirement and the behaviour. I do not look at the code at all. I give the system inputs and I check the outputs against what the requirement promised. White box means I do look at the internal structure, the code paths, the branches, the conditions, and that is what lets you talk about statement coverage or branch coverage. That is usually developer or SDET work. Grey box is the middle, and honestly it is where a lot of my best work as a manual tester happens. I am still testing through the screen, but I know something about what sits behind it. I know the database schema, so after I submit a form I can run a SQL query and confirm the row was actually written with the right values. I know the API contract, so I can see whether the screen is showing me a cached value or the real response. So I sit mainly in black box and grey box, and grey box is where I find the defects a screen level tester misses.

Key points to hit

• Black box: requirements and behaviour only, no view of the code.
• White box: internal structure, paths, branches, coverage measurement.
• Grey box: testing through the screen with knowledge of the internals.
• White box is mostly developer or SDET territory at unit level.
• Grey box example: submit a form, then verify the row with a SQL query.
• Be honest about where you sit. Grey box depth is a real differentiator.

SDLC is the whole software development life cycle: requirements, design, development, testing, deployment and maintenance. STLC is the testing life cycle that runs inside it: requirement analysis, test planning, test case development, test environment setup, test execution and test cycle closure. The point people miss is that STLC is not a block that starts after coding finishes. It starts at requirements and runs alongside development, because reviewing a requirement is already a testing activity.

Name both sets of phases cleanly, then make the point that carries the answer: STLC starts at requirements, not after coding. The trap is describing testing as a phase that begins when the build arrives. The senior signal is showing what you produce in each STLC phase, which proves you have run one.

How to phrase it

SDLC is the life cycle of the whole product: requirements, design, development, testing, deployment and then maintenance. STLC is the testing life cycle that runs inside it, and its phases are requirement analysis, test planning, test case development, test environment setup, test execution and test cycle closure. The thing I would make sure to say, because a lot of answers get this wrong, is that STLC does not start after coding ends. It starts at requirements. While the developers are still building, I am analysing requirements and raising the ambiguous ones, I am planning scope and estimates, I am writing and reviewing test cases, and I am chasing the test environment and the test data, which in my experience is the thing that actually delays execution. So by the time the build arrives, the only phase left is execution and closure. Each phase also has something I hand over: a requirement clarification list, a test plan, reviewed test cases, an environment readiness confirmation, execution reports and defect logs, and a closure summary at the end. Naming those deliverables usually shows I have actually run this rather than memorised the six words.

Key points to hit

• SDLC: requirements, design, development, testing, deployment, maintenance.
• STLC: requirement analysis, planning, case development, environment setup, execution, closure.
• STLC runs inside SDLC and starts at requirements, not after coding.
• Reviewing a requirement is already a testing activity.
• Each STLC phase has a deliverable: clarifications, plan, cases, reports, closure.
• Environment and test data readiness is the phase that usually delays execution.

Equivalence partitioning splits input data into groups where every value should be treated the same way, so you test one value from each group instead of all of them. Boundary value analysis then tests the edges of those groups, because the off by one mistakes live exactly there. They are partners, not alternatives: partitioning tells you which groups exist, boundary analysis tells you which exact values to pick. For an age field that accepts 18 to 60, two value boundary analysis tests 17, 18, 60 and 61, and three value analysis adds 19 and 59.

Say up front that these two are used together, then work one concrete field end to end, because a worked example beats a definition every time. The trap is picking arbitrary values with no reasoning. The senior signal is explaining why boundaries fail so often: the code says greater than where it should say greater than or equal to.

How to phrase it

I would start by saying these two are partners rather than alternatives, and then work an example, because that lands much better. Take an age field that accepts 18 to 60. Equivalence partitioning says I group the inputs into sets where every value should behave identically. Here that gives me three groups: below 18 is invalid, 18 to 60 is valid, above 60 is invalid. Inside a group, the system cannot tell 30 from 45, so testing both adds no information. I pick one value from each group and I have covered all three behaviours in three tests instead of forty-three. Boundary value analysis then says the edges are where defects actually live, so I test right at them. In the two value form that is 17, 18, 60 and 61. In the three value form I also take 19 and 59. And the reason boundaries fail so reliably is simple: someone wrote greater than where they meant greater than or equal to, so exactly one value behaves wrongly, and it is always the edge. So in practice I partition first to decide what to cover, then apply boundary values to decide which numbers to type.

Key points to hit

• Partitioning: group inputs that should behave identically, test one from each.
• Boundary analysis: test the edges of those groups, where defects concentrate.
• They are used together, partition first, then pick boundary values.
• Age 18 to 60: valid, below-range and above-range partitions.
• Two value boundaries: 17, 18, 60, 61. Three value adds 19 and 59.
• Why edges fail: greater than written where greater than or equal to was meant.

FIELD: Age, accepted range 18 to 60

Equivalence partitions
  P1  below range   any value under 18     pick 10   expect: rejected
  P2  valid range   18 to 60               pick 35   expect: accepted
  P3  above range   any value over 60      pick 75   expect: rejected

Boundary values
  Two value BVA     17  18        60  61
  Three value BVA   17  18  19    59  60  61

  17 rejected | 18 accepted | 60 accepted | 61 rejected

Also worth a case each: blank, 0, a negative number, letters, a decimal.

A decision table lays the conditions across the rows and the resulting actions below them, with one column per rule, so logic that depends on a combination of inputs gets covered systematically. With n independent yes or no conditions there are 2 to the power n combinations, and you strike out the ones that cannot happen in reality. It is the right technique when the outcome depends on several inputs together rather than on one input at a time, for example a discount driven by membership, cart value and a coupon. It doubles as a conversation with the business, because gaps in the rules show up as columns nobody can answer.

Say what triggers the technique: the outcome depends on a combination of inputs, not a single one. The trap is describing the grid without saying when you would reach for it. The senior signal is the business value, because an unanswerable column is a requirement gap you found before a line of code was written.

How to phrase it

I reach for a decision table the moment the outcome depends on a combination of inputs rather than on one input at a time. Boundary values and partitions are perfect for a single field like age, but they cannot express a rule like the discount depends on whether you are a member, whether the cart is over two thousand rupees, and whether a coupon was applied. For that I build a table: the conditions go down the left, then one column per rule, with yes or no in each cell, and the actions underneath. With three yes-or-no conditions there are eight combinations, so eight columns, and I go through all of them. Some of them will be impossible in reality and I strike those out and say why. Now, the reason I like this technique beyond coverage is that it is a brilliant conversation with the business. When I take the table to the business analyst and ask what happens in column six, and nobody can answer, I have just found a requirement gap before a single line of code was written. That is a defect prevented, not detected, and it costs almost nothing at that point.

Key points to hit

• Use it when the outcome depends on a combination of inputs, not a single input.
• Conditions down the left, one column per rule, actions underneath.
• n yes-or-no conditions give 2 to the power n combinations.
• Strike out combinations that cannot happen, and record why.
• Typical fit: pricing, discounts, eligibility, approval and access rules.
• A column nobody can answer is a requirement gap found before coding.

DISCOUNT RULES, three conditions, 2^3 = 8 rules

Conditions            R1   R2   R3   R4   R5   R6   R7   R8
  Member?             Y    Y    Y    Y    N    N    N    N
  Cart over 2000?     Y    Y    N    N    Y    Y    N    N
  Coupon applied?     Y    N    Y    N    Y    N    Y    N

Actions
  Discount 25%        X
  Discount 15%             X
  Discount 10%                  X         X
  Discount 5%                                  X    X
  No discount                        X                   X

One test case per column. If nobody can tell you the action for a
column, that is a requirement gap, not a test you skip.

A defect normally moves New, then Assigned, then Open while the developer works on it, then Fixed, then back to the tester for Retest, then Verified and Closed. If the fix does not work it becomes Reopened and goes round again. The side branches matter just as much: Rejected when it is not a defect, Duplicate when it is already logged, and Deferred when everyone agrees it is real but it will be handled in a later release. The exact status names come from whatever workflow the team has configured in Jira or a similar tool, so describe the flow and then say how your project named it.

Walk the happy path first, then the loop, then the side branches, in that order, so it sounds like a flow rather than a list of words. The trap is reciting statuses without saying who moves the defect at each step. The senior signal is adding that status names are tool configuration, so you name yours instead of assuming one standard.

How to phrase it

I would walk it as a flow. I find the defect and log it, so it is New. It goes to triage and gets assigned to a developer, so it is Assigned. The developer starts on it and it is Open or In Progress. When the code change is done they mark it Fixed and it comes back to me. I take the new build and retest, so it is in Retest. If the fix works I mark it Verified and then Closed. That is the happy path. The loop is when the fix does not work: I move it to Reopened and it goes back to the developer, and we go round again. Then the side branches, which come up just as often. Rejected, when the developer or the business decides the behaviour is as designed. Duplicate, when the same thing is already logged. And Deferred, when everyone agrees it is a genuine defect but it is not worth fixing in this release, so it is scheduled later. The exact names depend on how the Jira workflow is configured, so I describe the flow and then say what my project called each state.

Key points to hit

• Happy path: New, Assigned, Open, Fixed, Retest, Verified, Closed.
• Loop: if the fix fails, Reopened and back to the developer.
• Rejected: agreed to be working as designed, not a defect.
• Duplicate: the same defect is already logged.
• Deferred: a real defect, agreed for a later release.
• Status names are Jira workflow configuration, so say what yours were called.

DEFECT LIFE CYCLE

   New
    |
    v
  Assigned  ->  Rejected  (working as designed)
    |         ->  Duplicate (already logged)
    |         ->  Deferred  (real, but a later release)
    v
   Open   (developer working on it)
    |
    v
   Fixed
    |
    v
  Retest  (tester, on the new build)
    |
    |  fix did not work  ->  Reopened  ->  back to Open
    v
 Verified  ->  Closed

The quality of the report decides how fast a defect is fixed, because a developer who cannot reproduce it will move on to the next ticket. A strong report has a title that names what broke and where, the environment and build number, steps that start from a known state and can be followed by anybody, expected versus actual result, evidence such as a screenshot, a short recording, logs or a request id, a severity with the reason behind it, and how often it reproduces. The tone stays about the behaviour, never about the person who wrote the code.

Frame it as making reproduction effortless, because that is the single thing that decides whether a defect is fixed or bounced. The trap is listing fields without saying why each one saves time. The senior signal is mentioning reproducibility rate and evidence like logs or a request id, plus a neutral tone that keeps the relationship with the developers strong.

How to phrase it

I write the report for one reader, the developer, and my whole goal is that they can reproduce it without talking to me. So the title says what broke and where, something like checkout fails with a valid coupon on the payment page, not just coupon issue. Then the environment and the exact build number, because a defect that only exists in one environment is a big clue in itself. Then the steps, and I always start from a known state, logged out or a fresh cart, so nobody has to guess what I had on screen before. Expected result and actual result go side by side, and the expected result is tied back to the requirement so it is not just my opinion. Then evidence: a screenshot, a short screen recording for anything about timing, and if I can get them the logs or a request id, because that saves a developer half a day. I add how often it reproduces, three times out of five is very different from every time. And I keep the tone about the behaviour, never about the person, because I want the developers to want to read my tickets.

Key points to hit

• Title names what broke and where, not a vague label.
• Always include environment plus the exact build number.
• Steps start from a known state so anybody can follow them.
• Expected result tied to the requirement, actual result beside it.
• Evidence: screenshot, recording for timing issues, logs or a request id.
• Add the reproducibility rate, and keep the tone about behaviour, not people.

BUG REPORT TEMPLATE

Title        Checkout fails with a valid coupon on the payment page
ID           DEF-1842
Module       Checkout > Payment
Environment  QA2, build 4.7.1, Chrome 141, Windows 11
Severity     High (blocks a paid order)
Priority     High (coupon campaign is live from Monday)
Reproduces   5 of 5 attempts

Preconditions
  Logged in as a registered user with an empty cart.
  Coupon SAVE20 is active and not yet used by this account.

Steps
  1. Add any item over 2000 to the cart
  2. Open the cart and apply coupon SAVE20
  3. Confirm the discount line appears
  4. Click Proceed to pay
  5. Choose UPI and submit

Expected   Payment page loads with the discounted total (SRS 4.3.2)
Actual     Page shows Something went wrong. Order is not created.

Evidence   screenshot_def1842.png, screen recording, request id 7f2a91c4
Notes      Works correctly without a coupon. Only fails when a coupon
           is applied before payment.

Risk based testing means you rank what to test by risk, where risk is the likelihood of something failing multiplied by the impact if it does. You score each feature with the business and the developers, then spend the deepest testing on the high risk items and a lighter pass on the low risk ones. It is how you answer we do not have time to test everything with a defensible plan rather than a guess. It also gives you the language for sign off, because you can state clearly what was covered deeply, what was covered lightly, and what was consciously left out.

Define risk as likelihood times impact, then show the mechanics: who scores, what changes in the plan, and how it changes your sign off language. The trap is making it sound like intuition. The senior signal is that risk based testing turns an invisible cut into a shared, recorded decision.

How to phrase it

Risk based testing is how I decide where to spend my testing effort when there is never enough time for everything. Risk here is likelihood times impact: how likely is this area to fail, and how bad is it if it does. Likelihood comes from how much code changed, how complex the area is, and how many defects it has had before. Impact comes from the business: how many users touch it, does money move through it, is there a legal or compliance angle. I do not score this alone. I sit with the business analyst and a developer and we rate each area together, high, medium or low. Then the plan follows the scores. High risk areas get deep coverage, boundary values, negative cases, exploratory sessions on top. Low risk areas get a confidence pass. The part I really value is what it does to sign off. Instead of saying testing is done, I can say payments and login were covered in depth, reporting had a confidence pass, and this admin screen was not covered because we rated it low risk. That turns a silent cut into a decision the whole team made together and can see.

Key points to hit

• Risk equals likelihood of failure times impact if it fails.
• Likelihood: code churn, complexity, history of defects, team familiarity.
• Impact: number of users, money, legal or compliance exposure.
• Score with the business analyst and a developer, not alone.
• High risk gets depth, low risk gets a confidence pass.
• Sign off becomes specific: covered deeply, covered lightly, consciously not covered.

Exploratory testing is structured and deliberate: you design, run and learn at the same time, inside a time box, guided by a charter that states the mission. Ad hoc testing is unstructured poking around with no charter, no time box and usually no record. A charter is one sentence, for example explore checkout with expired cards to discover error handling problems. Session based test management adds the time box, usually 45 to 90 minutes, plus notes and a debrief, which is what makes exploratory work reportable. Exploratory testing finds what scripted cases miss, because a script can only ask the questions somebody thought of in advance.

Separate exploratory from ad hoc on structure, because interviewers often hear them used as synonyms. The trap is making exploratory sound like a licence to click around. The senior signal is the charter plus the session format, which makes exploratory work planned, time boxed and reportable like any other testing.

How to phrase it

People often use these as synonyms, and the difference is structure. Ad hoc testing is unstructured. I have some time, I poke at the application, and nothing is written down. It occasionally finds something, but I cannot repeat it or report it. Exploratory testing is deliberate. I am designing the test, running it and learning from the result at the same time, but inside a structure. That structure is a charter and a time box. The charter is one sentence that states the mission, for example explore the checkout with expired and declined cards to discover error handling problems. The time box is usually 45 to 90 minutes, and that is session based test management. During the session I keep notes of what I tried, what I noticed, and any questions that came up, and afterwards there is a short debrief. That is what makes exploratory testing reportable, I can say I ran three sessions, here are the charters and here is what came out. The reason I fight for exploratory time is simple. A scripted test case can only ever ask a question somebody already thought of. Exploratory is where the surprises get found.

Key points to hit

• Exploratory: design, run and learn together, inside a structure.
• Ad hoc: unstructured, no charter, no time box, nothing recorded.
• A charter is one sentence naming the mission of the session.
• Session based testing: a 45 to 90 minute time box, notes and a debrief.
• Notes plus debrief make exploratory work reportable, not just clicking around.
• Scripts only ask questions someone thought of. Exploratory finds the surprises.

Entry criteria are the conditions that must be true before a test phase can start: the build is deployed, smoke passes, test data is ready, test cases are reviewed and signed off, the environment is stable. Exit criteria are the conditions for declaring that phase done: the planned cases are executed, the pass rate meets the agreed threshold, no open critical or high defects, remaining defects are triaged and accepted, and coverage against requirements can be shown. They exist so that starting and stopping are agreed in advance rather than argued about under deadline pressure. A useful exit criterion is measurable, and since all tests passed is rarely realistic, teams agree thresholds plus a written acceptance of what is left open.

Say why they exist before you list them: the point is to agree start and stop while everyone is calm. The trap is reciting generic bullets. The senior signal is the reality check that all tests passed is rarely achievable, so you agree thresholds plus a documented acceptance of the open defects.

How to phrase it

Entry criteria are what has to be true before a test phase can start, and exit criteria are what has to be true before I can call it done. Entry usually means the build is deployed to the right environment, smoke passes, the test data is created, the test cases are reviewed, and the environment is stable enough to trust the results. If I start anyway, I end up raising defects that are really environment problems, and that burns my credibility. Exit usually means the planned cases are executed, the pass rate is at or above what we agreed, there are no open critical or high severity defects, the remaining defects are triaged and accepted by the business, and I can show coverage against the requirements. But the real reason both exist is timing. We agree them at the start, when everybody is calm, so that on the last Friday before release we are checking a list instead of having an argument. I would also be realistic: all tests passed almost never happens, so the grown up version is an agreed threshold plus a written acceptance of exactly which defects we are going live with.

Key points to hit

• Entry: build deployed, smoke passing, data ready, cases reviewed, environment stable.
• Exit: cases executed, agreed pass rate, no open critical or high defects.
• Exit also needs remaining defects triaged and accepted, and coverage shown.
• Starting without entry criteria produces environment defects and lost credibility.
• Agree both early so release day is a checklist, not an argument.
• All tests passed is rarely realistic. Agree a threshold plus a written acceptance.

A requirement traceability matrix maps every requirement to the test cases that cover it, and usually on to the defects raised against it. Forward traceability runs requirement to test case and proves nothing is untested. Backward traceability runs test case to requirement and catches tests that exist for no stated reason, which is normally scope creep. Doing both is bidirectional traceability. Its real value shows up when a requirement changes late, because you can see within seconds which test cases and which defects are affected, and it gives you a coverage number you can defend in a status meeting.

Explain the two directions, because that is the follow-up question, then get to the value fast. The trap is describing it as a document you fill in for audit. The senior signal is impact analysis: when a requirement changes late, the matrix tells you what to retest in seconds instead of guessing.

How to phrase it

A traceability matrix is a simple map from each requirement to the test cases that cover it, and usually on to the defects raised against that requirement. There are two directions and interviewers normally ask about them. Forward traceability goes from requirement to test case, and it answers is every requirement actually tested. Any requirement with no test case against it is a coverage gap sitting in plain sight. Backward traceability goes the other way, from test case to requirement, and it catches test cases that do not trace to anything, which normally means somebody has tested something nobody asked for. Doing both is bidirectional. Where it earns its keep is impact analysis. When a requirement changes in week six, which it always does, I do not have to guess what is affected. I look up that requirement and I immediately have the list of test cases to update and rerun, and the defects already raised in that area. And it gives me a number I can defend in a status meeting, I can say we have coverage on forty-eight of fifty requirements and here are the two that are open, instead of saying testing is going well.

Key points to hit

• Maps requirements to test cases, and usually on to defects.
• Forward: requirement to test case, proves nothing is untested.
• Backward: test case to requirement, catches tests nobody asked for.
• Both directions together is bidirectional traceability.
• Best value: instant impact analysis when a requirement changes late.
• Gives a defensible coverage number for status reporting.

REQUIREMENT TRACEABILITY MATRIX (extract)

Req ID   Requirement                    Test cases          Status   Defects
-------  -----------------------------  ------------------  -------  --------
REQ-01   User logs in with valid creds  TC-01, TC-02        Pass     -
REQ-02   Account locks after 3 fails    TC-04, TC-05        Pass     DEF-1120
REQ-03   Coupon applies at checkout     TC-11, TC-12, TC-13 Fail     DEF-1842
REQ-04   Order confirmation email       TC-20               Blocked  -
REQ-05   Invoice download as PDF        (none)              GAP      -

REQ-05 with no test case is a coverage gap.
A test case with no Req ID is usually scope creep.

The regular ceremonies are sprint planning, the daily stand up, the sprint review and the retrospective, with backlog refinement running alongside them. The tester is an active participant in every one: in refinement you question the story and the acceptance criteria before it is estimated, in planning you size the testing work and flag dependencies like test data and environments, in the stand up you raise blockers the same day, in the review you demo against acceptance criteria, and in the retrospective you bring the quality patterns you noticed. Many teams also run a three amigos conversation per story, business, developer and tester together, which is where the cheapest defects are prevented.

Go ceremony by ceremony and say what you contribute in each, because that is a far stronger answer than naming the four events. The trap is describing the tester as someone who waits for a build. The senior signal is refinement and three amigos, since that is where testers prevent defects rather than find them.

How to phrase it

I would go through them and say what I actually contribute, because just naming the events does not show much. In backlog refinement I read the story before it is estimated and ask the awkward questions. What happens if the payment times out, is this available to a guest user. Correcting an acceptance criterion there costs nothing. In sprint planning I size the testing effort honestly, and I flag dependencies early, usually test data and environment availability, because those are what actually delay a sprint. In the daily stand up I raise blockers the same day rather than sitting on them, and I say what I am testing so the developer can tell me if something has changed. In the sprint review I demo against the acceptance criteria, which keeps the conversation factual. In the retrospective I bring quality patterns, for example that three defects this sprint all came from unclear requirements, so we can fix the cause. And where the team runs a three amigos session per story, business, developer and me together for fifteen minutes, that is honestly where the best value is, because we prevent defects instead of finding them later.

Key points to hit

• Refinement: question the story and the acceptance criteria before estimation.
• Planning: size the testing work, flag test data and environment dependencies.
• Stand up: raise blockers the same day, say what you are testing.
• Review: demo against acceptance criteria so the discussion stays factual.
• Retrospective: bring patterns in the defects, not just a list of them.
• Three amigos per story prevents defects at the cheapest possible point.

Automate what is repetitive, stable, run often and expensive to do by hand: regression suites, smoke checks on every build, data heavy scenarios with many combinations, and checks at the API level where they are faster and steadier than through the screen. Keep manual what needs human judgement or changes constantly: exploratory work, usability and visual judgement, one off checks, features still in flux, and anything you will run twice and then never again. The honest measure is return on investment, the cost to build and maintain the script weighed against the time and risk it removes. A script that has to be rewritten every sprint costs more than it saves.

Answer with criteria, not a list of tools, and put maintenance cost at the centre. The trap is saying you would automate everything. The senior signal is naming what you would deliberately leave manual and why, plus preferring API level checks where they give the same confidence faster.

How to phrase it

I would answer this with criteria rather than a list, because the right answer changes per project. The first question is how often it will run. A regression pack every release, or smoke on every build, pays back quickly, so those go first. The second is how stable is it. If a screen is still being redesigned every sprint, automating it now means rewriting the script every sprint, and that costs more than running the test by hand. The third is how expensive it is manually. Anything data heavy, like the same flow across thirty combinations, is a strong candidate because a human doing it is slow and starts making mistakes. And where the same confidence can be got from an API level check instead of driving the screen, I prefer that, because it is faster and far steadier. What I leave manual deliberately is exploratory testing, usability and visual judgement, one off verifications, and features still changing shape. The underlying measure is return on investment: build cost plus maintenance cost against the time and risk it removes. A suite nobody trusts because it is always red is worse than no suite at all.

Key points to hit

• Automate what runs often: regression packs and smoke on every build.
• Automate what is stable. A screen still being redesigned is not ready.
• Automate data heavy runs, many combinations of the same flow.
• Prefer an API level check when it gives the same confidence faster.
• Keep manual: exploratory, usability and visual judgement, one off checks.
• The measure is ROI including maintenance. A flaky suite is worse than none.

You can test an API by hand with a client like Postman and the documentation, usually Swagger or an OpenAPI file. Start with the contract: the status code, the response schema, field types, and which fields are mandatory. Then the behaviour: valid requests, missing and invalid parameters, boundary values, wrong data types, and authorisation, which means no token, an expired token, and a token belonging to a different user. Then the side effects, because a 200 response does not prove the data was saved, so a SQL query against the table confirms it. Response time and the quality of the error messages are part of the test too.

Structure the answer in three layers, contract, behaviour and side effects, because that sounds like a method rather than a list of clicks. The trap is stopping at checking the status code. The senior signal is verifying the database after the call, and testing authorisation with another user's token, which is where real defects hide.

How to phrase it

I would use Postman and the API documentation, usually a Swagger or OpenAPI page, and I would test in three layers. First the contract. Does the endpoint return the status code the documentation promises, 200 for success, 201 for created, 400 for a bad request, 401 when I am not authenticated, 404 when the resource does not exist. Then I check the response body against the schema: are all the expected fields there, are the data types right, are the mandatory fields never null. Second, behaviour. I send a valid request, then break it deliberately: remove a mandatory field, send a string where a number belongs, send boundary values, send an empty body. I am checking that the error is clean and useful rather than a stack trace. Authorisation matters a lot here, so I call it with no token, an expired token, and, importantly, a valid token belonging to a different user, because that is where you find someone reading another customer's data. Third, side effects. A 200 does not prove the record was written, so I run a SQL query on the table and confirm the row is there with the right values.

Key points to hit

• Use Postman plus the Swagger or OpenAPI documentation as the contract.
• Layer one: status codes, response schema, field types, mandatory fields.
• Layer two: valid, missing, invalid, boundary and wrong-type inputs.
• Authorisation: no token, expired token, another user's valid token.
• Layer three: confirm the side effect with a SQL query, not just a 200.
• Judge the error messages and note response times as you go.

MANUAL API CHECKLIST: POST /api/v1/orders

Check                         Request                        Expect
----------------------------  -----------------------------  ------------------
Happy path                    valid body, valid token        201 + order id
Missing mandatory field       body without customerId        400 + clear message
Wrong data type               quantity as text               400 + field named
Boundary                      quantity 0, 1, 999, 1000       per the spec
No authentication             no Authorization header        401
Expired token                 old token                      401
Another user's token          user B token, user A order     403, never 200
Unknown resource              GET /orders/99999999           404
Response time                 happy path                     within the agreed SLA

Side effect check, run after the happy path:

  SELECT order_id, customer_id, status, total_amount
  FROM orders
  WHERE order_id = 10482;

A 200 or 201 only says the API replied. The row proves it saved.

This is a prioritisation and communication question, not a testing trivia question. The approach is to re-rank the scope by risk, confirm with the business what is genuinely unmissable, cover the money paths and the highest risk changes fully, shorten or drop the low risk and rarely used areas, lean on existing automation for regression breadth, and then write down clearly what will not be covered so the decision is visible and shared. The one thing you never do is quietly cut and hope, because that turns a business decision into a hidden risk that lands on you.

Do not answer with heroics like working the weekend. Answer with a method: re-rank by risk, agree the cut with the business, and record it. The senior signal is making the reduced scope visible and shared, and offering something back, such as a post release check or a staged rollout.

How to phrase it

I would not answer with working the weekend, because that is not a plan. I re-rank the scope by risk. I already know which areas are high risk, so I go to the product owner with a short list and confirm two things: what absolutely cannot go out broken, and what the business is comfortable accepting a lighter check on. Typically the money paths, login, checkout, payment and anything with a legal or compliance angle, get full depth regardless. The biggest code changes in this release get full depth too. The areas that barely changed and are rarely used get a confidence pass rather than the full set. I lean on whatever regression automation exists to keep breadth cheap, and I put my manual hours into the risky new work and a couple of exploratory sessions around it. Then, and this is the part that matters most, I write down exactly what will not be covered and I share it, so it is a decision the team made rather than a gap I hid. And I offer something back: a focused check in production right after release, or a staged rollout.

Key points to hit

• Never answer with heroics. Answer with a method.
• Re-rank the scope by risk and take a short list to the product owner.
• Money and compliance paths keep full depth, always.
• Biggest code changes keep full depth, low change and low use get a light pass.
• Use existing automation for breadth, spend manual hours on the risky new work.
• Write down what is not covered, and offer a post release check or staged rollout.

Contain first, learn second. Reproduce and confirm what is actually happening, assess how many users and how much money are affected, communicate quickly to the people who need to know, and support the fix or the rollback. Only once it is contained do you run the root cause analysis, and that analysis asks two separate questions: why did the defect get created, and why did testing not catch it. The output is concrete: a new regression test, an updated test case or checklist, and if needed a change to the process such as a review step or a missing data set. Keep it blameless, because a team that hides escapes learns nothing.

Sequence it: contain, then communicate, then analyse. The trap is jumping to whose fault it was. The senior signal is splitting the root cause into why it was created and why it was not caught, and finishing with a concrete change so the same escape cannot repeat quietly.

How to phrase it

My first instinct is to contain it, not to find out whose fault it is. Step one, reproduce and confirm exactly what is happening, because a production report is often a symptom rather than the real issue. Step two, assess the blast radius: how many users, is money involved, is data being written incorrectly. That decides the urgency. Step three, communicate straight away to the product owner and support, so nobody hears it from a customer first. Then I support the fix or rollback and retest it properly in production. Only once it is contained do I look at cause, and I split that into two questions. Why was the defect created, which might be an unclear requirement or a late change. And why did testing not catch it, which might be that the scenario was not in my test cases, or the test data did not look like real data, or the environment did not match production. The output has to be concrete: a regression test added, the test case or checklist updated, and if needed a process change. And I keep it blameless, because once people feel blamed for escapes they stop reporting them.

Key points to hit

• Contain first: reproduce, confirm, assess how many users and how much money.
• Communicate early so support and the product owner are never surprised.
• Support the fix or rollback, then verify it properly in production.
• Root cause splits in two: why created, and why not caught.
• Common not-caught causes: missing scenario, unrealistic data, environment gap.
• Output something concrete: a regression test, an updated case, a process change.

The genuinely useful uses today are all drafting and thinking aids: turning a user story into a first set of test scenarios that you then edit, generating combinations of test data, summarising a long requirement document, tidying a rough bug report into a clean one, suggesting exploratory ideas you had not considered, and converting manual steps into automation ready pseudo steps. Tools like ChatGPT and Gemini are the common ones, alongside whatever is built into the test management tool. The limits matter just as much: the output can be confidently wrong, it does not know your product's business rules, and you remain accountable for whatever you sign off. And confidential data, customer records and credentials never go into a public tool.

Give specific, believable uses with an example each, because vague enthusiasm reads as someone who has not used it. The trap is claiming AI replaces test design. The senior signal is pairing every use with its guardrail: you review everything, and no confidential or customer data goes into a public tool.

How to phrase it

I use it as a drafting partner, not as a replacement for thinking. The most useful thing is speed on the first draft. I paste a user story into ChatGPT or Gemini and ask for test scenarios, and in a minute I have twenty, of which maybe twelve are useful. It usually gives me two or three negative scenarios I would have reached eventually, so it is a good second pair of eyes. I use it to generate test data combinations, to summarise a long requirement document down to the parts that affect my feature, and to tidy up a bug report I wrote quickly so the developer gets something clean. The guardrails matter just as much, and I would say them without being asked. I review every line, because it can be confidently wrong and it does not know our business rules, our pricing logic or our compliance requirements. I never paste customer data, credentials or anything confidential into a public tool. And whatever I sign off is mine, not the tool's. Used that way it has genuinely made me faster, especially at the boring parts.

Key points to hit

• Draft test scenarios from a user story, then edit. Speed on the first draft.
• Generate test data combinations instead of building them by hand.
• Summarise long requirement documents down to what affects your feature.
• Tidy a rough bug report so the developer gets something clean.
• Guardrail one: review every line. It can be confidently wrong on business rules.
• Guardrail two: never paste customer data, credentials or confidential documents.

Defect density is defects divided by the size of what was tested, per module, per thousand lines of code, or per story point, and it tells you which parts of the product are risky. Defect leakage is about escapes: defects found after release compared with defects found during testing, so it measures how well the testing net held. The related one is defect removal efficiency, defects found before release divided by the total found before and after, as a percentage. Exact formulas vary between companies, so state the one you use and say what decision it drives. A metric nobody acts on is just reporting.

Pick a small number of metrics and tie each to a decision, because that is what separates a lead from someone who fills in a dashboard. The trap is reeling off ten metrics. The senior signal is naming the behaviour a metric can distort, such as defect count encouraging people to log noise, and saying formulas vary so you state yours.

How to phrase it

I keep it to a few metrics and explain what decision each drives, because a metric nobody acts on is just reporting. Defect density is defects divided by the size of what was tested, per module or per story point. It tells me where the risk is concentrated. If one module has three times the density of everything else, that is where my next regression effort and my exploratory sessions go. Defect leakage is about escapes, it compares defects found after release with defects found during testing, so it tells me how well my testing net held. Defect removal efficiency is the same idea as a percentage: defects found before release over the total found before and after. If that number is trending down, something in my coverage or my environments has slipped and I need to find out what. I would add two caveats. First, the exact formulas differ between companies, so I state the one we use rather than assuming a standard. Second, metrics change behaviour, so I never use raw defect count as a performance measure, because people start logging noise to look productive. I use them to steer testing, not to score people.

Key points to hit

• Defect density: defects per module, per KLOC or per story point. Shows where risk sits.
• Defect leakage: defects found after release against those found in testing.
• Defect removal efficiency: found before release over total found, as a percentage.
• Each metric must drive a decision, otherwise it is only reporting.
• High density in one module means that is where the next deep pass goes.
• Never score people on raw defect count. It just produces noisy defects.

THE THREE METRICS, WORKED

Defect density
  defects found in a module / size of that module
  Checkout: 34 defects / 8 story points   = 4.25 per point  <- deepest risk
  Reports : 6 defects  / 9 story points   = 0.67 per point

Defect removal efficiency (DRE)
  found during testing / (found during testing + found after release) x 100
  180 / (180 + 20) x 100 = 90%

Defect leakage
  found after release / found during testing x 100
  20 / 180 x 100 = 11.1%

Formulas vary between companies. State the one your team uses,
and say what you changed because of the number.