The Tester's Journey — How This Guide Flows
| Stop | Question it answers | Topics |
|---|---|---|
| 1 · Mindset | What is testing really? | Definitions, 7 principles, error → defect → failure |
| 2 · The Process | Where does testing fit? | SDLC models, V-Model, STLC, documents |
| 3 · The Bug | What happens after I find one? | Defect life cycle, severity vs priority, bug report |
| 4 · The Layers | What do we test at each level? | Test levels, pyramid, functional & non-functional types |
| 5 · The Techniques | How do I design good test cases? | Black/white/grey box, EP, BVA, decision table, state transition |
| 6 · The Team | How do I work in Agile & CI/CD? | Scrum, QA role, shift-left/right, pipelines |
| 7 · The Numbers | How do we measure quality? | Metrics & KPIs, automation decisions |
Stop 1 — The Testing Mindset
1.1 What testing is (and is not)
Software testing is the activity of evaluating a product to find defects, check it against requirements and build confidence that it works. It covers two questions:
| Verification | Validation | |
|---|---|---|
| Question | Are we building the product right? | Are we building the right product? |
| How | Reviews, walkthroughs, inspections — no execution | Executing the software against user needs |
| Type | Static | Dynamic |
| Example | Reviewing the fee-refund rules in the requirement document | Raising a refund on the demo portal and checking the amount credited |
Key Takeaway
Testing shows that defects are present — it can never prove that defects are absent.
1.2 Core vocabulary
| Term | Plain meaning |
|---|---|
| Requirement | A documented need — what the system must do (functional) or how well (non-functional) |
| Test scenario | A high-level “what to test” — e.g. Verify a learner can switch batches after enrolling |
| Test case | Precise steps: preconditions, data, actions, expected result |
| Test suite | A group of test cases run together — e.g. Enrolment regression pack |
| Test data | Inputs used while testing — emails, card numbers, pincodes |
| Test environment | Hardware, software, network and data where tests run (Dev, QA, UAT, Prod) |
| Test plan | Document of scope, approach, schedule, resources and risks |
1.3 Error → Defect → Failure
| Stage | Who / where | Example |
|---|---|---|
| Error (mistake) | A human — developer, analyst, designer | Dev reads “free delivery from ₹499” as “above ₹499” |
| Defect (bug / fault) | In an artifact — code, requirement, design | The code now says if (cartTotal > 499) |
| Failure | Visible at runtime to a user | A customer with exactly ₹499 in the cart is charged delivery |
Interview Trap
Not every defect becomes a failure (the code path may never run), and not every failure comes from a defect (a network or environment problem can also cause one).
1.4 Seven principles — with a story for each
| # | Principle | Remember it as |
|---|---|---|
| 1 | Testing shows the presence of defects | A green regression report only says “nothing found today”, not “nothing wrong” |
| 2 | Exhaustive testing is impossible | A PAN-number field alone has millions of valid combinations — pick inputs by risk |
| 3 | Early testing saves time and money (shift-left) | A wrong GST rule spotted in the requirement review is a one-line fix; spotted after invoices go out, it is a crisis |
| 4 | Defects cluster together | Most bugs of a release often sit in one or two complex modules — e.g. fee calculation (Pareto 80/20) |
| 5 | Beware of the pesticide paradox | Like a mosquito repellent that stops working — an unchanged suite stops catching new bugs; refresh it |
| 6 | Testing is context dependent | A UPI payment app and a recipe blog need very different depth and techniques |
| 7 | Absence-of-errors is a fallacy | Zero open bugs, but learners still cannot find the Enroll button = failed product |
Stop 2 — The Process
2.1 SDLC models
| Model | How work flows | When testing happens | Fits |
|---|---|---|---|
| Waterfall | Requirements → Design → Code → Test → Deploy, one after another | Late, after coding | Small, fixed-scope projects |
| V-Model | Each development phase has a paired test phase | Planned early, executed after build | Stable, regulated requirements |
| Agile / Scrum | Short sprints delivering working increments | Every sprint, continuously | Most modern products |
| Kanban | Continuous flow with WIP limits, no sprints | As each card moves | Support, maintenance |
| DevOps | Dev + Ops with CI/CD pipelines | Automated, inside the pipeline | Cloud apps, microservices |
2.2 V-Model pairing
| Development side (left, going down) | Paired test level (right, going up) |
|---|---|
| Requirement analysis | Acceptance testing |
| System design | System testing |
| Architecture (high-level) design | Integration testing |
| Module (low-level) design | Unit testing |
| Coding — the bottom of the V | — |
2.3 STLC — the six phases
| Phase | Key activities | Output document |
|---|---|---|
| 1 · Requirement analysis | Study requirements, find testable items, clarify doubts | RTM (traceability matrix) |
| 2 · Test planning | Scope, strategy, effort, schedule, tools, risks | Test plan |
| 3 · Test design | Write scenarios & test cases, prepare data | Test cases, test data |
| 4 · Environment setup | Prepare servers, builds, accounts, tools | Ready environment, smoke result |
| 5 · Test execution | Run tests, log defects, retest fixes | Execution status, defect reports |
| 6 · Test closure | Analyse metrics, lessons learned | Test summary report |
Stop 3 — Life of a Bug
3.1 Defect life cycle
| Status | Who moves it | Meaning |
|---|---|---|
| New | Tester | Bug logged |
| Assigned | Lead / manager | Given to a developer |
| Open | Developer | Analysis / fix in progress |
| Fixed | Developer | Fix delivered in a build |
| Retest | Tester | Verifying the fix |
| Closed | Tester | Fix verified |
| Reopened | Tester | Fix did not work → goes back to developer |
Side exits: Rejected (not a bug / works as designed), Duplicate (already logged), Deferred (fix in a later release), Not reproducible (dev cannot recreate it).
3.2 Severity vs priority
| Severity | Priority | |
|---|---|---|
| Meaning | Technical impact on the system | Business urgency to fix |
| Set by | Tester (mostly) | Product owner / lead |
| Levels | Critical · Major · Minor · Trivial | P1 Urgent · P2 High · P3 Medium · P4 Low |
| Combination | Example |
|---|---|
| High severity, high priority | Checkout crashes for every user |
| High severity, low priority | Year-end audit export corrupts the Excel file — report is used once a year |
| Low severity, high priority | Diwali offer banner still shows last year's date on launch morning |
| Low severity, low priority | Tooltip text wraps awkwardly on one tablet size |
3.3 Writing a bug report that gets fixed
| Field | AutomateWithUs example |
|---|---|
| Bug ID | AWU-DEF-2207 |
| Title | Seats-left counter does not refresh after a learner cancels an enrolment |
| Environment | QA build 4.2.0 · Edge 129 · Android 14 tablet |
| Severity / Priority | Major / P1 (batch starts Monday) |
| Steps | 1. Open Playwright Nov batch (shows 5 seats left) 2. Enroll 3. Cancel the enrolment from My Batches 4. Re-open the batch page |
| Expected | Counter returns to 5 seats left |
| Actual | Counter stays at 4 until the server cache expires (~30 min) |
| Attachments | Screen recording, API response of /seats, HAR file |
Stop 4 — The Layers of Testing
4.1 Test levels
| Level | What is tested | Usually by | Tools |
|---|---|---|---|
| Unit | One function / class in isolation | Developers | JUnit, TestNG, pytest, Jest |
| Integration | Interfaces between modules, services, APIs | Developers / QA | Postman, REST Assured, Playwright API |
| System | Complete product against requirements | QA team | Selenium, Playwright, manual |
| Acceptance (UAT) | Business workflows by real users | Business users / client | Manual, BDD tools |
4.2 Integration approaches — stubs & drivers
| Approach | Start from | Missing piece replaced by |
|---|---|---|
| Top-down | Upper modules first | Stub — a dummy called module that returns canned data |
| Bottom-up | Lower modules first | Driver — a dummy calling module that invokes the code under test |
| Big-bang | Everything at once | Nothing — but failures are hard to isolate |
| Sandwich | Both ends toward the middle | Stubs and drivers |
4.3 The test pyramid
Roughly 70% unit, 20% integration/API, 10% UI/E2E. Lower layers are faster, cheaper and less flaky; the top layer is slow and costly, so keep it for critical journeys only.
4.4 Functional testing types
| Type | Purpose | Typical trigger |
|---|---|---|
| Smoke | Are the critical features alive? Accept/reject the build | Every new build |
| Sanity | Is this specific fix/area working? | Small change or bug fix |
| Re-testing | Run the exact failed case again | After a fix |
| Regression | Did the change break anything else? | After every change |
| Integration | Do modules talk correctly? | After module completion |
| System / E2E | Does the whole flow work end to end? | Before release |
| UAT | Does it meet business needs? | Before go-live |
| Exploratory | Learn, design and execute together | Unclear specs, new features |
| Ad-hoc | Informal, unplanned checks | Quick checks under time pressure |
| Smoke | Sanity | Regression | |
|---|---|---|---|
| Breadth | Wide, shallow | Narrow, deep | Wide, deep |
| When | New build | Minor fix | Any change |
| Decides | Can testing start? | Is this area stable? | Is everything still OK? |
| Mumbai local analogy | Train starts and doors open | The repaired coach fan works | Full rake inspection at the car shed |
Interview Trap
Re-testing ≠ regression. Re-testing confirms the fix; regression confirms nothing else broke. Re-testing is planned for specific defects; regression is a broad, often automated suite.
4.5 Non-functional testing types
| Type | Question | Tools |
|---|---|---|
| Performance | Response time & throughput under normal load? | JMeter, k6, Gatling |
| Load | Behaviour at expected peak users? | JMeter, Locust |
| Stress | Where does it break beyond capacity? | JMeter, Gatling |
| Spike | Sudden jumps — e.g. sale at 12:00? | k6, JMeter |
| Volume | Huge data sets? | Custom scripts |
| Scalability | Does adding resources add capacity? | Cloud load tools |
| Security | XSS, SQL injection, broken auth? | OWASP ZAP, Burp Suite |
| Usability | Is it easy and intuitive? | Manual sessions |
| Compatibility | Browsers, OS, devices, resolutions? | BrowserStack, Sauce Labs |
| Accessibility | Usable with disabilities (WCAG)? | axe, Lighthouse, WAVE |
4.6 Static vs dynamic testing
| Static | Dynamic | |
|---|---|---|
| Code executed? | No | Yes |
| Finds | Defects in requirements, design, code | Failures at runtime |
| Activities | Reviews, walkthroughs, inspections, static analysis | Unit to UAT test execution |
| Tools | SonarQube, ESLint, Checkstyle | Selenium, Playwright, Postman |
| Cost of finding a bug | Lower (earlier) | Higher (later) |
Review formality, least to most: informal review (peer glance) → walkthrough (author leads) → technical review (experts evaluate) → inspection (formal roles — moderator, author, reviewer, scribe — with metrics).
Stop 5 — Test Design Techniques
5.1 Black, white and grey box
| Black box | White box | Grey box | |
|---|---|---|---|
| Code visible? | No | Yes | Partly |
| Done by | QA | Developers | QA with technical knowledge |
| Focus | Inputs → outputs | Code paths & logic | Behaviour + structure |
| Techniques | EP, BVA, decision table, state transition | Statement, branch, path coverage | Matrix, pattern testing |
| Example | Functional, system, UAT | Unit tests, code review | API & integration testing |
5.2 Black-box techniques with worked examples
| Technique | Idea | Worked example (passengers per booking: 1–6) |
|---|---|---|
| Equivalence Partitioning | Split inputs into groups that behave alike; test one value per group | Invalid low (0) · Valid (1–6): 3 · Invalid high (7+): 9 |
| Boundary Value Analysis | Bugs cluster at edges; test on and around each boundary | 0, 1, 2 · 5, 6, 7 |
| Decision Table | Every combination of conditions → expected action | Festive coupon: registered learner × cart ≥ ₹2,000 → 4 rules (see table below) |
| State Transition | Test moves between states on events | Order: Placed → Shipped → Delivered; “Cancel” allowed only while Placed |
| Use Case | Main flow + alternate + exception flows | Learner enrolls → pays by UPI → UPI times out → retries with card |
| Error Guessing | Experience-based attack on likely weak spots | Only spaces, Marathi/Hindi characters, ₹ symbol, pasted text with line breaks, leading zeros like 0007 |
Decision Table — Festive Coupon
Condition | R1 | R2 | R3 | R4
--------------------------+----+----+----+----
Registered learner? | Y | Y | N | N
Cart total >= Rs 2,000? | Y | N | Y | N
--------------------------+----+----+----+----
Apply 20% festive off | X | | |
Show "add more to unlock" | | X | |
Ask learner to sign up | | | X | X
5.3 White-box coverage
| Coverage | Goal | Strength |
|---|---|---|
| Statement | Every line runs at least once | Minimum |
| Branch / decision | Every if/else outcome (true & false) runs | Recommended |
| Condition | Each sub-condition evaluated true and false | Stronger for complex conditions |
| Path | Every possible route through the code | Strongest, often impractical |
| Loop | Loop runs 0, 1, many and max times | Catches off-by-one bugs |
Key Takeaway
100% branch coverage guarantees 100% statement coverage — but not the other way round.
Stop 6 — Working in a Team
6.1 Scrum essentials
| Term | Meaning |
|---|---|
| Sprint | Time-boxed iteration, usually 1–4 weeks, delivering a usable increment |
| User story | “As a [role], I want [feature], so that [benefit]” |
| Acceptance criteria | Conditions a story must satisfy to be accepted |
| Definition of Ready | Story is clear, estimated and testable — can enter the sprint |
| Definition of Done | Coded, reviewed, tested, documented, deployed to staging |
| Sprint planning | Team picks stories and commits to the sprint goal |
| Daily stand-up | 15 minutes: done yesterday, plan today, blockers |
| Sprint review | Demo the increment to stakeholders |
| Retrospective | What went well, what did not, what we will change |
| Backlog grooming | Refine, split and estimate upcoming stories |
| Role | Responsibility |
|---|---|
| Product Owner | Owns and prioritises the backlog; accepts or rejects work |
| Scrum Master | Removes blockers, coaches the team, guards the process |
| Development team | Cross-functional — developers, QA, designers — delivers the increment |
QA in Agile joins grooming, questions acceptance criteria, writes tests during the sprint, automates regression and gives continuous feedback — quality is the whole team's responsibility.
6.2 CI/CD and where tests run
| Term | Meaning |
|---|---|
| Continuous Integration | Code merged often; every merge triggers a build and automated tests |
| Continuous Delivery | Every build is release-ready; production deploy needs a manual approval |
| Continuous Deployment | Every change that passes the pipeline goes to production automatically |
| Shift-left | Test earlier — reviews, unit/API tests during development |
| Shift-right | Test in production — monitoring, canary releases, A/B tests, feature flags |
Pipeline At A Glance
Commit → Build & lint → Unit tests → API tests → UI smoke → Deploy to staging
(seconds) (seconds) (minutes) (minutes) (approved)
Tools: Jenkins · GitHub Actions · GitLab CI · Azure DevOps · Docker · Kubernetes
Stop 7 — Measuring Quality
7.1 Metrics you should be able to calculate
| Metric | Formula | Tells you |
|---|---|---|
| Defect density | Defects ÷ size (KLOC or function points) | Quality per unit of code |
| Pass rate | Passed ÷ executed × 100 | Execution health |
| Defect leakage | Production defects ÷ total defects × 100 | What escaped testing |
| Defect rejection ratio | Rejected ÷ reported × 100 | Accuracy of bug reports |
| Requirement coverage | Requirements covered ÷ total × 100 | Completeness of testing |
| Automation coverage | Automated cases ÷ total cases × 100 | Automation maturity |
| Mean time to resolve | Average time New → Closed | Team responsiveness |
Quick check: 200 tests executed, 184 passed → pass rate = 92%. 45 defects found in QA, 5 found in production → leakage = 5 ÷ 50 × 100 = 10%.
7.2 Automate or keep manual?
| Automate | Keep manual |
|---|---|
| Regression that runs every sprint | Exploratory testing |
| Smoke & sanity on every build | Usability and look-and-feel judgement |
| Data-driven tests with many inputs | One-time or rarely run checks |
| Cross-browser / cross-device runs | Features whose requirements change daily |
| API and performance checks | Ad-hoc investigation |
| Framework / tool | Language | Strength |
|---|---|---|
| Selenium | Java, Python, C#, JS | Widely used web UI automation |
| Playwright | TS/JS, Python, Java, C# | Modern web UI + API, auto-waiting |
| Cypress | JavaScript | Front-end focused testing |
| REST Assured | Java | API automation |
| Appium | Java, Python, JS | Android & iOS |
| TestNG / JUnit / pytest | Java / Python | Test runners & assertions |
Quick-Reference Glossary
| Term | Meaning |
|---|---|
| Quality Assurance | Process-oriented, preventive — improving how we build |
| Quality Control | Product-oriented, detective — testing what we built |
| Alpha testing | Internal testing at the developer's site before beta |
| Beta testing | Real users test in their own environment before release |
| Positive / negative testing | Valid inputs (happy path) / invalid inputs (graceful handling) |
| Globalization (i18n) | Works across languages, currencies, time zones |
| Localization (L10n) | Adapted correctly for a specific region |
| Monkey testing | Random, unplanned inputs to see if anything breaks |
| Gorilla testing | Hammering one module repeatedly |
| A/B testing | Two variants shown to real users to see which performs better |
| Canary release | Roll out to a small % of users first |
| Feature flag | Turn a feature on/off in production without redeploying |
| Test harness | Tests + stubs + drivers + data needed to run automated tests |
| Mock | A fake object that imitates real behaviour for isolated tests |
Templates
Test case template
| Field | Example |
|---|---|
| Test case ID | TC_ENROL_014 |
| Title | Verify FESTIVE20 reduces the batch fee by 20% |
| Precondition | Learner signed in; Playwright batch (₹5,000) in cart |
| Test data | Coupon: FESTIVE20 |
| Steps | 1. Open cart 2. Enter FESTIVE20 3. Click Apply |
| Expected result | Discount ₹1,000 shown; payable ₹4,000 |
| Actual result | (filled during execution) |
| Status | Pass / Fail / Blocked / Skipped |
| Priority | P2 |
Interview Questions & Answers
Q1. Verification vs validation?
Verification: building it right (reviews, static). Validation: building the right thing (execution, dynamic).
Q2. Error vs defect vs failure?
Human mistake → flaw in the artifact → wrong behaviour seen at runtime.
Q3. Smoke vs sanity?
Smoke: broad, shallow check of a new build. Sanity: narrow, deep check after a small fix.
Q4. Re-testing vs regression?
Re-testing verifies the fix; regression verifies nothing else broke.
Q5. Give a low-severity, high-priority bug.
A launch-day offer banner showing last year's date.
Q6. What is the pesticide paradox?
Repeating the same tests stops finding new bugs; tests must be reviewed and refreshed.
Q7. BVA values for a “quantity 1–50” field?
0, 1, 2 and 49, 50, 51.
Q8. Stub vs driver?
Stub replaces a called module (top-down); driver replaces a calling module (bottom-up).
Q9. What is an RTM?
A matrix mapping each requirement to its test cases to prove coverage.
Q10. What is defect leakage?
Share of defects found in production out of all defects — lower is better.
Q11. Entry and exit criteria?
Conditions to start a test phase (build deployed, smoke passed) and to finish it (critical bugs closed, coverage met).
Q12. What does QA do in a sprint?
Refine stories, define acceptance tests, test and automate during the sprint, report quality status.
Want to learn this live?
Small batches, real projects, mock interviews included. Sit in on a free demo class first.
See all coursesBook a mock interview