SaveMyCert
Log in
5 of 5 free questions left today·for 30 a day
CTFL · Domain 1

Fundamentals of Testing practice questions

Fundamentals of Testing is worth 20% of the CTFL exam — the 3rd-heaviest of the 6 domains. What testing is and why it matters: test objectives, testing vs debugging, errors/defects/failures, the seven principles, test activities, testware and roles, and essential tester skills. Official share: 8 of 40 exam questions. 6 fully worked examples are further down this page, answers included.

Exam weight
20%
the 3rd-heaviest of the 6 domains
Questions
129
across 5 topics
Free, no account
5/day
a free account allows 30 a day
Explanations
Every option
right and wrong

Build a practice session

5 free questions left today.

Domains

How many?

Mode

Ready when you are

10 fresh questions drawn across 1 of 6 domains, in Learn mode.

Focused review

Every question you answer incorrectly, and every question you flag while practising, is saved here automatically. Finish a session and you can come back to re-drill just those.

6 sample Fundamentals of Testing questions, fully explained

Questions from the CTFL bank mapped to domain 1, with the answer key and the reasoning behind every option. None of them repeat the examples on the main CTFL practice page.

Question 1Fundamentals of Testing

A project manager says: "Testing starts when the first build is installed and the first test case is executed." Which statement CORRECTLY assesses this view?

Choose one.

  • a
    It is a misconception, as testing also covers examining work products such as requirements without execution Correct

    Static testing, such as reviewing requirements or user stories, is testing even though nothing is executed, and it can start long before a build exists.

  • b
    It is correct for testing, as examining requirements without execution is a quality assurance activity instead

    Reviews and static analysis are static testing, which is part of testing. Quality assurance concerns the process, not examining work products.

  • c
    It is correct, as a defect in a work product can be found by a test once the software fails in execution

    Static testing finds defects directly in work products without any failure. Waiting for execution is not the only way to find defects.

  • d
    It is a misconception, as testing starts when developers begin debugging the first units of the code

    Debugging is not testing. It is the activity of finding and removing the causes of failures after testing has revealed them.

The concept

Testing includes both dynamic testing (with execution) and static testing (without execution).

Why that’s the answer

The manager equates testing with executing test cases. The syllabus calls this a common misconception: testing also includes static testing, such as reviews of requirements, user stories and code, which needs no execution. The tempting distractor reclassifies reviews as quality assurance, but quality assurance is about the process, while reviewing a work product is testing.

How to reason it out
  1. Identify the claim: testing equals running test cases on a build.
  2. Recall that static testing is part of testing and needs no execution.
  3. Check whether reviews of work products are testing or quality assurance: they are static testing.
  4. Reject the option that confuses debugging with testing.

Exam tip: Reviewing a requirement is testing too: static testing needs no execution.

What Is Testing? CTFL Test Objectives and Testing vs Debugging — the lesson that teaches this.

Question 2Fundamentals of Testing

Which of the following statements about software testing is TRUE?

Choose one.

  • a
    Testing is complete once every planned test case has been executed and has passed

    Passing the planned tests does not mean testing is complete. Testing also evaluates quality and covers more than test execution.

  • b
    Testing is a technical activity performed by developers while they write the code

    Testing is not limited to developers or coding time, and it is not purely technical: it also has to be planned and managed.

  • c
    Testing can find defects in a requirements document before any code has been written Correct

    The test object can be any work product. Static testing of a requirements document finds defects before coding starts.

  • d
    Testing proves that the software is free of defects once its test results are positive

    Testing can show that defects are present but cannot prove their absence; it reduces the probability of undiscovered defects.

The concept

Testing evaluates software work products, not only executable code.

Why that’s the answer

The definition of testing covers software artifacts in general, so a requirements document is a valid test object for static testing. Passed test cases do not end testing, testing is not a developer-only coding activity, and no amount of passed tests proves defect-free software.

How to reason it out
  1. Recall that the test object can be any software work product.
  2. Check each statement against the definition: discover defects and evaluate quality.
  3. Reject statements that equate testing with executing passed test cases or claim proof of correctness.

Exam tip: A requirements document can be tested: testing is not limited to code.

What Is Testing? CTFL Test Objectives and Testing vs Debugging — the lesson that teaches this.

Question 3Fundamentals of Testing

Which of the following is an example of static testing?

Choose one.

  • a
    Running an automated suite of unit tests against each new build of the component

    Running unit tests executes the component, so this is dynamic testing.

  • b
    Exploring the checkout screen of a web shop to look for unexpected system behavior

    Exploratory testing of a running screen executes the software, so it is dynamic testing.

  • c
    Reviewing a user story to check that its acceptance criteria are clear and testable Correct

    A review examines a work product without executing anything, which is what makes it static testing.

  • d
    Measuring the response times of a service while it is placed under a simulated load

    Load testing runs the service and measures its behavior, so it is dynamic testing.

The concept

Static testing does not involve executing the software being tested; it includes reviews and static analysis.

Why that’s the answer

