Manual Testing, SDLC, STLC & Core QA Concepts (In-Depth, ISTQB-Aligned)¶

Foundational knowledge — asked in ~90% of QA/SDET interviews. This guide explains every concept in simple words with examples, grounded in the ISTQB Foundation Level (CTFL) syllabus. Each part ends with likely interview Q&A.

How to use it: read a part, then cover the answers and say them out loud. The bold words are what the interviewer listens for.

Going deeper? For advanced white-box coverage (statement/branch/MC-DC/path, cyclomatic complexity), combinatorial/pairwise, mutation testing, data-flow, and OO testing, see the companion file 20_Software_Testing_Concepts_NPTEL.md.

Contents 1. Fundamentals of Testing (what, why, the 7 principles) 2. Error vs Defect vs Failure + Testing vs Debugging 3. The Fundamental Test Process (ISTQB) + STLC 4. SDLC & SDLC Models 5. Test Levels (unit → acceptance) 6. Test Types (functional, non-functional, white-box, change-related) 7. Static Testing & Reviews 8. Test Design Techniques (black-box, white-box, experience-based) — with worked examples 9. Bug / Defect Lifecycle, Severity vs Priority 10. Agile Testing 11. Test Management: risk, estimation, metrics 12. Test Documentation 13. Roles: QA vs QC, Verification vs Validation, SDET 14. Big Q&A bank (simple words)

PART 1: FUNDAMENTALS OF TESTING¶

What is testing? (ISTQB definition, in plain words)¶

Testing is the process of checking whether software does what it's supposed to do — and finding the places where it doesn't. It's more than "running the app": it also includes planning, designing test cases, reviewing documents, and reporting results.

In plain words: testing is evidence gathering. You're building a case for "this software is good enough to ship," and hunting for proof that it isn't.

Why is testing necessary?¶

Catch defects early — a bug found in design costs far less than one found in production (the "cost of defect" rises the later you find it).
Reduce risk — of failures, money loss, safety issues, and reputation damage.
Build confidence — give the business evidence about quality so they can decide to release.
Meet requirements / contracts / laws — e.g., banking, healthcare compliance.

Remember: testing doesn't create quality (developers do that); testing measures and protects it.

Test objectives (what a test run is trying to achieve)¶

Find defects.
Verify requirements are met (validation).
Give information to stakeholders to make decisions.
Prevent defects (by reviewing early — "shift-left").
Build confidence in the quality level.

