Fast definitions for terminology interviewers often use to check whether basic QA concepts are separated correctly.

The seven principles are frequent foundation-level interview material and explain why testing must be selective and context-driven.

The core idea is faster, cheaper feedback and shared quality ownership—not merely moving the same manual tests earlier.

ISTQB defines seven test activities, but the syllabus list is not a chronological seven-step flow. A useful simplified working sequence is planning → analysis → design → implementation → execution → completion, while test monitoring and control runs continuously across all of them.

These terms are frequently collapsed in interviews; separate the scope and decision each one documents instead of memorizing one rigid template.

Allocate earlier and deeper testing effort where product risk is highest, then make residual risk explicit when constraints force trade-offs.

When everything cannot be tested, make the selection logic and resulting residual risk explicit instead of pretending coverage is unchanged.

A strong interview answer checks both the wording of one requirement and whether the set of requirements works coherently together.

Requirements are a graph, not a flat list; interview-ready review includes decomposition, dependencies, conflicts, and overlap between requirements.

Traceability is useful when it answers coverage, origin, or change-impact questions; a giant spreadsheet is not the goal.

Know the major review forms and separate human review techniques from tool-based static analysis.

A test level answers where the test object sits in the system decomposition; do not mix levels with test types or regression labels.

A test type answers what objective or quality question is being evaluated; the same type can be applied at several test levels.

Use canonical quality-characteristic names in interviews, then translate each one into practical testing questions.

These are planning heuristics, not laws; use them to explain feedback speed, scope, and the different purposes of technical and business-facing testing.

Start from the formal family name, then name the techniques; this is the interview-friendly map for choosing how tests are derived.

Divide a large input or state domain into partitions expected to behave similarly, then choose representative values from each meaningful partition.

Focus on values around behavior-changing boundaries because implementation errors frequently occur at inclusive and exclusive limits.

Use a decision table when outcomes depend on combinations of conditions; it makes hidden or contradictory business-rule combinations visible.

Use state-transition testing when the same event can behave differently depending on current state or previous events.

Use tester experience deliberately: the technique should guide where to look, while the mission and evidence remain visible.

When an expected result is unclear, identify a credible source of truth before adding more test execution.

Interview answers should focus on reproducibility and purpose rather than treating every test case as a mandatory long template.

Test documentation is broader than test cases; know the artifacts and the decision or reproducibility need each one serves.

Before declaring a product defect, verify that build, configuration, dependency, or data drift is not explaining the observation.

Criteria should trigger real decisions about whether testing can start, continue, stop, or be considered sufficiently complete.

These industry labels are not universally standardized, so explain the purpose you use rather than arguing about one absolute definition.

Coverage tells you which implementation structure was exercised; it does not prove that assertions, requirements, or test data are good.

After a change, confirmation proves the reported failure is fixed; regression looks for unintended side effects elsewhere.

Severity describes impact; priority describes when the organization chooses to address the issue.

Optimize a defect report for reproduction, diagnosis, and impact assessment rather than form completion.

Know the normal state flow but emphasize that exact statuses depend on the workflow; what matters is ownership and a verifiable resolution path.

These labels overlap in real projects, so distinguish the test level, the stakeholder purpose, and who performs the testing.

Start with the decision or question, then choose a metric; raw counts without denominator, scope, or context are easy to misuse.

A release decision is a risk decision supported by evidence; pass percentage alone is not a sufficient release argument.

A useful Root Cause Analysis goes beyond developer made a mistake and identifies what allowed the defect to be introduced and escape.

Static and dynamic describe whether the test object is executed, not a test level or a quality characteristic.