ISTQB CTFL study guide

40 questions, 40 points, 60 minutes. You need 26 points, which is 65%. If you are sitting in a language that is not your native or working language you may be entitled to 75 minutes. There is no negative marking, so never leave a question blank.

No prerequisites. ISTQB recommends around six months of practical testing experience, but it is not required and plenty of people pass without it. The certification does not expire and there is no recertification cycle.

Every learning objective carries a cognitive level. ISTQB publishes how many questions come from each, and the timing they allow.

Add that up and the paper is designed to take 56 minutes of the 60 available. That is the tightest margin of any exam in this catalog, and it is why the eight K3 questions matter out of proportion to their count: each one is budgeted three minutes, and if a technique is not automatic you will spend five.

The eight K3 questions live only in chapter 4 (five of them) and chapter 5 (three). They are equivalence partitioning, boundary value analysis, decision tables, state transition testing, statement and branch coverage, and test estimation. Those six things are what to drill until they are mechanical.

ISTQB publishes the per-chapter counts, so this is not an estimate.

Chapters 4 and 5 are half the paper between them and hold all eight K3 questions. Chapter 6 is two questions, which is worth knowing before you spend an evening on tool categories.

Testing is more than executing software. It includes planning, analysis, design, implementation, reporting and completion. A common misconception the exam attacks directly is that testing equals running tests.

Testing is not debugging. Testing finds failures. Debugging is the development activity of finding the defect that caused a failure, fixing it, and confirming the fix. Testers test; developers debug. The exam checks this distinction.

The chain runs error causes defect causes failure. Not every defect causes a failure: some sit on paths never taken. And failures can also be caused by environmental conditions rather than defects. A root cause is the earliest action or condition that led to the defect.

Learn these by name and by what they imply. Questions usually describe a situation and ask which principle it illustrates.

The test process is not fixed, but these activities are named and examinable:

Analysis versus design is a favorite question. Analysis produces test conditions (what). Design produces test cases (how).

Testware is the work products of these activities: test plans, test conditions, test cases, test data, test procedures, test scripts, test results, test logs and test reports. Traceability between the test basis and testware is what lets you assess coverage, analyze impact, and report meaningfully.

Version 4 names two roles rather than job titles: the test management role, which owns the overall test process and leadership, and the testing role, which owns the engineering work. One person may hold both.

Essential skills include testing knowledge, thoroughness and attention to detail, good communication, analytical and critical thinking, plus domain and technical knowledge. Communication matters because defect reports are criticism, and being right is not the same as being heard.

The whole team approach means anyone on a cross-functional team can do testing. Independence of testing ranges from developers testing their own work (fastest, most biased) through to testers from a different organization (least biased, slowest and most distant). Independence tends to find different defects; it does not replace developer testing.

Acceptance testing has named forms worth knowing: user acceptance, operational acceptance, contractual and regulatory acceptance, and alpha and beta. Alpha happens at the developing organization's site; beta happens at the customer's.

Test levels and test types are independent dimensions: you can do non-functional testing at component level, and functional testing at acceptance level. The exam tests that they are not a hierarchy.

Testing changes to a system already in operation. The three named triggers are modification (enhancements, fixes, patches), migration (to a new platform, including data conversion), and retirement (archiving, data migration out, checking restore procedures).

Scope depends on the size and risk of the change, the size of the system, and whether an impact analysis was possible. Poor documentation makes impact analysis hard, which widens the regression scope.

Examining work products without executing the code. It has two forms: reviews, done by people, and static analysis, done by tools.

Almost any readable work product can be statically tested: requirements, user stories and acceptance criteria, design documents, code, test plans and test cases, contracts, models. If a human or a tool can read it, static testing can examine it.

Reviews succeed when objectives are clear, the right people are involved, the work product is a manageable size, participants have enough time to prepare, defects are welcomed and expressed objectively, and the review is not used to evaluate the participants. That last point is the one most often tested: a review that becomes a performance appraisal stops finding defects, because people stop raising them.