The 7 Principles of Testing (ISTQB — memorize these, they're asked directly)¶

Testing shows the presence of defects, not their absence. Finding no bugs doesn't prove there are none. In plain words: passing tests ≠ perfect software.
Exhaustive testing is impossible. You can't test every input/combination. So you prioritize using risk and techniques.
Early testing saves time and money. Start testing (even reviewing documents) as early as possible — "shift-left."
Defects cluster together. A small number of modules usually contain most of the bugs. (The Pareto 80/20 idea.) So focus effort where bugs already appear.
Beware the pesticide paradox. Running the same tests over and over stops finding new bugs (like pests growing immune to a pesticide). Fix: regularly review and add/update test cases.
Testing is context-dependent. You test a banking app differently from a gaming app. Context drives how much and what you test.
Absence-of-errors is a fallacy. Software with zero bugs can still be a failure if it's the wrong product nobody wants or it's unusable.

Memory hook (initials): "Defects present, Exhaustive impossible, Early, Cluster, Pesticide, Context, Absence-fallacy."

The Psychology of Testing¶

Testers and developers have different mindsets — devs build, testers look for problems. Both are needed.
Confirmation bias: people don't like hearing their work has bugs. So communicate defects tactfully — focus on the product, not the person; be factual (steps, evidence), not blaming.
Independence of testing: the more independent the tester (someone other than the author), the more likely they spot defects the author is "blind" to.

PART 2: ERROR vs DEFECT vs FAILURE + TESTING vs DEBUGGING¶

Error → Defect → Failure (ISTQB — a classic question)¶

This is a chain of cause and effect: - Error (mistake): a human mistake. Example: a developer misunderstands the requirement. - Defect (bug/fault): the mistake in the code/document that results. Example: the wrong formula is written. - Failure: what the user sees when that defect runs. Example: the app shows the wrong total on screen.

In plain words: a person makes an error → which puts a defect in the code → which, when run, causes a failure. (Note: not every defect causes a failure — it may sit in code that never runs.)

Root cause = the underlying reason for the error (e.g., unclear requirement, time pressure).

Testing vs Debugging (don't mix these up)¶

Testing = finding failures (the tester's job).
Debugging = finding and fixing the defect that caused the failure (the developer's job).

Remember: testing finds it; debugging fixes it.

PART 3: THE FUNDAMENTAL TEST PROCESS (ISTQB) + STLC¶

ISTQB describes a set of test activities (not always strictly sequential). Learn these — they map onto the "STLC" that Indian interviews love.

ISTQB Test Activities¶

Test Planning — decide the objectives, scope, approach, and how to measure "done."
Test Monitoring & Control — track progress vs the plan; take action if off-track.
Test Analysis — "what to test": study the requirements/basis, identify testable features and test conditions.
Test Design — "how to test": turn conditions into test cases and figure out test data.
Test Implementation — get everything ready: test procedures/suites, environment, test data.
Test Execution — run the tests, compare actual vs expected, log defects.
Test Completion — write reports, gather metrics, archive testware, capture lessons learned.

Testware = everything testing produces: test plans, cases, data, scripts, reports.

STLC (Software Testing Life Cycle) — the practical 6-phase version¶

Interviewers often expect this exact sequence:

Requirement Analysis — understand what to test; identify testable requirements; raise questions on unclear/missing/ambiguous requirements. Output: a list of testable scenarios, an RTM.
Test Planning — create the test plan: scope, approach, effort estimation, resources, schedule, tools, risks. Output: test plan + effort estimate.
Test Case Design — write test cases and prepare test data; review them. Output: test cases, test data.
Test Environment Setup — prepare hardware/software/test environment; run a smoke test to confirm it's ready.
Test Execution — execute cases, mark pass/fail, log defects, retest fixes, run regression. Output: execution results, defect reports.
Test Closure — evaluate exit criteria, write the Test Summary Report, collect metrics, and record lessons learned.

Entry & Exit Criteria (a common question)¶

Entry criteria = conditions that must be TRUE before you start a phase. Example (execution): build deployed, environment ready, test data prepared, test cases reviewed.
Exit criteria = conditions that must be TRUE to finish/stop. Example: all planned tests executed, no open critical/high defects, coverage target met, test summary signed off.

Remember: Entry = "are we allowed to start?" Exit = "are we allowed to stop?"

PART 4: SDLC & SDLC MODELS¶

SDLC (Software Development Life Cycle) — 6 phases ("PARDIM")¶

Phase	What happens
Planning	Define scope, feasibility, cost
Analysis	Gather requirements (BRD, FRD)
Requirement/Design	Architecture, DB design, UI mockups
Development	Code is written
Implementation (Testing)	QA tests the build
Maintenance	Bug fixes, updates after release

(BRD = Business Requirements Document; FRD = Functional Requirements Document.)

SDLC Models — what each is, and when to use it¶

Model	How it works	Best when	Testing angle
Waterfall	Strict linear phases, one after another	Requirements fixed, won't change (e.g., govt)	Testing happens late — risky if requirements were wrong
V-Model	Every dev phase has a matching test phase planned in parallel	Regulated domains (banking, healthcare)	Shift-left built in: you plan acceptance tests during requirements, unit tests during design
Iterative	Build in repeated cycles, improving each time	Requirements evolve	Test each iteration
Incremental	Deliver in pieces (increments), each adding features	Large apps delivered in parts	Test each increment + integration
Agile	Small frequent releases, fast feedback	Most modern apps	Continuous testing, testers embedded in the team
Spiral	Iterative + heavy risk analysis each loop	High-risk, large projects (defense)	Risk-based testing each loop
DevOps	CI/CD, automated build/test/deploy, daily releases	SaaS products	Automation + tests in the pipeline are mandatory

V-Model detail (often asked): left side goes down (Requirements → System Design → Architecture → Module Design → Coding); right side goes up (Unit → Integration → System → Acceptance testing). Each left level's test plan is written when that level is designed, then executed on the way up.

PART 5: TEST LEVELS (ISTQB) — "at what stage / scope do you test?"¶

Test levels are groups of activities based on the maturity/scope of what's being tested. There are four:

Level	What's tested	Who usually does it	Example
1. Component / Unit	A single function/class in isolation	Developers	Test that `calculateTax()` returns the right value
2. Integration	How modules/components talk to each other	Devs + testers	Login module correctly passes the token to the profile module
3. System	The whole application end-to-end	Testers	Full "register → login → buy → logout" flow
4. Acceptance (UAT)	Does it meet business needs / is it ready to accept?	End users / business / client	A real bank user confirms the statement download works

Integration testing — two approaches (asked): - Big Bang: integrate everything at once, then test. Fast to set up, but hard to locate faults. - Incremental: integrate a few modules at a time. - Top-down: start from top modules, use stubs (fake called-modules). - Bottom-up: start from bottom modules, use drivers (fake calling-modules). - Sandwich/Hybrid: both directions.

Stub vs Driver: a stub stands in for a module that's called; a driver stands in for a module that calls.

Types of acceptance testing: UAT (business users), Operational acceptance (backups, security, recovery), Contractual/Regulatory (meets contract/law), Alpha (in-house, before release), Beta (real users, outside).

Remember: Levels = scope ladder — Unit → Integration → System → Acceptance.

PART 6: TEST TYPES (ISTQB) — "what quality aspect are you checking?"¶

A test type focuses on a particular quality characteristic. Don't confuse type (what aspect) with level (what scope) — you can run any type at any level.

A) Functional testing¶

Checks what the system does — the features/behavior vs the requirements. Example: "clicking Pay charges the correct amount." Mostly black-box.

B) Non-functional testing¶

Checks how well the system works — the qualities. Based on ISO 25010 characteristics:

Non-functional type	Question it answers
Performance / Load / Stress / Spike	Is it fast and stable under many users?
Scalability	Can it grow with more load?
Security	Can attackers break in / steal data? (OWASP)
Usability	Is it easy and pleasant to use?
Compatibility	Works across browsers/OS/devices?
Reliability	Does it keep working over time without crashing?
Maintainability	Easy to change/fix?
Portability	Easy to move to another environment?
Accessibility	Usable by people with disabilities? (WCAG)

Load vs Stress: load = expected heavy usage; stress = push past the limit to see how/where it breaks.

C) White-box (structural) testing¶

Tests based on the internal code structure (not just behavior). Measures code coverage — e.g., statement coverage, branch coverage (see Part 8).

Confirmation testing (Re-testing): after a bug is fixed, run the same test that failed to confirm the fix works.
Regression testing: after any change, re-run other tests to make sure the change didn't break something that used to work.

Re-test vs Regression: re-test = "did the fix work?" (same case). Regression = "did the fix break anything else?" (broader set).

Common test-type terms you must define crisply¶

Type	One-line meaning
Smoke	Quick, shallow check that the new build is stable enough to test ("build verification").
Sanity	Narrow, deep check after a small change/fix that a specific area works.
Functional	Does the feature meet requirements?
Integration	Do modules work together?
System	End-to-end whole-app test.
UAT	End users confirm it meets business needs.
Exploratory	Simultaneously learn, design, and run tests without pre-written scripts.
Ad-hoc	Informal, random, no plan (least structured).
Regression	Re-run tests to catch breakage after change.
Retesting	Re-run the failed test after a fix.

Smoke vs Sanity (the trick question)¶

	Smoke	Sanity
When	After a new build	After a minor change / bug fix
Scope	Whole app, shallow	Specific area, deep
Documented?	Usually scripted	Usually not
Purpose	"Is the build stable enough to test?"	"Does this specific thing actually work now?"
Memory	"Smoke = does it boot?"	"Sanity = does the fix actually fix?"

PART 7: STATIC TESTING & REVIEWS (ISTQB — often missed by candidates)¶

Static testing = checking the software WITHOUT running it — you examine documents and code. Dynamic testing = running the software.

In plain words: static = read and review; dynamic = run and observe.

Why static testing is powerful: it finds defects early and cheaply — before code is even written or run. It also finds things dynamic testing can't (unclear requirements, dead code, bad standards).

Two kinds of static testing¶

Reviews — of documents (requirements, designs, test cases). Done by people.
Static analysis — automated tools scan code for issues (unused variables, security flaws, style) without running it. (e.g., SonarQube, linters.)

Review types (from least to most formal)¶

Review	Formality	What it is
Informal review	None	A colleague glances over your work; no process
Walkthrough	Low	Author leads others through the document to explain and gather feedback
Technical review	Medium	Experts/peers check technical correctness; often no manager
Inspection	High	Most formal; trained moderator, defined roles, metrics, checklists, formal process

Review roles: author (wrote it), moderator/facilitator (runs the review), scribe/recorder (notes defects), reviewers (find issues), manager (decides, allocates).

Remember: the earlier you review, the cheaper the fix. A requirement defect caught in a review costs a fraction of the same defect caught in production.

PART 8: TEST DESIGN TECHNIQUES (ISTQB) — with worked examples¶

ISTQB splits techniques into three families. Know at least EP, BVA, Decision Table, State Transition, and one white-box + experience-based.

A) Black-box techniques (based on requirements, not code)¶

