Manual Testing Foundations | Playwright SDET Mastery

33Manual Testing Foundations

What you will master here

SDLC vs STLC — phases and deliverables
Verification vs Validation
Test levels (unit / integration / system / acceptance) and types
Functional vs non-functional testing
Test design techniques (BVA, equivalence, decision table, state transition)
Defect lifecycle and severity vs priority
Smoke / sanity / regression / retesting
Agile testing — sprints, definition of done, exploratory testing

33.1 SDLC vs STLC

SDLC (Software Development Life Cycle)

Requirements gathering
Analysis
Design
Implementation (coding)
Testing
Deployment
Maintenance

STLC (Software Testing Life Cycle)

Requirements analysis (testing perspective)
Test planning
Test case design
Test environment setup
Test execution
Test closure

33.2 Verification vs Validation

Verification	Validation
"Are we building the product right?"	"Are we building the right product?"
Static — review docs, code, design	Dynamic — actually run the product
No code execution	Code execution required
Reviews, walkthroughs, inspections	Functional, UAT, system testing

33.3 Test levels

Level	Who writes it	What it covers
Unit	Developer	One function/class in isolation
Integration	Developer + SDET	Two or more modules together
System	SDET / QA	End-to-end application
Acceptance (UAT)	Business / end users	Validates business needs

33.4 Functional vs non-functional

Functional types

Unit / Integration / System / Acceptance
Smoke, sanity, regression, retesting
UI, API, DB, end-to-end
White-box, black-box, gray-box

Non-functional types

Performance (load, stress, soak, spike)
Security (penetration, vulnerability)
Usability / UX
Accessibility (WCAG)
Compatibility (browser, device, OS)
Localisation / Internationalisation
Reliability / Recovery
Scalability

33.5 Test design techniques (interviewers ask these)

Boundary Value Analysis (BVA)

Bugs cluster at boundaries. For an input that accepts 1–100, test 0, 1, 2, 99, 100, 101.

Equivalence partitioning

Divide the input range into classes where the behaviour should be identical. Test one value per class. For 1–100, partitions are: <1 (invalid), 1–100 (valid), >100 (invalid). Three tests cover the range conceptually.

Decision table

Cross-product of conditions → expected outcomes. For login: { valid email, valid pw, captcha solved } → 8 rows covering every truth combination.

State transition

For state-machine systems (order: pending → paid → shipped → delivered). Test every valid transition and assert invalid ones are rejected.

Pairwise / all-pairs

For many input dimensions, test every pair of values rather than every combination. Tools like PICT generate the cases. Catches ~95% of multi-input bugs with far fewer tests.

Error guessing

Experienced testers guess where bugs hide — empty fields, max lengths, special characters, race conditions. Not systematic, but high signal.

33.6 Defect lifecycle

Figure 14 — A bug travels through these states. SDET often owns "Verified/Closed" and "Reopened".

33.7 Severity vs Priority — the must-know distinction

Severity	Priority
Impact of the bug on the system	Order in which it should be fixed
Critical / High / Medium / Low	P0 / P1 / P2 / P3
Decided by tester / system	Decided by PM / business
Typo on login page = Low severity	Same typo on a billion-dollar launch page = High priority
App crash on rare path = High severity	Same crash affects 3 users / month = Low priority

33.8 Smoke / Sanity / Regression / Retesting

Type	What it is	When
Smoke	Build-acceptance: app boots, critical paths work	Every new build
Sanity	Narrow check after a small change	Targeted to changed area
Regression	Re-run existing tests to ensure new changes didn't break old features	Per release / nightly
Retesting	Re-run the test that found a bug, after the fix, to confirm it's gone	After every bug fix

33.9 Test artefacts

Test plan — scope, schedule, resources, risk
Test strategy — high-level approach across projects
Test case — id, title, preconditions, steps, expected result, actual result, status
Test data — inputs needed for the cases
Traceability matrix — req → test mapping
Test summary report — pass/fail counts, defects, recommendation

33.10 Agile testing

Testing happens every sprint, not at the end
SDET pairs with developers during story implementation (3 amigos: PM + dev + tester)
Definition of Done includes: unit tests pass, code review done, no high/critical bugs open, regression green
Exploratory testing remains valuable — scripted tests find what they're designed to find; exploratory finds the unexpected
Agile testing quadrants (Brian Marick): Q1 unit/component (tech-facing, supports team), Q2 functional acceptance (business-facing, supports team), Q3 exploratory/usability (business-facing, critiques product), Q4 perf/security (tech-facing, critiques product)

Module 24 — Manual Testing Q&A bank

Difference between verification and validation?

Verification — "are we building the product right?" — static checks of design/code/docs. Validation — "are we building the right product?" — dynamic testing of the running product against requirements.

SDLC vs STLC?

SDLC is the whole software lifecycle (requirements → analysis → design → coding → testing → deploy → maintain). STLC is the testing-specific subset (req analysis → planning → design → setup → execution → closure). STLC happens inside SDLC's testing phase.

