NCT Tester Competence Assessment cheat sheet

Error (mistake) is a human action producing an incorrect result; defect (bug, fault) is the resulting flaw in a work product; failure is the observable deviation of running software from expected behavior or specification.

Root cause analysis traces a failure back through the defect to the originating error; fixing only the symptom leaves the defect latent and able to cause further failures.

Testing shows the presence of defects, not their absence: exhaustive testing is infeasible except for trivial cases, so testing reduces residual risk rather than proving correctness.

Verification asks 'are we building the product right' against specifications and design; validation asks 'are we building the right product' against user needs and intended use.

The seven ISTQB Foundation testing principles: testing shows presence of defects; exhaustive testing is impossible; early testing saves time and money; defect clustering; pesticide paradox; testing is context dependent; absence-of-errors fallacy.

Defect clustering (Pareto principle) means a small number of modules typically contain the majority of defects; defect density = defects found / size (KLOC or function points).

Pesticide paradox: repeating the same tests stops finding new defects, so test cases must be regularly reviewed and updated; the absence-of-errors fallacy means bug-free software that misses user needs still fails.

Testware includes test plans, test cases, test data, test scripts, expected results, and test reports; traceability links testware to requirements and to defects.

Quality attributes split into functional (what it does) and non-functional (how well: performance, security, usability, reliability); testing addresses both.

Component (unit) testing: tests individual components in isolation, often with stubs and drivers, typically by developers using white-box techniques.

Integration testing: tests interfaces and interactions between components or systems; strategies include big-bang, top-down (stubs), bottom-up (drivers), and sandwich/hybrid.

System testing: tests the complete integrated system against specified requirements, including functional and non-functional types, usually by an independent test team.

Acceptance testing: confirms fitness for use; forms include user acceptance (UAT), operational acceptance, contractual and regulatory acceptance, and alpha/beta testing.

Test types are grouped as functional (features and business rules), non-functional (performance, load, stress, security, usability, portability, maintainability), and structural/white-box (code, architecture, data flow).

Confirmation testing (re-testing) checks that a specific defect is fixed; regression testing checks that changes have not broken unchanged areas - they answer different questions.

SDLC models: waterfall (sequential, late feedback), V-model (each development level paired with a test level), iterative/incremental, and agile (short sprints, continuous testing, test automation, shift-left).

Shift-left moves testing earlier (static analysis, reviews, unit tests); shift-right extends testing into production (monitoring, canary releases, A/B testing, chaos engineering).

Maintenance testing is triggered by changes (corrective, adaptive, perfective, preventive) and by retirement/migration; impact analysis determines the regression scope.

Static testing examines work products (requirements, design, code, testware) without executing them; it finds defects earlier and cheaper than dynamic testing.

Static analysis tools detect code smells, unreachable code, uninitialized variables, violations of coding standards, security weaknesses, and complexity metrics.

Review types by formality: informal review, walkthrough (author-led, knowledge sharing), technical review (peer, documented, led by a moderator), and inspection (most formal, defined roles and entry/exit criteria).

Formal inspection roles: manager, moderator, author, reviewer/inspector, and scribe/recorder; the moderator plans and leads, the scribe records findings.

A formal review process: planning, kick-off, individual preparation, review meeting, rework, and follow-up; entry criteria must be met before the review starts.

Success factors for reviews: clear objectives, small reviewable chunks (typically a few pages or a few hundred lines of code), defined roles, checklists, training, and management support.

Reviews find defects and improve quality but are not a substitute for dynamic testing; they cannot verify runtime behavior, performance, or environment-specific issues.

A review checklist is a list of common defect patterns used during preparation; it improves consistency and focuses reviewers on high-yield areas.

Equivalence partitioning divides inputs into classes where all members are expected to behave the same; one test per valid class and one per invalid class minimizes redundancy.

Boundary value analysis tests values at, just below, and just above class boundaries; for two-value BVA test the boundary and its neighbor, for three-value BVA also test the adjacent value inside the class.

Decision tables capture combinations of conditions and actions; the number of rules is 2^n for n conditions, and full coverage requires at least one test per rule (or per collapsed rule).

State transition testing models states, events, transitions, and guards; coverage levels include all states, all transitions (0-switch), and sequences (1-switch and higher).

Use case testing derives tests from actor-system interactions and covers basic flows and alternative/exception flows; it is strong for end-to-end business scenarios.

Pairwise (all-pairs) testing covers every pair of parameter values at least once, reducing the combinatorial explosion of full Cartesian product testing.

Statement coverage requires every executable statement to run at least once; branch (decision) coverage requires every decision outcome to be taken at least once, and branch coverage subsumes statement coverage.

Condition coverage requires each atomic condition to be true and false; MC/DC requires each condition to independently affect the decision outcome, and it is weaker than multiple-condition coverage but stronger than branch coverage.

