QAI CAST flashcards
QAI CAST · Build recall with a focused review session.
31 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Verification
- Confirmation that a work product meets its specified requirements, answering whether the product was built correctly. It relies on reviews, inspections, and static analysis rather than executing code.
- Validation
- Confirmation that the delivered product meets the user's actual needs in its intended environment. It answers whether the right product was built and typically involves acceptance and operational testing.
- Defect clustering
- A test principle stating that a small number of modules usually contain the majority of defects. Effort is therefore concentrated on those modules, guided by defect history and complexity analysis.
- Pesticide paradox
- A test principle noting that repeating the same tests eventually stops finding new defects. Test cases and data must be periodically reviewed and updated to remain effective.
- Exhaustive testing impossible
- A test principle stating that testing every input and precondition combination is infeasible except in trivial cases. Risk analysis and prioritization are used instead to select a practical subset.
- Failure versus defect
- A defect is a flaw in a work product; a failure is the observable incorrect behavior during execution. A defect may exist for years without producing a failure if the faulty path is never executed.
- Static testing
- Testing that does not execute the software. It includes reviews, walkthroughs, inspections, and static analysis tools that detect issues in code, requirements, and design documents.
- Regression testing
- Retesting unchanged areas after a change to confirm nothing previously working has broken. It is usually automated and scoped using change impact analysis to control cost.
- Entry and exit criteria
- Preconditions that must hold before a test level starts, and conditions that must be met before it is declared complete. Typical exit criteria include execution and pass-rate thresholds.
- Equivalence partitioning
- A black-box technique that divides input data into classes expected to be processed identically. One representative value per valid and invalid class is selected, reducing the number of cases.
- Boundary value analysis
- A technique targeting the edges of ordered equivalence classes, where defects concentrate. For a range of 1 to 100, tests include 1, 2, 99, 100, 0, and 101.
- Decision table testing
- A technique that tabulates combinations of conditions and their expected actions. With n binary conditions there are up to 2^n rule columns, which can be collapsed when actions are identical.
- State transition testing
- A technique modeling states, events, guards, and actions. Coverage levels range from all-states to all-transitions (0-switch) to n-switch, with invalid transitions tested explicitly.
- Risk-based testing
- Prioritizing test effort by risk, calculated as likelihood multiplied by impact. High-risk items are tested earlier, more deeply, and more often than low-risk items.
- Branch coverage
- The proportion of decision outcomes exercised by tests. One hundred percent branch coverage guarantees one hundred percent statement coverage, but the reverse implication does not hold.
- Exploratory testing
- An experience-based approach where design, execution, and learning happen simultaneously. Testers use charters and session-based time boxes rather than pre-scripted cases.
- Severity versus priority
- Severity measures the impact of a defect on the system; priority measures how urgently the business wants it fixed. They are assigned independently, so a cosmetic defect can still be high priority.
- Defect life cycle
- The states a defect passes through: New, Assigned, In Progress, Fixed, Retest, Verified, Closed, plus Reopened, Deferred, Duplicate, Rejected, and Cannot Reproduce.
- Deferred defect
- A valid defect whose fix is postponed to a later release. It is recorded with a rationale and reviewed against release risk rather than discarded.
- Rejected defect
- A reported issue that is not accepted as a defect, for example because it works as designed, duplicates another report, or stems from a test environment problem.
- Retest versus regression
- Retesting runs the failing case against a fix to confirm resolution. Regression testing reruns broader suites to confirm the fix did not break other functionality.
- Defect report content
- A defect record includes a unique identifier, title, build and environment, preconditions, reproducible steps, expected and actual results, severity, priority, status, and supporting evidence.
- Defect density
- The number of defects divided by a size measure such as thousands of lines of code, function points, or requirements. It enables comparison across modules and releases.
- Defect detection percentage
- Defects found in testing divided by all defects found in testing plus those found after release, times one hundred. Higher values indicate more effective pre-release testing.
- Defect leakage
- Defects found after release divided by total defects reported, times one hundred. It is the complement view of detection percentage and highlights gaps in test coverage.
- Test execution progress
- Executed tests divided by planned tests, expressed as a percentage. It is usually reported alongside pass rate and defect trend to avoid a misleading picture.
- Requirements coverage
- The percentage of requirements traced to at least one test case. A traceability matrix is the standard evidence, and uncovered requirements are flagged as risk.
- Statement coverage
- The proportion of executable statements run by the test suite. It is the weakest structural coverage measure, since it ignores whether decision outcomes were both exercised.
- Automation pyramid
- A test strategy with many fast unit tests, fewer service or API tests, and few brittle UI tests. The shape keeps feedback fast and maintenance cost low.
- Flaky test
- A test that passes and fails on unchanged code. Common causes are timing and synchronization issues, shared state, order dependence, and unstable test data.
- Data-driven framework
- An automation design where test logic is separated from data, which is stored externally in files or databases. Adding cases requires new data rows rather than new scripts.