Test Management & Process

Agile testing integrates testing throughout short, iterative development cycles (sprints) rather than as a separate phase at the end — testers work alongside developers continuously, testing features as they're built, adapting quickly to changing requirements between iterations.

A bug report is the documented record of a defect — a clear title, steps to reproduce, expected versus actual results, environment details, and supporting evidence — written so someone who wasn't present when the bug was found can understand, reproduce, and eventually fix it.

Bug reproducibility describes how reliably a defect can be triggered again using the same steps — an "always reproducible" bug happens every time; an "intermittent" one only sometimes; a "cannot reproduce" bug can't be triggered again at all with the information currently available, and needs more investigation before it can be fixed.

Bug triage is the regular process of reviewing newly reported defects as a team, assigning severity and priority, and deciding what gets worked on next — separating genuinely urgent issues from lower-impact ones in a backlog that would otherwise grow unmanageable without deliberate prioritization.

The defect lifecycle is the standard sequence of states a bug moves through from discovery to resolution — typically New, Open, In Progress, Fixed, Retest, Verified, and Closed — giving a team a shared, trackable process for managing defects instead of an ad hoc, inconsistent one.

Definition of Done is a team's shared, agreed checklist of what "complete" actually means for any piece of work — code written, tests passing, code reviewed, documentation updated — used to prevent inconsistent, subjective judgments about whether a story or feature is actually finished.

Definition of Ready is a team's shared checklist for whether a piece of work is sufficiently well-defined to actually start — clear acceptance criteria, no unresolved dependencies, estimated effort — preventing a team from beginning work on something too vague or blocked to make real progress on.

Kanban for QA applies the Kanban method — visualizing work as cards moving through columns (To Do, In Progress, Testing, Done), limiting work in progress — to testing workflows, emphasizing continuous flow over fixed-length sprints, well suited to teams handling a steady stream of testing requests rather than batched sprint work.

Release testing is the final round of testing performed on a specific release candidate before it ships — confirming the exact build going to production has been fully verified, often including a full regression pass and a check that all planned exit criteria have genuinely been met.

Scrum QA describes how testing activities integrate into the Scrum framework — participating in sprint planning, testing stories within the sprint they're built, and demonstrating tested functionality at the sprint review — rather than testing as a separate phase happening after a sprint ends.

Sprint testing is the testing work performed within a single Scrum sprint — usually one to four weeks — covering the stories completed during that iteration, planned and executed within the same tight timebox as the development work it's verifying.

A test case management tool organizes, stores, and tracks test cases, test runs, and results in one central system — TestRail, Zephyr, Xray, and qTest are common examples — replacing spreadsheets or scattered documents with structured, searchable, reportable test case data.

Test case peer review has another tester or team member review newly written test cases before they're executed — checking for clarity, completeness, correct expected results, and coverage gaps — catching problems with the test itself before it's run, the same way code review catches problems before code ships.

Test estimation predicts how much time and effort testing a given piece of work will require — factoring in complexity, risk, available automation, and team experience — informing sprint planning and release schedules with a realistic testing timeline rather than an afterthought guess.

Test metrics reporting communicates the state and trends of testing activity and product quality — pass rates, defect counts, coverage, automation ROI — to stakeholders who need visibility without being in the testing details day to day.

Test risk assessment identifies and scores the areas of a system most likely to fail and most damaging if they do, directly informing where testing effort should concentrate. It's the analytical process underlying risk-based testing as a strategy.

Traceability is the ability to link related project artifacts together — a requirement to its test cases, a test case to a defect, a defect to the code change that fixed it — creating an auditable chain that answers "why does this exist" and "what does this affect" for anything in the system.

Waterfall model testing describes testing performed as a single, distinct phase after development is entirely complete, following the traditional sequential waterfall methodology — requirements, design, development, testing, deployment — each phase finishing fully before the next begins.