Free ISEB-SWTINT1 Practice Test

Configuration management (CM) procedures are fundamental to maintaining control and integrity over all test assets, including the test item, test environment, and testware. These procedures must be established early to ensure consistency and traceability throughout the entire test process. The test planning phase is dedicated to defining the overall test strategy, objectives, and the processes that will govern testing activities. Therefore, defining and implementing the procedures for configuration management is a critical activity that occurs during test planning and is documented within the test plan. This ensures that all subsequent activities, such as analysis, design, and execution, are conducted under proper version control.

B. During test analysis, established CM procedures are used to control versions of the test basis and the test conditions being created, not implemented for the first time.
C. During test execution, CM procedures must already be in place and strictly followed to ensure the correct versions of code, test scripts, and environment are used.
D. When evaluating exit criteria, CM provides essential data (e.g., which version was tested), but the procedures themselves must have been implemented long before this final step.

1. ISTQB® Certified Tester Foundation Level Syllabus (Version 2018 v3.1), Section 5.2.5, "Configuration Management". This section describes the purpose of CM in testing. Its placement within Chapter 5, "Test Management," and specifically under section 5.2, "Test Planning and Estimation," firmly associates the establishment of CM procedures with the test planning phase. The test plan, an output of this phase, documents these procedures.

2. Hambling, B., Morgan, P., Samaroo, A., & Williams, G. (2021). Software Testing: An ISTQB-BCS Certified Tester Foundation Guide (4th ed.). BCS, The Chartered Institute for IT. In Chapter 5, "Test Management," the text explains that the test plan specifies the items that need to be under configuration control and the procedures that will be used. This confirms that CM procedures are determined and set up during the planning stage. (See Section 5.2.2, "Test plan content").

From a testing perspective, the main purposes of Configuration Management (CM) are to establish and maintain the integrity of all test items and testware. This involves three core activities:
1. Configuration Identification: Uniquely identifying the version of the software under test (i) and the versions of all associated testware (e.g., test plans, cases, scripts) (ii). This ensures that test results can be accurately traced back to a specific build and a specific set of tests.
2. Configuration Control: Managing and tracking changes to testware (iv). This is crucial for maintaining the consistency and validity of the test suite over time, especially in iterative development cycles. These activities ensure that tests are repeatable and that defects can be reliably reproduced.

iii. Ensuring that all testware is stored in a common repository. While using a common repository is a best practice facilitated by CM tools, it is a mechanism for implementation, not a fundamental purpose of CM itself.
v. Ensuring that all testware is backed up. Backing up assets is a critical data protection and disaster recovery function, which is distinct from the primary CM goals of versioning, control, and status accounting.

1. ISTQB® Certified Tester Foundation Level Syllabus (Version 2018 V3.1):

Section 5.3, Configuration Management, Page 53: "The purpose of configuration management is to establish and maintain the integrity of the component or system, the testware, and their relationships to one another throughout the project and product lifecycle." It further states, "These items [testware] should be uniquely identified, version-controlled, tracked for changes, and related to each other." This directly supports points (i), (ii), and (iv) as core purposes.

2. Graham, D., Van Veenendaal, E., & Black, R. (2019). Foundations of Software Testing: ISTQB Certification (4th ed.). Cengage Learning.

Chapter 5, Section 5.3, Configuration management, Page 218: The text explains that CM ensures that "we know the exact version of everything we are dealing with." It lists typical configuration items as the "test object" (software under test) and "testware." It also emphasizes that CM "controls the changes made to these items." This aligns with the selection of (i), (ii), and (iv). The text does not define repository location or backups as a primary purpose of CM.

Static analysis tools examine source code or other software artifacts without executing them. Their primary and most effective use is to automatically and consistently check the code against a predefined set of rules. This makes them exceptionally useful for the enforcement of coding standards, as they can identify deviations in syntax, structure, and complexity that would be tedious and error-prone for human reviewers to find manually. This automated enforcement improves code quality, maintainability, and consistency across a project.

A. Supporting reviews. While static analysis findings are valuable inputs for reviews, the tool's core function is the analysis and rule enforcement itself, not the support of the human-centric review process.
B. Validating models of the software. This is a specialized task, often performed by model-checking tools. While a form of static analysis, it is not the most common or primary use for the general-purpose static analysis tools implied here.
C. Testing code executed in a special test harness. This describes dynamic testing, where code is executed to observe its behavior. Static analysis, by definition, analyzes code without running it.

