Free Practice Questions for iSQI CTFL_Syll2018 Exam

 Equivalence partitioning is a black box test design technique2. A black box technique is a technique that uses the external behaviour or specification of a system as a test basis to derive test cases without referring to its internal structure or logic2. Equivalence partitioning is a technique that divides the input domain of a system into partitions of equivalent data2. Each partition should contain data that is expected to be treated the same by the system2. Therefore, only one test case input from each partition is needed to test the system’s behaviour2. Therefore, equivalence partitioning is a black box test design technique.

Explanation of Correct Answer: Priority indicates the level of business importance assigned to the defect, while severity indicates the degree of impact that a defect has on the development or operation of a component or system. Urgency is not a standard term used in defect reporting, and difficulty refers to the effort required to fix the defect.

References: Section 1.4.3.2, Section 5.3.2

b & c are debugging activities, because they involve locating the cause of failure and fixing the defect in the software . Debugging is the process of finding and removing the causes of software failures . The other options are not debugging activities, but rather testing activities. Option A is a testing activity, because it involves identifying a failure in the software by comparing the expected and actual results . Option D is a testing activity, because it involves checking the fix has resolved the failure by re-testing the software .

Defect density is a metric that measures the number of defects identified in the system under test divided by the size of the system. The size of the system can be measured in different ways, such as lines of code, function points, or modules. Defect density can be used to compare the quality of different systems or different versions of the same system.

References: [Certified Tester Foundation Level Syllabus], Section 8.3.1

Software testing can be necessary to fulfill legal or contractual obligations, such as safety standards or compliance requirements. This is stated in the syllabus under section 1.1, "Why is Testing Necessary?"1. Intensive testing can help reduce risks and problems during operation by finding defects early and preventing failures. This is stated in the syllabus under section 1.2, "What is Testing?"1. Software testing is not done to increase the quality of developers, nor is it used to prove correctness. These are common misconceptions about testing that are refuted in the syllabus under section 1.3, "Seven Testing Principles"1.

References: Certified Tester Foundation Level (CTFL) Syllabus - ASTQB

Maintenance testing is triggered by changes, such as migration, retirement, or enhancement of a system1. Therefore, option A is the best example of a trigger for maintenance testing. Options B, C, and D are examples of triggers for development testing, not maintenance testing1. References: 1, Section 2.3.2

Tests designed by a person in the development team other than the person who wrote the code is not the lowest level of independence. The lowest level of independence is tests designed by the person who wrote the code, as this may introduce bias or blind spots in testing. Tests designed by another person in the development team is one level higher than tests designed by the person who wrote the code, as this may provide a different perspective or expertise in testing. defines the levels of independence as follows:

The level of independence of testing is related to the degree of separation between those who are responsible for developing software and those who are responsible for testing software.

The following levels of independence can be distinguished:

Level 0: No independent testing; tests are designed by the same person who wrote the code.

Level 1: Tests are designed by another person in the development team; e.g., another programmer or software designer.

Level 2: Tests are designed by a person from a different group within the organization; e.g., an independent test team or group.

Level 3: Tests are designed by a person from a different organization or company; e.g., an outsourcing partner or contractor.

A, B, and C are correct statements. A test team with high level of independence may suffer from lower familiarity with the product (A), as they may not have access to all the information or knowledge about the system under test. Development team may find many defects since they are familiar with the code (B), as they may have more insight into how the system works internally and where potential problems may occur. Tests designed by a person from different group in the organization is the highest level of independence within an organization ©, as this provides maximum separation between development and testing activities.

Providing developers with information to isolate the failure is the incident report objective that this excerpt satisfies. The excerpt provides the name and location of the test file that was used to recreate the failure, which can help developers to reproduce and debug the failure in their own environment. defines this objective as follows:

One of the objectives of an incident report is to provide developers with information to isolate the failure. This means providing enough details and evidence for developers to understand what caused the failure and how to fix it. This may include information such as:

Steps to reproduce: A sequence of steps that can be followed to recreate the failure.

Test data: The inputs that were used to execute the test case that caused the failure.

Test environment: The configuration and settings of the hardware and software that were used to execute the test case that caused the failure.

Attachments: Any screenshots, logs, files, or other artifacts that can help to demonstrate or explain the failure.

B, C, and D are incorrect answers. Providing ideas for test process improvement (B) is not an incident report objective that this excerpt satisfies, as it does not provide any suggestions or feedback on how to improve the test process or prevent similar failures in the future. Not belonging in an incident report © is not true, as this excerpt belongs in an incident report as part of the incident details section. Providing test leaders with information to report test progress (D) is not an incident report objective that this excerpt satisfies, as it does not provide any metrics or indicators on how much testing has been done or how many failures have been found.

Component integration testing is the process of testing the interactions between different components of a system. It should always be done before system testing, which is the process of testing the system as a whole. Integration testing can reveal defects in the interfaces and interactions between components, which can affect the functionality and performance of the system. System testing can reveal defects in the system requirements, design, and behavior, which can affect the quality and usability of the system. Therefore, it is logical to perform integration testing before system testing, to ensure that the components work together correctly before testing the system as a whole.

References: Certified Tester Foundation Level Syllabus, Section 5.1.2 and 5.2.2

 According to the syllabus, error guessing is a technique that uses testers’ experience and intuition to identify potential errors or defects in a software system. An experienced tester makes a list of potential defects and failures, and designs and runs tests to generate these failures should the defects be present in the code. The answer B is correct because it best describes a methodical approach to the error guessing technique. The other answers are incorrect because they describe other techniques, such as exploratory testing (A), checklist-based testing © and negative testing (D).

References: Certified Tester Foundation Level Syllabus, Section 4.2.4, page 43.