1. Equivalence Partitioning (EP) Divide inputs into groups (partitions) that should behave the same, then test one value per group (testing more from the same group is wasteful). - Example: Age field accepts 1–100. - Invalid-low group: e.g., 0 (or -5) - Valid group: e.g., 50 - Invalid-high group: e.g., 101 - → 3 tests cover all three behaviors instead of testing every number.

2. Boundary Value Analysis (BVA) Most bugs hide at the edges of a range, so test the boundaries. For a range, test the boundary values (and just inside/outside). - Example: Range 1–10. - 2-value BVA: test at each boundary → 1, 10 (and often just-outside 0, 11). - 3-value BVA: 0, 1, 2 and 9, 10, 11. - Why: developers commonly mis-code < vs <=, so edges break most.

EP + BVA are usually used together: EP reduces how many tests, BVA targets the risky edges.

3. Decision Table Testing For features with combinations of conditions (rules), list every combination and its expected outcome. Great for business logic. - Example: Loan approval — conditions: Good credit? (Y/N) and Has collateral? (Y/N).

Rule	Good credit	Collateral	Decision
1	Y	Y	Approve
2	Y	N	Approve
3	N	Y	Manual review
4	N	N	Reject

Why: guarantees you don't miss a combination.

4. State Transition Testing For systems that move through states, test valid and invalid transitions. - Example: Order: New → Paid → Shipped → Delivered. Test valid moves, and that invalid ones are blocked (e.g., can't go New → Shipped without Paid). - Another: an ATM card that blocks after 3 wrong PINs — test the transition into "blocked."

5. Use Case Testing Design tests from user-goal flows (actor + main flow + alternate/exception flows). Good for end-to-end scenarios.

B) White-box techniques (based on code structure)¶

