Test Process & Management
Testing does not live in a vacuum — it lives inside a development process. What matters here is not "click the button" but answering: which model the project follows, what the team's approach to quality is, what and how much we cover, how to prove that coverage is sufficient, and which release activities validate the product before it ships. This is the test-management level — and it is exactly what middle and senior interviews probe.
The traps here are conceptual, not syntactic: candidates flip alpha and beta, confuse strategy with plan, equate 100% code-line coverage with full coverage, and mistake an A/B test for defect-finding. Below is a map of eight layers — from SDLC models and planning documents to coverage, traceability, and release-level testing. Each layer is grounded in a table, a diagram, or a worked example.
Topic map
- SDLC models — Waterfall, Scrum, and Kanban, and where testing sits in each.
- Strategy vs test plan — the organization's high-level approach versus a document for one specific release.
- Test analysis vs test design — WHAT to test (conditions) versus HOW (concrete cases).
- Test coverage — tying coverage to requirements and risk, not to code lines.
- Traceability matrix — mapping requirements to test cases, where an empty row is a visible gap.
- Exploratory testing — testing without a spec by building a mental model of the product.
- Alpha and beta testing — internal acceptance versus a field test by real users.
- A/B testing — an experiment on live traffic to optimize a metric, not defect-finding.
Common traps
| Mistake | Consequence |
|---|---|
| Confusing which model is sequential (Waterfall) and which is iterative (Scrum) | A wrong picture of where testing sits in the cycle |
| Treating strategy and test plan as interchangeable | Loses the difference between a stable approach and a per-release plan |
| Swapping test analysis (WHAT) and test design (HOW) | Jumping to writing cases without deriving test conditions |
| Equating 100% code-line coverage with full coverage | Uncovered requirements stay invisible |
| Counting test cases instead of linking them to requirements | The traceability matrix reveals no gaps |
| Filing undocumented behavior as a bug without confirmation | False defects instead of asking the analyst or PO |
| Reversing that alpha is internal/early and beta is external/late | Confusion over who tests the release and when |
| Treating A/B testing as a defect-finding technique | Conflating a metric experiment with checking requirements |
Interview relevance
Process questions check whether you think at the test-management level, not only as a runner of test cases. A candidate who distinguishes strategy from plan, ties coverage to requirements through a traceability matrix, and can stand up a process in a team that has none, immediately looks a grade higher.
Typical checks:
- Development models and where testing sits in each (Waterfall, Scrum, Kanban).
- The difference between strategy and test plan, test analysis and test design.
- How to prove coverage is sufficient — requirements, risk, traceability matrix, not code lines.
- Release-level testing types — alpha, beta, A/B — and how an experiment differs from defect-finding.
Common wrong answer: "coverage is sufficient once 100% of code lines have run". In fact code-line coverage does not guarantee that every requirement was checked — full coverage is tied to requirements and residual risk, and traceability shows which requirements were left without a case.