1. ISTQB® Certified Tester Foundation Level Syllabus (Version 2018 V3.1.1):

Section 5.3.2, "Test Tool Classification," discusses static analysis tools. It states, "Static analysis tools support developers and testers in finding defects and enforcing coding standards... They help to find defects, not failures. They are an extension of compiler warnings." This explicitly identifies "enforcing coding standards" as a key purpose.

2. Graham, D., Van Veenendaal, E., Evans, I., & Black, R. (2019). Foundations of Software Testing: ISTQB Certification (4th ed.). Cengage Learning.

In Chapter 3, Section 3.2, "Static analysis by tools," the text lists typical defects found by static analysis tools. The first item on the list is often related to standards: "A static analysis tool can find defects such as... violating programming standards" (paraphrased from content on pp. 108-110). The text emphasizes that this is a key strength of such tools.

3. Spillner, A., Linz, T., & Rossner, T. (2021). Software Testing Foundations: A Study Guide for the Certified Tester Exam (5th ed.). Rocky Nook.

Chapter 3, Section 3.2, "Static Analysis by Tools," states: "Typical defects that can be found more easily by tools than by humans are... Deviations from standards (coding standards)." It highlights that checking for compliance with coding guidelines is a primary and efficient application of these tools.

A test case specification is the document that provides a detailed description of a single test. According to industry standards like IEEE 829 and the ISTQB syllabus, a fundamental component of a test case specification is the definition of the 'expected results'. This section precisely describes the anticipated outcome or state of the software after the test steps are executed with specified inputs. The actual results are then compared against these expected results to determine whether the test has passed or failed.

B. Test design specification: This document outlines the overall test strategy and identifies features to be tested, but not the specific expected results for each test case.
C. Test procedure specification: This specifies the sequence of actions for executing a test (the 'how-to'), not the predicted outcome of that execution.
D. Test results: This refers to the actual outcome observed after executing a test, which is then compared against the predefined expected result.

1. ISTQB® Glossary of Testing Terms (Version 4.0). The definition for "Test Case" states: "A set of preconditions, inputs, actions (where applicable), expected results and postconditions, developed based on test conditions." This directly links expected results to the test case.

2. IEEE Std 829-2008, "IEEE Standard for Software and System Test Documentation". Section 5.4, "Test Case Specification," requires a dedicated section for "Expected results." It defines this as specifying "the required, observable outcomes from executing the test case."

3. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill. In Chapter 18, "Software Testing Strategies," the book describes the anatomy of a test case, explicitly including "a list of expected outputs or results" as a critical element. This text is standard in university software engineering curricula.

State transition testing is a black-box technique used to model the behavior of a system. A state transition diagram illustrates the possible states of a system and the valid transitions that can cause a change from one state to another. To identify an invalid sequence, we must trace each path on the provided diagram. The sequence in option C, "Login → Browse → Basket → Checkout → Basket → Logout," contains an invalid transition. While all other steps in this sequence are valid, the final transition from the 'Basket' state directly to the 'Logout' state is not permitted, as there is no corresponding arrow in the diagram. This represents an illegal sequence of events.

A. This sequence is valid. The diagram explicitly shows transitions allowing a user to move from 'Checkout' back to 'Basket' and then proceed again.
B. This sequence represents a standard, valid "happy path" through the system, with each transition directly corresponding to an arrow on the diagram.
D. This sequence is valid. The diagram permits moving from 'Basket' back to 'Browse' and then back to 'Basket' before proceeding to checkout.

1. BCS Foundation Certificate in Software Testing Syllabus (2018 Version): Section 4.3, "State Transition Testing," describes this technique. It states, "Transitions are the movements from one state to another... A state diagram shows the possible software states, as well as how the software enters, exits and transitions between states." The invalidity of option C is determined by the absence of a defined transition from 'Basket' to 'Logout'.

2. Jorgensen, P. C. (2013). Software Testing: A Craftsman's Approach, Fourth Edition. CRC Press. Chapter 9, "State-Based Testing," discusses the formal model of finite state machines. On page 218, it explains that a sequence of events is valid only if each event corresponds to a defined transition from the current state in the model. The transition 'Logout' from state 'Basket' is not defined, hence the sequence is invalid. (DOI: https://doi.org/10.1201/b15696)