Statement coverage = % of code lines executed by your tests. 100% = every line ran at least once.
Branch / Decision coverage = % of decision outcomes (each if true AND false) executed. Stronger than statement coverage.
Why it matters: shows how much of the code your tests actually exercise. 100% statement coverage can still miss a false branch — that's why branch coverage is stronger.

Remember: branch coverage ≥ statement coverage in strength (100% branch implies 100% statement, not the reverse).

C) Experience-based techniques (rely on tester skill/intuition)¶

Error guessing: use experience to guess where bugs hide (empty fields, 0, negative numbers, huge inputs, special characters).
Exploratory testing: simultaneously learn, design, and execute — no pre-written scripts; often time-boxed as "sessions." Great when documentation is thin.
Checklist-based: test against a checklist of important things to verify.

PART 9: BUG / DEFECT LIFECYCLE¶

Typical flow: New → Assigned → Open (In Progress) → Fixed → Retest → Verified → Closed

Other states you should be able to explain: - Rejected — dev says it's not a valid bug. - Deferred — real bug, but will be fixed later (low priority / future release). - Duplicate — already reported. - Reopened — the "fix" didn't work; back to the dev. - Not a Bug / Works as Designed — behavior is actually correct per requirement.

In plain words: a bug is born (New), given to a dev (Assigned), worked on (Open), fixed (Fixed), you re-check (Retest); if good → Verified → Closed; if bad → Reopened.