Divide the input data into groups where all members should be handled the same way, then test one value from each group. The assumption is that if one value in a partition works, they all do.

Partitions are valid (should be accepted) and invalid (should be rejected). Coverage is the proportion of partitions exercised. A rule the exam applies: test one invalid partition at a time, so one rejection does not mask another.

Example. A field accepts 18 to 65. Partitions: below 18 (invalid), 18 to 65 (valid), above 65 (invalid). Three tests, one per partition.

An extension of partitioning: defects cluster at the edges, so test the boundaries. Only applies where a partition is ordered, such as numbers or dates.

Know both forms and which values each produces. Questions frequently ask for the exact set of values, which is why this must be automatic rather than reasoned out.

For systems where the outcome depends on combinations of conditions. Rows are conditions and actions; columns are rules, each a combination.

A full table with n binary conditions has 2 to the power of n rules: three conditions gives eight columns. Minimum coverage is one test per rule, meaning per column. Tables can be collapsed where some conditions do not affect the outcome, marked as "don't care".

For systems whose response depends on current state and history. A state transition diagram or table shows states, events, transitions and actions.

Coverage levels the exam uses: all states (visit every state), all transitions or 0-switch (exercise every valid transition), and higher n-switch coverage for sequences. All-transitions coverage is the usual minimum, and it subsumes all-states coverage. A state table also exposes invalid transitions, which is where interesting defects hide.

Statement coverage is the percentage of executable statements exercised. Branch coverage is the percentage of branches, meaning the outcomes of decisions, exercised.

The relationship is the examinable point: 100% branch coverage guarantees 100% statement coverage, but not the reverse. A single test through an if-without-else can hit every statement while never taking the false branch. Neither level guarantees the code does the right thing; both only prove what was executed.

Acceptance test-driven development (ATDD) creates acceptance tests from acceptance criteria before implementation, collaboratively across roles, so the tests define what "done" means.

User stories follow the pattern of role, goal and benefit, and are elaborated through the three Cs: card, conversation, confirmation. Good stories meet INVEST: independent, negotiable, valuable, estimable, small, testable. Acceptance criteria are what make a story testable, and the tester's job at refinement is often to notice that they are not.

A test plan documents objectives, scope, approach, resources, schedule, risks and the criteria for starting and stopping. Writing it clarifies the work; maintaining it keeps it useful.

Entry criteria define what must be in place before testing starts; in Agile terms, the definition of ready. Exit criteria define when testing can stop; the definition of done. Running out of time or budget is not a legitimate exit criterion, though the syllabus acknowledges it happens in practice.

The test pyramid says have many fast, cheap, low-level tests (unit), fewer at the integration level, and fewest slow expensive end-to-end tests at the top. An inverted pyramid, mostly UI tests, is slow and brittle.

The testing quadrants group tests along two axes: business-facing versus technology-facing, and supporting the team versus critiquing the product. It is a way of checking you have not left a whole category of testing out.

A risk is a potential event with negative consequences. Risk level = likelihood × impact, and that product is what drives prioritization.

Product risk analysis identifies and assesses risks so that test effort goes where it matters, and it can influence the depth of testing, the techniques chosen, and the order tests run in. Risk control is the response: mitigate, transfer, accept, or plan a contingency.

Ensures every item of testware is identified, version controlled, tracked for changes, and related to other items and to the versions of the software it tests. Without it, you cannot say which version a result applies to, which makes the result close to worthless. This is why the syllabus places it inside test management rather than treating it as an IT concern.

A defect report exists to give developers enough to reproduce and fix, to let managers judge impact, and to provide data for improvement. Contents include an identifier, title and summary, date and author, the version tested, the environment, steps to reproduce, expected and actual results, severity, priority, status, and references to the test case or requirement.

Severity versus priority is the classic exam pair. Severity is how bad the effect is on the system. Priority is how urgently it should be fixed. A cosmetic typo in the company name on the home page is low severity and high priority. A crash in a feature nobody uses until next year is high severity and low priority.