3. Pressman, R. S., & Maxim, B. R. (2015). Software Engineering: A Practitioner's Approach, Eighth Edition. McGraw-Hill Education. Chapter 21, "Black-Box Testing," covers state-based testing. It emphasizes that test cases are derived from the state diagram to exercise valid transitions. An invalid transition, as seen in option C, represents a sequence that the system should reject or handle as an error. (Refer to Section 21.5.2, "State-Based Testing").

State transition testing involves creating test cases that execute sequences of events to move a system through its various states. Assuming the system starts in the initial state S1, we can trace the path for each option using the provided state transition table. The event sequence in option A, 'D, A, B, C', results in the state path: S1 → S1 → S2 → S3 → S4. This path covers the following four distinct transitions:
1. (S1, D) → S1
2. (S1, A) → S2
3. (S2, B) → S3
4. (S3, C) → S4 Although the question omits the target series of transitions, this is the only option that covers this specific, comprehensive set.

B: The sequence A, B, C, D does not execute the transition (S1, D) → S1. It follows the path S1 → S2 → S3 → S4 → S1. C: The sequence D, A, B is incomplete. It does not execute the final transition from S3 to S4 with event C. D: The sequence A, B, C does not execute the transition (S1, D) → S1, which is a self-loop on the initial state.

1. Hambling, B., Morgan, P., Samaroo, A., & Williams, G. (2021). Software Testing: An ISTQB-BCS Certified Tester Foundation Guide (4th ed.). BCS, The Chartered Institute for IT. In Chapter 4, Section 4.3.2, "State transition testing," the methodology of designing test cases as sequences of events to cover transitions is detailed.

2. Jorgensen, P. C. (2013). Software Testing: A Craftsman's Approach (4th ed.). CRC Press. Chapter 9, "Graph, State, and Transition Testing," explains that a test case for a state model is a sequence of inputs that corresponds to a path through the state graph (p. 221).

3. Ammann, P., & Offutt, J. (2016). Introduction to Software Testing (2nd ed.). Cambridge University Press. Chapter 3 discusses graph coverage criteria, where test paths (sequences of nodes and edges) are derived to satisfy criteria like visiting all nodes (states) or traversing all edges (transitions). The analysis in this question requires tracing such a path.

The review planning phase is the first stage of a formal review process. Its purpose is to establish the foundation for a successful review. Key activities include defining the scope, objectives, and entry/exit criteria. A critical part of this phase is resource planning, which involves selecting the appropriate participants and formally allocating their individual roles, such as moderator, author, and reviewer. This ensures that all responsibilities are clearly defined before the review commences.

A. Log defects: This activity occurs during the individual review and subsequent review meeting (issue communication and analysis phase), not during planning.
B. Explain the documents to the participants: This is a primary activity of the 'initiate review' or 'kick-off' phase, which follows the planning phase.
C. Gather metrics: Metrics are defined during planning, but the actual gathering of data (e.g., number of defects, effort spent) happens during and after the review execution.

1. ISTQB® Certified Tester Foundation Level Syllabus (CTFL) 2018 V3.1, Section 3.2.2, "Activities of a Formal Review". The syllabus explicitly lists "Selecting the people to participate in the review and allocating roles" as a key activity within the Planning phase (p. 29).

2. Black, R. (2019). ISTQB Certified Tester Foundation Level Exam Certification Guide. Rocky Nook. Chapter 3, "Static Testing," details the review process. The section on "Planning the Review" confirms that defining roles and responsibilities is a fundamental planning task.

3. van Veenendaal, E. (Ed.). (2012). Foundations of Software Testing: ISTQB Certification. Cengage Learning. Chapter 3, "Static Techniques," describes the phases of a formal review. The "Planning" phase is detailed as including the allocation of roles to the review team (p. 85).

The main objective of a review, as a primary static testing activity, is to find defects in any software work product. This process is applied to various deliverables throughout the software development lifecycle, such as requirements specifications, design documents, code, and test plans. By examining these documents before dynamic testing, reviews help in the early detection and removal of errors, omissions, and ambiguities. This proactive approach improves the overall quality of the final product and reduces the cost of fixing defects, which is the central goal of the review process.

A. This describes dynamic testing, which involves executing the software to find failures, not the static examination of a deliverable.
C. While spelling mistakes are defects, this is too specific. The main objective is to find all types of defects, including major logical or functional errors.
D. This is a valid objective for a code review specifically, but not the main objective for reviewing any software deliverable, such as a requirements document.

1. ISTQB® Certified Tester Foundation Level Syllabus (Version 2018 V3.1): Section 3.2.2, "Benefits of Reviews," states, "The main purpose of reviews is to find defects." It further clarifies that reviews contribute to "early defect detection and correction" and can be applied to any work product.