Bug Report — must-have fields (a "write me a bug report" question)¶

Title — clear and specific ("Login fails with valid credentials on Chrome").
Steps to reproduce — numbered, exact.
Expected vs Actual result.
Severity (impact) and Priority (urgency).
Environment — OS, browser, build/version.
Evidence — screenshot, video, logs.
Reproducibility — always / intermittent.

Severity vs Priority (guaranteed question)¶

Severity = how BAD the bug is (technical impact). Set by the tester.
Priority = how SOON it must be fixed (business urgency). Set by PM/lead.

Severity	Priority	Example
High	High	Login broken on production — everyone blocked
High	Low	App crashes in a rarely used legacy module
Low	High	Company logo/name wrong on the homepage (embarrassing, easy fix, but very visible)
Low	Low	Typo in the footer

Memory trick: Severity = how much damage. Priority = how fast to fix. They're independent — a tiny bug (low severity) on the homepage logo can be high priority.

PART 10: AGILE TESTING¶

Agile Manifesto — 4 values¶

Individuals & interactions over processes & tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

(Note: the right side still has value — the left is just valued more.)

Scrum — "3-5-3"¶

3 Roles: Product Owner (decides what to build, owns backlog), Scrum Master (removes blockers, protects the process), Dev Team (builds and tests).
5 Events: Sprint Planning, Daily Standup, Sprint Review (demo), Sprint Retrospective (improve the process), Backlog Refinement.
3 Artifacts: Product Backlog, Sprint Backlog, Increment (the working product).

Sprint = a fixed time-box (1–4 weeks) that delivers a working increment. Story points = relative effort estimate, usually Fibonacci (1, 2, 3, 5, 8, 13).

Definition of Done (DoD) vs Acceptance Criteria (asked)¶

DoD = a general checklist every story must meet to be "done" (code reviewed, unit tests pass, QA tested, deployed to staging, docs updated).
Acceptance Criteria = story-specific conditions that define when that story works (often written as Given/When/Then).

Where QA fits in Agile¶

Testers join from the start (refinement/planning), help write acceptance criteria, test within the sprint, and automate regression. "Quality is the whole team's job."

Kanban vs Scrum¶

	Scrum	Kanban
Cadence	Fixed sprints	Continuous flow
Roles	Defined	Optional
WIP limits	Via sprint scope	Explicit column limits
Best for	New feature delivery	Maintenance/support

PART 11: TEST MANAGEMENT — RISK, ESTIMATION, METRICS¶

Risk-based testing (ISTQB core)¶

Since you can't test everything (principle #2), prioritize by risk. - Risk = likelihood of failure × impact if it fails. - Two kinds: - Product risk — risk in the software (a feature might fail). Testing reduces this. - Project risk — risk to the project (late delivery, no environment, staff leaving). - Approach: test the high-risk, high-impact, frequently-used areas first and most thoroughly.

Test estimation techniques (how you size testing effort)¶

