NCT Tester Competence Assessment study materials
NCT Tester Competence Assessment study resources

NCT Tester Competence Assessment flashcards

NCT Tester Competence Assessment · Build recall with a focused review session.

32 cards. Read the term and the definition here. The deck at the top of this page is optional.

Error, defect, failure
An error is a human mistake, a defect is the resulting flaw in a work product, and a failure is the observable incorrect behavior when the flawed software executes.
Verification versus validation
Verification checks that the product conforms to its specified requirements and design; validation checks that it fulfills the intended user needs and purpose in its real context.
Exhaustive testing principle
Testing every possible input and precondition combination is infeasible except for trivial software, so testers use risk and technique-based selection to reduce residual risk rather than prove absence of defects.
Defect clustering
A small number of modules usually contain most defects, so defect density analysis directs test effort toward the highest-risk components instead of spreading it uniformly.
Testware
The artifacts produced during testing, including test plans, test cases, test data, scripts, expected results, and reports, all traceable to requirements and defects.
Component testing
Testing individual units in isolation, usually by developers using white-box techniques, with stubs and drivers replacing components that are not yet available.
Integration testing strategies
Big-bang tests all components together at once; top-down uses stubs for lower levels; bottom-up uses drivers for higher levels; sandwich combines both approaches.
Confirmation versus regression testing
Confirmation testing re-runs a failed test to verify a specific defect is fixed; regression testing re-runs broader tests to confirm that changes did not break unchanged functionality.
V-model
A sequential lifecycle model in which each development phase is paired with a corresponding test level: component, integration, system, and acceptance testing, planned in parallel with design.
Shift-left and shift-right
Shift-left moves testing earlier through reviews, static analysis, and unit tests; shift-right extends testing into production using monitoring, canary releases, and chaos experiments.
Acceptance testing forms
User acceptance, operational acceptance, contractual and regulatory acceptance, plus alpha testing at the developer site and beta testing at customer sites, all confirm fitness for use.
Static analysis
Tool-based examination of source code or models without execution, detecting unreachable code, uninitialized variables, standards violations, security weaknesses, and excessive complexity.
Technical review versus inspection
A technical review is a documented peer examination led by a moderator; an inspection is the most formal review, with defined roles, entry and exit criteria, and recorded metrics.
Formal review roles
Manager selects and allocates; moderator plans and leads; author creates the work product; reviewers inspect it; scribe records findings and decisions during the meeting.
Review process stages
Planning, kick-off, individual preparation, review meeting, rework, and follow-up; entry criteria must be satisfied before preparation begins and exit criteria before closure.
Equivalence partitioning
Dividing inputs into classes expected to behave identically, then testing one representative value per valid class and one per invalid class to reduce redundant test cases.
Boundary value analysis
Testing values at, just below, and just above class boundaries; three-value analysis adds the adjacent interior value, while two-value analysis tests only the boundary and its neighbor.
Decision table coverage
A table of condition combinations and resulting actions; with n conditions there are 2^n rules, and full coverage needs at least one test per rule or collapsed rule.
State transition coverage
Modeling states, events, guards, and transitions; all-states coverage visits every state, all-transitions coverage takes every transition, and switch coverage tests transition sequences.
Statement versus branch coverage
Statement coverage executes every statement at least once; branch coverage executes every decision outcome at least once, and branch coverage subsumes statement coverage.
MC/DC coverage
Modified condition/decision coverage requires each atomic condition to independently change the decision outcome while other conditions are held fixed, giving strong safety-critical test assurance.
Cyclomatic complexity
V(G) = E - N + 2P for edges, nodes, and connected components; it equals the number of independent paths plus one and the minimum tests for branch coverage.
Exploratory testing
Simultaneous learning, test design, and execution guided by charters and time-boxed sessions, relying on tester skill and recorded session notes rather than pre-scripted cases.
Entry and exit criteria
Entry criteria define prerequisites for starting a test level, such as available test basis and environment; exit criteria define conditions for completion, such as coverage and defect thresholds.
Three-point PERT estimate
Expected effort = (optimistic + 4 x most likely + pessimistic) / 6, used to express uncertainty in test estimation and to weigh the most probable outcome.
Test progress metrics
Measures such as test execution rate, pass and fail percentages, defect discovery rate, defect density, and requirement coverage used to monitor progress and trigger control actions.
Severity versus priority
Severity is the technical impact of a defect on the system; priority is the business urgency of fixing it, and the two can differ, as with a low-severity but high-priority branding error.
Defect lifecycle states
Typical transitions are New, Assigned or Open, Fixed or Resolved, Retest, and Closed, with alternative outcomes Reopened, Deferred, Rejected, and Duplicate.
Risk exposure formula
Risk level equals likelihood of occurrence multiplied by impact; test effort is allocated in proportion to risk exposure so high-risk areas are tested first and most thoroughly.
Product versus project risk
Product risks concern quality attributes of the software such as security or performance; project risks concern delivery factors such as schedule slippage, staff turnover, or environment unavailability.
Test automation pyramid
A layered strategy with many fast unit tests, fewer service or API tests, and few slow brittle UI tests, balancing execution speed against maintenance cost.
Professional conduct in reporting
Testers report defects and risks factually and neutrally, avoid suppressing findings to please stakeholders, respect confidentiality, and escalate blockers early with documented impact.