Test Process & Management

Tie coverage to requirements, not just to code lines. A traceability matrix maps each requirement to the test cases that verify it, so a requirement with no linked case is a visible gap. Combine that with risk: ensure high-risk areas are covered first. Coverage is sufficient when every requirement is traced and residual risk is acceptable.

With documentation you test against a spec — deriving cases from requirements and checking conformance. Without it, you rely on exploratory testing: learning the product by using it, building a mental model, and judging behavior against common sense and analogous products. On undocumented behavior, do not assume it is a bug — flag it, ask the analyst or PO, and get the expectation confirmed before reporting.

The test pyramid prescribes many fast, cheap unit tests at the base, fewer integration/service tests in the middle, and few slow, brittle UI/e2e tests at the top. It balances speed, cost, and confidence. Applying it means pushing each check to the lowest level that can catch the bug, and avoiding the ice-cream-cone anti-pattern of too many UI tests and too few unit tests.

Waterfall runs sequential phases (requirements → design → build → test → release) with little overlap and late testing. Scrum is iterative: fixed-length sprints deliver increments, with roles Product Owner, Scrum Master, and the development team. Kanban is continuous flow with no sprints — work is pulled across a board under WIP (work-in-progress) limits.

A/B testing splits live traffic between two variants (A and B) and measures which performs better against a metric — e.g. does a green "Buy" button beat a red one on conversion? It is an experimentation/optimization technique, not defect-finding: it compares outcomes statistically rather than checking behavior against requirements like functional testing does.

Alpha testing happens internally, before release, at the developer's site — done by internal staff (often QA or selected employees) in a controlled environment. Beta testing happens externally, later in the cycle, in the real environment of actual end users who report issues from production-like usage. Alpha is in-house and earlier; beta is in-the-wild and later.

Static testing examines artifacts without running the code — reviews, walkthroughs, and inspections, plus static-analysis tools. Dynamic testing executes the software and checks its behavior. Static finds defects earliest and cheapest, before code exists. Reviews are its core manual form: a peer review of test cases or requirements catches ambiguity a dynamic run could not surface as cheaply.

A test strategy is a high-level, often organization- or product-wide document describing the general approach to testing — levels, types, tools, standards — and it changes rarely. A test plan is project- or release-specific and derived from the strategy: it sets scope, schedule, resources, environments, entry/exit criteria, and risks for that particular effort.

Test analysis answers WHAT to test: study the test basis (requirements, specs, risks) and derive the test conditions to cover. Test design answers HOW to test: turn those conditions into concrete test cases using techniques like equivalence partitioning, boundary-value analysis, and decision tables. Analysis identifies; design produces the cases.

Session-based testing splits exploratory testing into time-boxed sessions (usually 60–120 min), each driven by a charter — a short mission stating what to explore, which areas or risks, and with what data. The tester logs findings and coverage in a session sheet, then holds a debrief. It makes exploratory testing accountable and reportable without scripting every step in advance.

Match the dimensions that change behavior: data volume, service and library versions, network, config, flags, secrets, and production-like load. Sync them via infrastructure-as-code so environments do not drift as prod evolves. Differ only where safety demands — masked data, sandbox credentials. Prove parity by comparing versions and config and smoke-running risky flows before a release decision.

Start from the product, users, and risks — a risk-based approach decides where to invest. Introduce lightweight docs first (checklists, then cases for critical flows) and entry/exit criteria. Build a smoke suite for build acceptance and a growing regression suite; explore where specs are thin. Establish a bug workflow: report → triage by severity/priority → fix → verify. Integrate into the release cycle with CI gates and track metrics (escaped defects, coverage, cycle time) proving it works.