Expert judgment / experience-based.
Work Breakdown Structure (WBS) — break into tasks, estimate each.
Three-point estimate — (Optimistic + 4×Most-likely + Pessimistic) / 6.
Planning poker (Agile, story points).

Key testing metrics¶

Metric	Formula / meaning
Defect Density	Defects / size (per KLOC or per module) — where bugs concentrate
Defect Leakage	Defects found in prod ÷ total defects — how many escaped testing
Defect Removal Efficiency (DRE)	Defects found before release ÷ total defects × 100 — how good testing was
Test Case Pass %	Passed ÷ executed × 100
Test Coverage	Requirements tested ÷ total requirements
Automation Coverage	Automated cases ÷ total cases

Leakage vs DRE: high leakage = bad (bugs escaped to users). High DRE = good (you caught most before release).

PART 12: TEST DOCUMENTATION¶

Document	Purpose (plain words)
Test Strategy	Org-wide, high-level "how we test here" (rarely changes)
Test Plan	Project-specific: scope, approach, schedule, resources, risks, entry/exit criteria
Test Scenario	High-level "what to test" (one line, e.g., "verify login")
Test Case	Detailed "how to test" (steps, data, expected result)
RTM (Requirement Traceability Matrix)	A table mapping each requirement → its test cases, so you can prove full coverage and spot gaps
Test Summary Report	Final results after execution: what passed/failed, defects, coverage, sign-off

Strategy vs Plan: Strategy = company-wide philosophy. Plan = this project's specifics. Scenario vs Case: Scenario = what (broad). Case = how (detailed steps).

PART 13: ROLES — QA vs QC, VERIFICATION vs VALIDATION, SDET¶

QA vs QC (subtle but asked)¶

QA (Quality Assurance) = process-focused, preventive. Improve the process so defects don't happen (standards, reviews, audits). "Are we doing the right things?"
QC (Quality Control) = product-focused, detective. Find defects in the product by testing. "Did we build it right?"

Remember: QA prevents, QC detects.

Verification vs Validation¶

	Verification	Validation
Question	"Are we building it right?" (meets specs)	"Are we building the right thing?" (meets user needs)
Method	Static — reviews, walkthroughs, inspections	Dynamic — actually running/testing
When	Before/during coding	After code is runnable

SDET vs Manual QA vs Automation Engineer¶

	Manual QA	Automation Engineer	SDET
Coding	Minimal	Writes test scripts	Writes tests + tools/frameworks
Framework design	No	Sometimes	Yes
CI/CD ownership	No	Partial	Yes
Mindset	Bug-finding	Script-writing	Engineer and tester

PART 14: BIG Q&A BANK (simple words)¶

Fundamentals 1. What is testing? → Checking that software meets requirements and finding where it doesn't; includes planning, designing, and reviewing, not just running it. 2. Why can't we test everything? → Exhaustive testing is impossible (too many input combinations); we prioritize by risk. 3. Difference between error, defect, and failure? → A human makes an error → it becomes a defect in the code → which causes a failure the user sees. 4. Testing vs debugging? → Testing finds the failure; debugging finds and fixes the defect. 5. Name the 7 testing principles. → Defects present not absent; exhaustive impossible; early testing; defect clustering; pesticide paradox; context-dependent; absence-of-errors fallacy. 6. What is shift-left testing? → Start testing earlier in the SDLC (review requirements/designs), not just at the end — cheaper to fix bugs early.

Process & levels 7. What's the difference between a test level and a test type? → Level = the scope/stage (unit, integration, system, acceptance). Type = the quality aspect (functional, performance, security). 8. Entry vs exit criteria? → Entry = conditions to start a phase; exit = conditions to stop/finish it. 9. Stub vs driver? → Stub replaces a called module (top-down); driver replaces a calling module (bottom-up). 10. What is UAT? → Acceptance testing by real business users to confirm it meets their needs before go-live.