The deciding point is whether the test object is executed. A user story review examines the work product directly and executes nothing, so it is static testing. Unit test runs, exploratory sessions and load measurements all execute the software and are dynamic testing.

How to reason it out
  1. Ask for each option: is the software being executed?
  2. Classify execution-based activities as dynamic testing.
  3. Pick the activity that examines a work product without execution.

Exam tip: No execution = static testing; execution = dynamic testing.

What Is Testing? CTFL Test Objectives and Testing vs Debugging — the lesson that teaches this.

Question 4Fundamentals of Testing

A static analysis tool processes source code and reports a variable that is read before it is assigned a value. Which statement describes this activity?

Choose one.

  • a
    This is dynamic testing, as the tool processes the code in order to produce its report

    Processing code with a tool is not executing the test object. Dynamic testing requires the software under test to run.

  • b
    This is static testing, which has found a defect directly without executing the code Correct

    Static analysis examines the code without running it, so it finds the defect itself rather than a failure.

  • c
    This is debugging, as the tool points to the line of code that contains the defect

    Debugging finds the causes of failures and removes them. Detecting the defect is testing; the later fix is debugging.

  • d
    This is a failure, which is reproduced by running the code before the defect is fixed

    Nothing was executed, so there is no failure. Static testing finds defects directly and needs no reproduction.

The concept

Static testing, including static analysis, finds defects directly in the test object without executing it.

Why that’s the answer

Static analysis is a form of static testing: the tool reads the code, but the code under test never runs. That is why its output is a defect, not a failure. A failure is an event observed during execution. Pointing at the faulty line does not make it debugging, which is the developer activity of analyzing and removing causes.

How to reason it out
  1. Check whether the test object was executed: it was not.
  2. Classify the activity as static testing.
  3. Recall that static testing reports defects, not failures.
  4. Reject the options that call it dynamic testing, debugging or a failure.

Exam tip: Static analysis is testing that finds defects, not failures, because nothing runs.

What Is Testing? CTFL Test Objectives and Testing vs Debugging — the lesson that teaches this.

Question 5Fundamentals of Testing

Which of the following activities is an example of validation rather than verification?

Choose one.

  • a
    Checking that the system meets the requirements written in its requirements specification

    Checking against specified requirements is verification.

  • b
    Checking that the design document is consistent with the approved system requirements

    Checking a design against approved requirements is verification of that work product.

  • c
    Checking with end users that the system meets their needs in its operational environment Correct

    Validation checks that the system meets users' and other stakeholders' needs in its operational environment.

  • d
    Checking that the code implements the interfaces defined in the technical design document

    Checking code against its specification (the design) is verification.

The concept

Verification checks against specified requirements; validation checks against stakeholder needs in the operational environment.

Why that’s the answer

Testing involves both verification and validation. Three options compare a work product with a specification (requirements, approved requirements, design), which is verification. Only checking with end users that the system meets their needs where it will be used is validation.

How to reason it out
  1. Recall the two definitions: specification versus stakeholder needs.
  2. Classify each option by what the work product is compared with.
  3. Pick the one that compares the system with users' real needs.

Exam tip: Verification: built it right (to spec). Validation: built the right thing (for stakeholders).

What Is Testing? CTFL Test Objectives and Testing vs Debugging — the lesson that teaches this.

Question 6Fundamentals of Testing

A system passes every test derived from its specification. In acceptance testing, users report that the order workflow does not match how they actually process orders. What does this show?

Choose one.

  • a
    Validation found no problem, while verification found that the system does not meet its specified requirements

    This swaps the two. The specification-based tests all passed, so verification found no problem.

  • b
    Verification found no problem, while validation found that the system does not meet stakeholder needs Correct

    Tests derived from the specification verify; the users' feedback in their real workflow is validation, and it found a mismatch with their needs.

  • c
    Verification and validation both passed, and the user feedback is a change request outside the scope of testing

    Checking that the system meets user needs is validation, which is part of testing. The feedback is a validation finding.

  • d
    Verification and validation were both missed, as tests derived from a specification do not reveal user needs

    Verification did take place: tests derived from the specification check it. Validation then happened in acceptance testing.

The concept

Testing involves both verification and validation, and the two can give different results.

Why that’s the answer

Passing specification-based tests shows the system meets its specified requirements, which is verification. Users trying it in their real workflow is validation, and that found the system does not meet their needs. The specification itself probably did not capture those needs, which is why validation matters even when verification passes.

How to reason it out
  1. Map the specification-based tests to verification.
  2. Map the users' feedback on their real workflow to validation.
  3. Read each result: verification passed, validation found a gap.

Exam tip: A system can pass verification and still fail validation if the specification misses real needs.

What Is Testing? CTFL Test Objectives and Testing vs Debugging — the lesson that teaches this.

What CTFL domain 1 tests, topic by topic

The official exam guide breaks Fundamentals of Testing into 5 topics. The question bank follows the same split, so a weak topic shows up as a cluster of misses you can go back and read.