Severity vs priority?

Severity = how bad the bug is technically (impact on system). Priority = how urgent the fix is (business need). A typo on a feature launch page = low severity, high priority. A crash on a feature 3 users hit = high severity, low priority.

Difference between smoke, sanity and regression?

Smoke: shallow build acceptance — does it boot? Sanity: narrow check of a recent change — does the fix work? Regression: full re-run of existing tests to catch unintended breakage. Each has different scope and frequency.

Boundary value analysis?

Bugs cluster at boundaries. For input range 1–100, test 0, 1, 2, 99, 100, 101. Catches off-by-one and boundary handling bugs with minimal cases.

Equivalence partitioning?

Divide inputs into classes where behaviour should be identical, then test one value from each class. For 1–100, partitions are <1, 1–100, >100 — three tests cover the range conceptually.

What's a decision table?

A grid of conditions × actions. Each row is a unique combination of conditions and the expected outcome. Ensures every business rule combination is tested. Common in pricing, eligibility, and discount logic.

What's exploratory testing?

Simultaneous test design + execution, guided by experience and curiosity. Not random — tester forms hypotheses ("what if I leave this empty?") and runs them. Finds bugs scripted tests miss because they weren't designed.

What's the Definition of Done in agile?

A team-agreed checklist a story must satisfy before it's "done". Typically: code reviewed, unit tests passing, regression green, no high/critical bugs open, documentation updated, deployed to staging.

What's the difference between retesting and regression?

Retesting: re-run the specific test that originally found a bug, after the fix, to confirm it's gone. Regression: re-run a broader suite to ensure the fix didn't break anything else. Both happen after a bug fix.

What is a Test Plan vs Test Strategy?

Test Strategy is org-/program-level — long-lived, the overall philosophy (test pyramid, tooling, environments). Test Plan is project-/release-level — scope, schedule, resources, risk, exit criteria for one effort.

White-box vs black-box vs gray-box?

White: tests written with knowledge of the code (statement / branch coverage). Black: tests written from spec, no code knowledge. Gray: in between — knowing data structures or DB schema but not implementation. SDETs do all three.

What's an Acceptance test?

Validates business requirements from a user's perspective. Performed by stakeholders (UAT) or written as automated specs (ATDD / BDD with Cucumber). Pass = ready to release.

What's positive vs negative testing?

Positive: verify the system works with valid inputs and intended flows. Negative: verify it handles invalid inputs gracefully — bad data, wrong types, security exploits, edge cases. Negative often finds more bugs.

What's a "happy path" vs "edge case"?

Happy path: the most common valid user flow. Edge case: unusual but valid input — empty list, single item, max length, boundary numbers, Unicode, RTL languages. Always test both.

What are entry and exit criteria for testing?

Entry: conditions that must be true before testing can start (build deployed, env ready, test data seeded). Exit: conditions for stopping (all critical tests pass, no high/critical bugs open, coverage threshold met).

33.11 Test case template (concrete)

ID:         TC-LOGIN-001
Title:      Successful login with valid credentials
Module:     Authentication
Priority:   P1
Severity:   Critical

Preconditions:
  - User account exists: qa@test.com / p4ssw0rd
  - Browser on supported version (Chrome 120+)
  - Network connection available

Test data:
  - email: qa@test.com
  - password: p4ssw0rd

Steps:
  1. Navigate to https://app/login
  2. Enter email in Email field
  3. Enter password in Password field
  4. Click "Sign in"

Expected result:
  - Redirect to /dashboard within 3 seconds
  - "Welcome, QA" message visible
  - Session cookie set (httpOnly, SameSite=Lax, Secure)
  - 200 status from POST /api/auth/login

Actual result: [filled during execution]
Status:       [Pass / Fail / Blocked / Skip]
Tester:       Yash
Date:         2026-06-19
Build:        v3.2.1-rc4
Defect IDs:   [linked if failed]

33.12 Bug report template (gold standard)

Title:      [Module] Concise description of the problem

Environment:
  - Browser: Chrome 120.0.6099.71 on macOS Sonoma 14.2
  - URL:     https://staging.app.com/checkout
  - Build:   v3.2.1-rc4 (commit abc123)
  - Account: qa-user-42 (regular role)

Preconditions:
  - Logged in as qa-user-42
  - Cart contains 2 items totaling $99

Steps to reproduce:
  1. Click "Checkout" button on cart page
  2. Enter shipping address (any valid)
  3. Select "Express" shipping
  4. Click "Place Order"

Expected:
  - Order created with status "pending"
  - Confirmation email sent within 10 seconds
  - Redirect to /orders/{id} page

Actual:
  - Order placed (visible in DB)
  - Page shows generic 500 error overlay
  - No email received after 5 minutes
  - Browser console: "Cannot read property 'id' of undefined" in checkout.js:142

Reproducible: Yes (5/5 attempts)
Frequency:    100%
Severity:     High (functional regression)
Priority:     P1 (blocks production deploy)
Workaround:   None