Types (the tricky pairs) 11. Smoke vs sanity? → Smoke = broad, shallow "is the build stable?" after a new build. Sanity = narrow, deep "does this specific fix work?" after a change. 12. Retesting vs regression? → Retesting = re-run the failed case after a fix. Regression = re-run other cases to ensure nothing else broke. 13. Verification vs validation? → Verification = "building it right" (reviews, static). Validation = "building the right thing" (running tests, dynamic). 14. Load vs stress testing? → Load = expected heavy usage; stress = push beyond limits to find the breaking point. 15. Functional vs non-functional? → Functional = what it does (features). Non-functional = how well it does it (speed, security, usability).

Test design 16. Explain equivalence partitioning with an example. → Split inputs into groups that behave the same and test one per group; e.g., for age 1–100 test one invalid-low, one valid, one invalid-high. 17. Explain boundary value analysis. → Test the edges of a range (and just outside), because bugs cluster at boundaries; for 1–10 test 0,1,10,11. 18. When do you use a decision table? → When output depends on combinations of conditions (business rules), to cover every combination. 19. When do you use state transition testing? → For systems with states/workflows (order status, ATM card block after 3 wrong PINs). 20. Statement vs branch coverage? → Statement = % of lines run. Branch = % of decision outcomes (each if true & false) run; branch is stronger.

Static testing 21. What is static testing? → Checking software without running it — reviews and static analysis; finds defects early and cheaply. 22. Types of reviews? → Informal, walkthrough, technical review, inspection (least → most formal).

Defects 23. Severity vs priority? → Severity = how bad the impact; priority = how soon to fix. Independent — a homepage logo typo is low severity but high priority. 24. Walk me through the defect lifecycle. → New → Assigned → Open → Fixed → Retest → Verified → Closed (with Reopened/Deferred/Duplicate/Rejected as needed). 25. What makes a good bug report? → Clear title, exact steps, expected vs actual, severity/priority, environment, evidence (screenshot/logs), reproducibility.

Agile & management 26. Scrum roles/events/artifacts? → 3 roles (PO, SM, Dev Team), 5 events (planning, standup, review, retro, refinement), 3 artifacts (product backlog, sprint backlog, increment). 27. DoD vs acceptance criteria? → DoD = general "done" checklist for all stories; acceptance criteria = specific conditions for one story. 28. What is risk-based testing? → Prioritize testing by likelihood × impact; test high-risk, high-use areas first. 29. What is an RTM and why use it? → Requirement Traceability Matrix maps requirements to test cases to prove full coverage and find gaps. 30. TDD vs BDD? → TDD = write the test first, then the code. BDD = describe behavior in Given/When/Then (Cucumber/Gherkin) so non-tech folks understand.

Practical 31. How would you test a login page? → Functional (valid/invalid credentials, empty fields, locked account), boundary (max length), security (SQL injection, password masking, brute-force lockout), usability, compatibility (browsers), and negative cases. (Uses EP + BVA + error guessing.) 32. How do you decide what to automate? → Automate stable, repetitive, high-value, frequently-run tests (regression, smoke); keep exploratory, one-off, and rapidly-changing UI tests manual. 33. A developer says "not a bug" — what do you do? → Re-verify against the requirement, share exact steps + logs + screenshot; if it truly contradicts the requirement, escalate calmly to the PM/BA with evidence. 34. What is a hotfix? → An urgent fix applied directly to production for a critical issue. 35. How do you test with unclear/missing requirements? → Ask the BA/PO, use exploratory testing, base tests on similar features and risk, and document assumptions.

Final memory sheet (say these fast)¶

7 principles: defects-present, exhaustive-impossible, early, clustering, pesticide, context, absence-fallacy.
Error → Defect → Failure.
Levels: Unit → Integration → System → Acceptance.
Static = review (don't run); Dynamic = run.
EP (groups) + BVA (edges) go together.
Severity = how bad; Priority = how soon.
Retest = same case; Regression = other cases.
Verification = building it right; Validation = right thing.
QA prevents (process); QC detects (product).