Path testing requires all paths through the control flow graph; the cyclomatic complexity V(G) = E - N + 2P (edges, nodes, connected components) equals the number of independent paths plus one and the minimum number of tests for branch coverage.

Experience-based techniques: error guessing (using defect history), exploratory testing (simultaneous learning, design, and execution with charters and session-based time boxes), and checklist-based testing.

A test plan defines scope, objectives, approach, entry and exit criteria, resources, schedule, risks, deliverables, and environment needs; it is a living document updated as conditions change.

Entry criteria (test basis available, environment ready, testware complete) and exit criteria (planned tests executed, coverage reached, defect thresholds met) gate the start and end of test execution.

Estimation techniques: expert judgment, analogy (based on similar past projects), work breakdown structure, and metrics-based (test effort per requirement, per test case, or per KLOC/function point).

The three-point (PERT) estimate: expected effort = (optimistic + 4 x most likely + pessimistic) / 6; use it to express uncertainty in estimates.

Test progress monitoring uses metrics such as test case execution rate, pass/fail percentages, defect discovery rate, defect density, and requirement coverage; control actions include re-prioritizing tests and adjusting scope.

A test summary report communicates results, deviations from plan, defect status, residual risk, and a recommendation (release, hold, or conditional release).

Risk-based test prioritization orders tests by risk exposure = likelihood x impact; high-exposure areas are tested first and most deeply.

Test effort typically follows a curve: planning and design early, execution peaking in the middle, and closure at the end; monitoring should compare actuals against this planned profile.

A defect report contains a unique ID, title, environment, preconditions, steps to reproduce, expected versus actual result, severity, priority, status, and evidence (logs or screenshots).

Severity is the technical impact on the system (e.g., crash, data loss); priority is the business urgency of the fix. They are independent and can differ (a cosmetic logo error on the home page may be low severity but high priority).

Defect lifecycle: New -> Assigned/Open -> Fixed/Resolved -> Retest -> Closed; other transitions include Reopened, Deferred, Rejected (not a defect, duplicate, or by design), and Verified.

Defect classification supports analysis: by phase injected, by component, by type (functional, interface, data, performance), and by root cause; trends guide process improvement.

Risk is defined as probability of occurrence x impact; risk level = likelihood x consequence, and risk-based testing allocates effort in proportion to risk exposure.

Risk identification sources include requirements analysis, technical reviews, defect history, project constraints, and stakeholder workshops; each risk gets a likelihood, an impact, and a mitigation or contingency.

Product risks (quality attributes such as poor performance or security flaws) differ from project risks (schedule slippage, staff turnover, environment unavailability).

Risk mitigation options: test more deeply, add reviews, prototype, add contingency time, or accept the residual risk with documented sign-off.

Tool categories: test management, static analysis, test design and data preparation, test execution and coverage, performance/load, and defect management; selection depends on needs, cost, fit, and support.

Test automation benefits: repeatability, speed, regression coverage, and objective results; costs include tooling, script development, maintenance, and skills; ROI requires frequent, stable, repeatable tests.

The test automation pyramid favors many fast unit tests, fewer service/API tests, and few slow UI tests; UI-heavy suites are brittle and expensive to maintain.

A test harness comprises the test scripts, test data, stubs, drivers, and configuration needed to execute tests; a test oracle determines whether an observed result is correct.

Test environment components: hardware, operating system, network, databases, third-party services, test data, and configuration; environments should mirror production closely enough to be representative.

Environment management practices: version control of configuration, environment booking and scheduling, data masking/anonymization, refresh from production, and isolation between teams.

Test data management: generate, subset, mask, and reset data; data must be realistic, cover boundary cases, and be reproducible for regression runs.

Automation maintenance risks include brittle locators, hard-coded data, and coupled tests; use stable selectors, independent tests, and version-controlled scripts.

Tool adoption requires a pilot, training, and a defined process for script review and retirement; unused or unsupported tools become technical debt.

The ISTQB Code of Ethics: public interest, client and employer, product and standards, judgment, management, and profession; testers should act with integrity and avoid conflicts of interest.

Testers must report findings objectively and not suppress or soften defects to please stakeholders; independence of testing supports credibility.

Communicate defects factually and neutrally: describe observed behavior and expected behavior, avoid blaming individuals, and focus on the product.

Escalate blockers (environment unavailable, missing test basis, schedule risk) early and in writing to the responsible owner with impact and options.

Written communication should be concise, structured, and audience-appropriate: executives need risk and status, developers need reproducible detail.

Confidentiality: test data, defects, and security findings may be sensitive; share only with authorized parties and follow data protection rules.

Conflict handling: separate the person from the problem, gather facts, agree on criteria, and escalate only when facts and criteria cannot resolve the disagreement.

Continuous professional development: keep current with techniques, tools, and standards, and share knowledge through reviews, mentoring, and communities.