Published CTFL practice questions per topic in Fundamentals of Testing
TopicWhat it coversQuestions
What is Testing?Official CTFL v4.0.1 syllabus section 1.1. Learning objectives: FL-1.1.1 (K1) Identify typical test objectives; FL-1.1.2 (K2) Differentiate testing from debugging.26
Why is Testing Necessary?Official CTFL v4.0.1 syllabus section 1.2. Learning objectives: FL-1.2.1 (K2) Exemplify why testing is necessary; FL-1.2.2 (K1) Recall the relation between testing and quality assurance; FL-1.2.3 (K2) Distinguish between root cause, error, defect, and failure.26
Testing PrinciplesOfficial CTFL v4.0.1 syllabus section 1.3. Learning objectives: FL-1.3.1 (K2) Explain the seven testing principles.26
Test Activities, Testware and Test RolesOfficial CTFL v4.0.1 syllabus section 1.4. Learning objectives: FL-1.4.1 (K2) Explain the different test activities and related tasks; FL-1.4.2 (K2) Explain the impact of context on the test process; FL-1.4.3 (K2) Differentiate the testware that supports the test activities; FL-1.4.4 (K2) Explain the value of maintaining traceability; FL-1.4.5 (K2) Compare the different roles in testing.25
Essential Skills and Good Practices in TestingOfficial CTFL v4.0.1 syllabus section 1.5. Learning objectives: FL-1.5.1 (K2) Give examples of the generic skills required for testing; FL-1.5.2 (K1) Recall the advantages of the whole team approach; FL-1.5.3 (K2) Distinguish the benefits and drawbacks of independence of testing.26
Total129

Revise Fundamentals of Testing before you drill it

What Is Testing? CTFL Test Objectives and Testing vs DebuggingQuestions on this topic are mostly short recall and classification items. Expect to pick the statement that BEST describes testing, to spot which goal in a list is or is NOT a typical test objective, and to classify an activity as static or dynamic testing, verification or validation, or testing or debugging. Scenario items describe what a person does after a failure or a review finding and ask which activity it is, which step comes first, or which follow-up is best. Some use roman-numeral sets of statements to judge as true or false. Distractors swap the definitions of near-twin terms, so read each option for which yardstick or activity it really names.CTFL Why Testing Is Necessary: QA vs QC, Errors and FailuresQuestions on this topic are mostly short definition and classification items. They assess whether you can match a scenario to one of the four contributions of testing, distinguish QA from QC by orientation (process or product), approach (preventive or corrective) and how each uses test results, and recall who is responsible for QA. Error, defect, failure and root cause items describe a short chain of events and ask what one element is or which mapping of terms is correct, including defects outside the code, defects that have not failed, and failures with an environmental origin. Root cause items assess whether you can tell an action on the underlying situation from one that fixes or detects individual defects.ISTQB CTFL Seven Testing Principles ExplainedThis topic is a K2 learning objective, so questions ask you to explain the principles rather than recite them. Expect short scenarios that ask which principle an observation illustrates, "which statement is TRUE/CORRECT" items that mix accurate statements of the principles with distorted ones, and items asking for the BEST response to a principle, such as how to focus effort when exhaustive testing is impossible or what to do once verification is complete. Some items combine two principles in one scenario, so know how each principle relates to the others.ISTQB CTFL Test Activities, Testware, Traceability and Test RolesQuestions on this topic are mostly short understanding (K2) items. Expect a brief description of a task and a choice of which test activity it belongs to, near-twin pairs such as analysis versus design, design versus implementation, or monitoring versus control, and items that ask which activity produces a given work product, sometimes as a matching list. Context items ask you to classify a factor (for example project constraint versus team or business domain factor) or to choose the tailoring that fits several factors at once. Traceability items ask which benefit a particular link provides, and role items describe what people actually do and ask which role they are performing, regardless of their job title.ISTQB CTFL Tester Skills, Whole Team Approach and Independence of TestingExpect mostly short recall and understanding items. Skill questions describe what a tester does and ask which generic skill it shows, so know which group serves effectiveness, efficiency, hard-to-find defects, stakeholder communication or business understanding, and keep testing, technical and domain knowledge apart. Communication items turn on confirmation bias and reporting defects about the product, not the author. Whole team items cover its origin, its advantages, the tester's collaboration with business representatives and developers, and its limits. Independence items cover the four levels, the benefits and drawbacks, and why familiarity still matters.

Other CTFL domains

Domain 2: Testing Throughout the Software Development Lifecycle15% of the exam · 99 questionsDomain 3: Static Testing10% of the exam · 66 questionsDomain 4: Test Analysis and Design28% of the exam · 184 questionsDomain 5: Managing the Test Activities22% of the exam · 145 questionsAll CTFL practice questionsMixed sessions across all 6 domains — the way the real exam interleaves them.

Fundamentals of Testing: your questions

Fundamentals of Testing is domain 1 of the CTFL exam guide and carries 20% of the scored content — the 3rd-heaviest of the 6 domains. On a 40-question paper that works out to roughly 8 questions, though ISTQB does not publish an exact per-domain count and individual exam forms vary.

Source

The domain weight and topic list on this page come from the official CTFL exam guide.