2. Black, R., van Veenendaal, E., & Greaves, D. (2019). Foundations of Software Testing: ISTQB Certification (4th ed.). Cengage Learning. Chapter 3, Section "Objectives of the review process," explicitly lists "finding defects" as the primary objective of any formal review.

3. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill. In Chapter 17, "Review Techniques," the text states, "The primary objective [of a formal technical review] is to find errors during the process so that they do not become defects after release of the software." This applies to any work product being reviewed.

The system's behavior changes at temperatures 18 and 21, creating three distinct equivalence partitions for the input domain (temperature):
1. Partition 1 (Heating OFF): Temperatures below 18 degrees (e.g., ..., 16, 17).
2. Partition 2 (State Unchanged): Temperatures from 18 to 20 degrees inclusive.
3. Partition 3 (Heating ON): Temperatures 21 degrees and above (e.g., 21, 22, ...). To achieve full coverage using equivalence partitioning, at least one value must be selected from each partition. Option A (15, 19, 25) is the only choice that provides a representative value for all three partitions: 15 for Partition 1, 19 for Partition 2, and 25 for Partition 3.

B. This option fails to test the partition for temperatures 21 and above (Partition 3), which is required for complete coverage.
C. This option fails to test the partition for temperatures below 18 (Partition 1), resulting in incomplete test coverage.
D. This option fails to test the partition for temperatures between 18 and 20 (Partition 2), leaving a key behavioral range untested.

1. ISTQB® Certified Tester Foundation Level Syllabus (Version 2018 v3.1.1): Section 4.2.1, "Equivalence Partitioning (EP)," states, "To achieve 100% EP coverage, test cases must cover all identified partitions... by exercising at least one value from each partition." This principle directly supports selecting one value from each of the three identified temperature ranges.

2. Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner's Approach (9th ed.). McGraw-Hill. In Chapter 21, "Software Testing Strategies," the text explains that equivalence partitioning divides the input domain into classes of data from which test cases are derived. The goal is to select a test case from each class to ensure a high probability of detecting errors. This methodology validates the identification of the three partitions and the selection of a single test value from each.

3. MIT OpenCourseWare, 6.170 Software Studio, Lecture 10: Testing. The lecture notes describe equivalence partitioning as a method to divide the input space into a finite number of equivalence classes. The testing strategy is to "pick one test case from each class," which is precisely the logic applied to solve this problem. (Available at MIT OCW website).

Functional testing is a test type focused on evaluating what a system does, based on its functional requirements and specifications. This test type is not confined to a specific test level. It can be applied at every stage of the testing process. For instance, at the component level, it verifies the functionality of individual units. At the integration level, it checks the functional behavior of interacting components. At the system and acceptance levels, it validates that the complete system functions according to end-to-end business requirements and user expectations. Therefore, functional testing is applicable at all test levels.

A. This is incorrect because it omits component and integration testing, where verifying the functionality of individual parts and their interactions is crucial.
C. This is incorrect as it wrongly excludes component and integration testing, which are fundamental stages for performing functional tests on modules and their interfaces.
D. This is incorrect because it severely restricts functional testing to a single level, ignoring its critical role in earlier stages like component, integration, and system testing.

1. ISTQB® Certified Tester Foundation Level Syllabus (Version 2018):

Section 2.2.1, "Functional Testing," states: "Functional tests can be performed at all test levels (e.g., testing the functionality of an individual component during component testing, or testing the functionality of the end-to-end business process during system testing)." This directly supports that functional testing is applicable at all levels.

2. Black, R. (2019). ISTQB Certified Tester Foundation Level Syllabus 2018. Rocky Nook.

Chapter 2, "Testing Throughout the Software Development Lifecycle," explains the relationship between test levels and test types. It clarifies that test types like functional testing are orthogonal to test levels and can be executed at any level. For example, on page 68, it discusses how functional testing applies to component testing, integration testing, system testing, and acceptance testing.

3. Jorgensen, P. C. (2013). Software Testing: A Craftsman's Approach, Fourth Edition. CRC Press.

Chapter 1, "A Math and Logic Foundation," Section 1.3, "The V-Model," discusses the relationship between development phases and test levels. The text implicitly and explicitly supports that functional verification (a form of functional testing) occurs at every level, from unit to system testing, to check against the requirements defined at the corresponding development stage. (See Figure 1.6, page 18).