ISTQB CTFL-2018 Practice Test - Questions Answers, Page 8

The Test Analysis and Design activity of the test process is the activity where test conditions and test cases are identified and specified based on the test objectives and criteria. The Test Analysis and Design activity also involves identifying and preparing the necessary test data and test environment to support the test execution. Some of the tasks of the Test Analysis and Design activity are:

Reviewing the test basis: This task involves reviewing the requirements, specifications, design documents, or other sources of information that form the basis for testing.

Identifying test conditions: This task involves identifying what needs to be tested based on the test basis and objectives.

Designing and prioritizing test cases: This task involves designing specific scenarios or steps to verify each test condition and assigning priorities to them based on their importance or risk level.

Identifying necessary test data to support the test conditions and test cases: This task involves identifying what data is needed to execute each test case and how to obtain or generate it.

Identifying and preparing the test environment: This task involves identifying what hardware, software, network, data, tools, etc., are needed to execute the test cases and how to set up and maintain them.

Measuring the percentage of prepared test cases with what was actually prepared is not a task of the Test Analysis and Design activity because it does not involve identifying or specifying anything related to testing. Rather, it is a task of the Test Monitoring and Control activity, which involves measuring and reporting the progress and status of testing against the planned activities and criteria. You can find more information about the Test Analysis and Design activity inA Study Guide to the ISTQB Foundation Level 2018 Syllabus, Chapter 31.

The requirement given in the image specifies an additional fee of $3 that is charged during the weekend, with some exceptions and discounts based on the age of the visitors. To test this requirement, we can use boundary value analysis, which is a specification-based test technique that involves testing the values at or near the boundaries of an equivalence partition. An equivalence partition is a set of values that are expected to be treated in the same way by the system under test. For example, based on the requirement, we can identify the following equivalence partitions for the input age:

EP1: Age < 0 (invalid)

EP2: Age = 0 (valid, no charge)

EP3: 0 < Age < 7 (valid, no charge)

EP4: Age = 7 (valid, 20% discount)

EP5: 7 < Age < 13 (valid, 20% discount)

EP6: Age = 13 (valid, 20% discount)

EP7: 13 < Age < 65 (valid, full charge)

EP8: Age = 65 (valid, 50% discount)

EP9: Age > 65 (valid, 50% discount)

The boundary values for each equivalence partition are the values at or near the edges of the partition. For example, the boundary values for EP3 are 1 and 6. The boundary values for EP4 are 6 and 7. The boundary values for EP5 are 7 and 12. And so on.

To test this requirement using boundary value analysis, we need to select one value from each boundary and test it with different combinations of weekend and weekday. For example, we can select the following values:

BV1: Age = -1 (from EP1)

BV2: Age = 0 (from EP2 and EP3)

BV3: Age = 6 (from EP3 and EP4)

BV4: Age = 7 (from EP4 and EP5)

BV5: Age = 12 (from EP5 and EP6)

BV6: Age = 13 (from EP6 and EP7)

BV7: Age = 64 (from EP7 and EP8)

BV8: Age = 65 (from EP8 and EP9)

BV9: Age = 66 (from EP9)

We can then create test cases using these values and different combinations of weekend and weekday. For example:

TC1: Age = -1, Weekend = Yes -> Invalid input

TC2: Age = -1, Weekend = No -> Invalid input

TC3: Age = 0, Weekend = Yes -> No charge

TC4: Age = 0, Weekend = No -> No charge

TC5: Age = 6, Weekend = Yes -> No charge

TC6: Age = 6, Weekend = No -> No charge

TC7: Age = 7, Weekend = Yes -> $2.40 ($3 - 20% discount)

TC8: Age = 7, Weekend = No -> No charge

TC9: Age = 12, Weekend = Yes -> $2.40 ($3 - 20% discount)

TC10: Age = 12, Weekend = No -> No charge

TC11: Age = 13, Weekend = Yes -> $2.40 ($3 - 20% discount)

TC12: Age = 13, Weekend = No -> No charge

TC13: Age = 64, Weekend = Yes -> $3

TC14: Age = 64, Weekend = No -> No charge

TC15: Age = 65, Weekend = Yes -> $1.50 ($3 - 50% discount)

TC16: Age = 65, Weekend = No -> No charge

TC17: Age = 66, Weekend = Yes -> $1.50 ($3 - 50% discount)

TC18: Age =