Attachments:
  - screenshot-error.png
  - playwright-trace.zip
  - browser-console.log
  - har-network-capture.har

Related:
  - Similar to BUG-2341 (closed: webhook race)
  - Blocks STORY-5670 (express shipping launch)
  - Linked to PR #1234

Root cause hypothesis (optional, mark as such):
  - Likely race between order creation and email service publish

33.13 Test Plan template (one-page)

Project:        Acme Checkout v3.2
Test Lead:      Yash
Start / End:    2026-06-19 → 2026-07-03
Build under test: v3.2-rc

Scope:
  IN:  Checkout flow (cart → payment → confirmation), refund, cancel
  OUT: User registration, search, admin panel (separate plan)

Test types:
  - Functional (API + UI E2E)
  - Regression (existing checkout suite)
  - Cross-browser (Chrome, Safari, Firefox)
  - Mobile responsive (Pixel 7, iPhone 14)
  - Accessibility (axe automated + 1 manual NVDA pass)
  - Performance (Lighthouse on checkout, p95 latency on /api/orders)
  - Security (OWASP scan via ZAP baseline)

Risk areas:
  - Payment provider integration (new Stripe webhook handler)
  - Inventory race conditions on flash sale
  - GDPR compliance for new shipping address fields

Test environments:
  - Local: dev mocks + sqlite
  - QA: shared staging at qa.acme.com
  - UAT: production-like, week of 06-26

Entry criteria:
  - Code freeze on 06-18
  - Smoke passes on QA env
  - Test data seeded (1000 mock orders)
  - All P1 bugs from prior release closed

Exit criteria:
  - 0 P1/P2 open bugs
  - Regression suite 100% pass on QA
  - p95 latency < SLA on perf tests
  - 1 sprint of stable UAT use
  - Stakeholder sign-off

Resources:
  - 2 SDETs (Yash, Bob)
  - 1 dev rotates for exploratory sessions
  - Cloud farm: BrowserStack (12 parallel)

Communication:
  - Daily standup 10am
  - Slack channel #acme-checkout-v32-qa
  - Slack alert on each P1
  - Weekly Friday demo for PM

Tools:
  - Playwright (E2E + visual)
  - REST Assured (API)
  - JMeter (load smoke)
  - Jira / Zephyr

33.14 RTM (Requirements Traceability Matrix) example

Req ID	Acceptance criterion	Test cases	Status
FR-CHK-01	User can place order with valid card	TC-CHK-001, TC-CHK-002, api/checkout.spec L20	Pass
FR-CHK-02	Declined card shows error, no order created	TC-CHK-003, api/checkout.spec L42	Pass
FR-CHK-03	Duplicate-click does not double-charge (idempotency)	TC-CHK-004, api/checkout.spec L80	Gap — no test
NFR-CHK-01	p95 latency < 1.5 s	perf/checkout.k6.js	Pass
NFR-CHK-02	WCAG 2.2 AA	a11y/checkout.spec	Fail (3 contrast issues)

33.15 Exploratory testing — session-based

Time-boxed (60-90 min) sessions with a charter ("explore checkout under network failures"). Take notes; file bugs as you find them. Less script, more curiosity. Catches what scripted misses.

33.16 Defect lifecycle states (full)

New → Assigned → In Progress → Fixed → Retest → Verified/Closed
              ↓                       ↓        ↓
          Rejected               Reopened   (back to In Progress if fix fails)
              ↓
          Duplicate / Won't Fix / Cannot Reproduce

33.17 Testing pyramid in numbers

~70% unit (devs own; fast, isolated)
~20% integration / contract / API (SDET owns mostly)
~10% E2E (SDET owns; slow, full browser)
Inverted = trouble. Many slow E2Es hiding poor unit coverage.

Module 24 — More Manual Testing Q&A

Test case must-have fields?

ID, title, module, priority, preconditions, test data, steps, expected result, actual result, status, tester, date, build, related defects.

Why "expected vs actual" instead of just "broken"?

Anyone reading later (dev, PM, future you) needs to know WHAT was supposed to happen. "Broken" is opinion; "Expected X, got Y" is fact.

What's a good bug report look like?

Reproducible steps, environment, expected vs actual with concrete values, severity + priority, attachments (screenshot, video, trace, logs). A stranger should reproduce it from your text alone.

What's "Cannot Reproduce" really mean?

Usually: steps are incomplete, env differs (browser/data/account), or it's a race condition the reporter didn't capture. Push back with a request for trace/video; don't close silently.

Why is exploratory testing valuable?

Scripted tests find what they're designed to find. Exploratory finds the unexpected — usability issues, edge interactions, integration bugs scripted didn't think to try.

What's a charter in exploratory?

A short statement of intent + time budget: "Explore checkout under intermittent network for 60 min". Keeps the session focused without scripting it.

When do you stop testing?

Exit criteria met: P1 bugs closed, regression green, coverage threshold met, stakeholder sign-off. Or: time/budget exhausted (be explicit about residual risk).