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.