66, Weekend = No -> No charge

Therefore, we need a minimum of18valid test cases to achieve100%boundary value coverage based on input age.

$3.01 is not a valid output boundary value because it is not a possible output value based on the requirement. The output values can only be $0, $1.50, $2.40, or $3 depending on the input age and weekend status.

You can find more information about boundary value analysis in [A Study Guide to the ISTQB Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.

Static analysis tools are tools that examine the code or design of a software system without executing it. Static analysis tools can be used to find defects, measure complexity, check compliance, or improve quality. Some examples of defect types that can be found by static analysis tools are:

Variables that are never used: This defect type occurs when a variable is declared but not referenced or assigned in the code, which indicates a waste of memory or a logic error.

Coding standard violations: This defect type occurs when the code does not follow the predefined rules or conventions for formatting, naming, commenting, etc., which affects the readability and maintainability of the code.

Uncalled functions and procedures: This defect type occurs when a function or procedure is defined but not called or invoked in the code, which indicates a waste of resources or a missing functionality.

Memory leaks are defect types that are least likely to be found by static analysis tools because they are related to the dynamic behavior and performance of the software system. Memory leaks occur when a program does not release memory that it has allocated, causing the system to run out of memory and slow down or crash. Memory leaks can only be detected by dynamic analysis tools that monitor the memory usage of the program during execution. You can find more information about static analysis tools in [A Study Guide to the ISTQB Foundation Level 2018 Syllabus], Chapter 6, Section 6.3.

How to fix the defect is not needed to specify in a defect report because it is not part of the information that is required to describe, reproduce, and prioritize the defect. How to fix the defect is part of the solution or resolution that is provided by the developers or maintainers who are responsible for correcting the defect. A defect report is a document that records and communicates the details of a defect found during testing. A defect report typically includes the following information:

Defect ID: A unique identifier for the defect

Summary: A brief description of the defect

Severity and priority: An indication of how serious and urgent the defect is

Test environment details: A description of the hardware, software, network, data, tools, etc., that were used when the defect was found

How to reproduce the defect: A step-by-step procedure to recreate the defect

Expected and actual results: A comparison of what should have happened and what actually happened when the defect occurred

Attachments: Any additional information or evidence that can help understand or resolve the defect, such as screenshots, logs, files, etc.

You can find more information about defect reports in [A Study Guide to the ISTQB Foundation Level 2018 Syllabus], Chapter 5.

The statement that does not describe how testing contributes to higher quality is ''The testing of software demonstrates the absence of defects''. This statement is false because testing cannot prove that a software system is defect-free or has a certain level of quality because there might be some untested inputs or outputs that could reveal defects or failures. Testing can only provide information about the quality and risk level of a software system based on the observed behavior and results under certain conditions and assumptions. The other statements describe how testing contributes to higher quality by:

Performing a review of the requirement specifications before implementing the system can enhance quality: This statement is true because reviewing the requirement specifications can help identify and prevent defects, ambiguities, inconsistencies, or incompleteness in the requirements before they are implemented in the system, which can save time and effort and improve customer satisfaction.

Properly designed tests that pass reduce the level of risk in a system: This statement is true because passing tests can increase confidence that the system meets its requirements and expectations and provides value to the users and customers. Passing tests can also reduce the probability or impact of failures or defects in the system that could cause harm or loss.

Software testing identifies defects, which can be used to improve development activities: This statement is true because identifying defects can help analyze and remove their causes and prevent them from recurring in future development activities. Identifying defects can also help improve development processes, methods, standards, tools, techniques, etc., by providing feedback and lessons learned.

You can find more information about how testing contributes to higher quality in [A Study Guide to the ISTQB Foundation Level 2018 Syllabus], Chapter 1.

The fundamental test process activity where the sufficiency of testing and resulting information are assessed is Evaluating exit criteria and reporting. This activity involves checking whether the test objectives have been met and whether there are any unresolved issues or risks that could affect the release or deployment decision. This activity also involves preparing and communicating a test summary report that summarizes the test activities and results and provides recommendations and feedback for improvement. You can find more information about Evaluating exit criteria and reporting in [A Study Guide to the ISTQB Foundation Level 2018 Syllabus], Chapter 3, Section 3.5.

Regression testing is a type of testing that is performed after a software system has been changed or modified to verify that the changes have not introduced any new defects or adversely affected the existing functionality of the system. Regression testing can be performed when the software system undergoes different types of changes, such as:

Corrective changes: Changes that fix defects or errors in the software system

Adaptive changes: Changes that adapt the software system to new platforms or environments

Perfective changes: Changes that improve the performance or usability of the software system

Preventive changes: Changes that avoid potential problems or issues in the software system

In this case, the software system was re-deployed because the backend database was changed from one vendor to another, which is an example of an adaptive change. Therefore, the test manager decided to perform some functional tests on the re-deployed system to ensure that the change did not affect the functionality of the system. This is an example of regression testing.

The other types of testing mentioned in the question are not relevant for this scenario. For example:

Non-functional testing: This type of testing verifies the non-functional aspects of the software system, such as reliability, performance, security, usability, etc.

Structural testing: This type of testing verifies the internal structure or implementation of the software system, such as code, architecture, design, etc.

Unit testing: This type of testing verifies individual components or units of software in isolation from other components or systems.

You can find more information about regression testing in [A Study Guide to the ISTQB Foundation Level 2018 Syllabus], Chapter 2, Section 2.4.

The requirement given in the image specifies a field asking for the number of group members, which can be anywhere from 2 to 20 visitors. To test this requirement, we can use boundary value analysis, which is a specification-based test technique that involves testing the values at or near the boundaries of an equivalence partition. An equivalence partition is a set of values that are expected to be treated in the same way by the system under test. For example, based on the requirement, we can identify two equivalence partitions for the input group size:

EP1: Group size < 2 (invalid)

EP2: Group size = 2 (valid)

EP3: 2 < Group size < 20 (valid)

EP4: Group size = 20 (valid)

EP5: Group size > 20 (invalid)

The boundary values for each equivalence partition are the values at or near the edges of the partition. For example, the boundary values for EP1 are -1 and 1. The boundary values for EP2 are 1 and 2. The boundary values for EP3 are 2 and 19. And so on.

To test this requirement using boundary value analysis, we need to select one value from each boundary and test it with different combinations of valid and invalid inputs. For example, we can select the following values:

BV1: Group size = -1 (from EP1)

BV2: Group size = 1 (from EP1 and EP2)

BV3: Group size = 2 (from EP2 and EP3)

BV4: Group size = 19 (from EP3 and EP4)

BV5: Group size = 20 (from EP4 and EP5)

BV6: Group size = 21 (from EP5)

We can then create test cases using these values and different combinations of valid and invalid inputs. For example:

TC1: Group size = -1 -> Invalid input

TC2: Group size = 1 -> Invalid input

TC3: Group size = 2 -> Valid input

TC4: Group size = 19 -> Valid input

TC5: Group size = 20 -> Valid input

TC6: Group size = 21 -> Invalid input

Therefore, we need a minimum of6valid test cases to achieve100%boundary value coverage based on input group size.

You can find more information about boundary value analysis in [A Study Guide to the ISTQB Foundation Level 2018 Syllabus], Chapter 4, Section 4.2.

A software company decided to buy a commercial application for its accounting operations. As part of the evaluation process, the company decided to assemble a team to test a number of candidate applications. The most suitable team for this goal would be a team with a mix of software testers and experts from the accounting department. This team would have the following advantages:

Software testers have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They can also use tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.

Experts from the accounting department have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They can also provide feedback and suggestions for improvement based on their needs and expectations as end users or customers.

The other teams mentioned in the question are not as suitable for this goal as they are for other purposes or scenarios. For example:

A team from an outsourcing company which specializes in testing accounting software: This team might have the skills and experience to test accounting software, but they might not have the knowledge and expertise to understand and validate the specific requirements and criteria of the company that wants to buy the application. They might also lack the communication and collaboration with the stakeholders of the company who are involved in the evaluation process.

A team of users from the accounting department that will need to use the application on a daily basis: This team might have the knowledge and expertise to understand and validate the functionality and usability of each candidate application, but they might not have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company. They might also lack the tools and techniques to support their testing activities and provide reliable and objective information about the quality and risk level of each candidate application.

A team from the company's testing team, due to their experience in testing software: This team might have the skills and experience to design, execute, and evaluate test cases based on the requirements and criteria of the company, but they might not have the knowledge and expertise to understand and validate the functionality and usability of each candidate application. They might also lack the feedback and suggestions for improvement based on the needs and expectations of the end users or customers.