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

Equivalence Partitioning is a black-box test design technique that divides input data of a software module into partitions of equivalent data from which test cases can be derived. In this context, the valid equivalence partitions are:

Silver Tier: 0 to 400 Credits

Gold Tier: 401 to 800 Credits

Platinum Tier: 801 to 1400 Credits

Concierge Tier: 1401+ Credits

The test cases provided cover all these partitions:

TC1 covers the Silver Tier boundary at 400 Credits.

TC2 covers within the Gold Tier at 500 Credits.

TC3 covers the Gold Tier boundary at 800 Credits.

TC4 covers within the Concierge Tier at 1500 Credits.

Since all valid partitions are covered by the test cases, 100% of the valid Equivalence Partitions have been achieved.

2-point boundary value analysis is a technique that tests the boundary values of valid and invalid partitions with two values each: one at the boundary and one just outside the boundary. For example, if the valid range is 1 to 10, the 2-point boundary values are 1, 2, 9, 10 for the valid partition, and 0, 11 for the invalid partitions. The advantage of this technique is that it reduces the number of test cases compared to 3-point boundary value analysis, which tests one value inside the boundary as well. However, it may miss some defects that occur only with the values inside the boundary.

In this question, the valid partitions are the ranges of spending that correspond to different discounts, and the invalid partitions are the ranges of spending that are below or above the valid partitions. The boundaries are the values of spending that trigger a change in the discount rate. The 2-point boundary values for each partition are:

Invalid partition below 500: 0, 499

Valid partition for 5% discount: 500, 501

Valid partition for 10% discount: 1000, 1001

Valid partition for 15% discount: 2000, 2001

Valid partition for 20% discount: 4000, 4001

Invalid partition above 4000: 4001, 4002

The test cases TC1 and TC2 already cover two of the boundary values: 500 and 2000. Therefore, to achieve 100% 2-point boundary value analysis, we need to write seven more test cases to cover the remaining boundary values: 0, 499, 501, 1000, 1001, 4000, and 4002. Note that 4001 is a boundary value for both the valid and invalid partitions, so we only need to test it once.

Product risk analysis is an approach to testing that aims to reduce the level of product risks and inform stakeholders of their status, starting in the initial stages of a project1.It involves the identification of product risks and the use of risk levels to guide the test process1.Product risks are uncertain situations that can affect the quality or value of the software product2.One of the factors that can influence the testing approach is the test design technique to be applied3.Test design techniques are methods to derive and select test cases based on the test objectives, test conditions, and test basis2.Decision table testing is a test design technique that is suitable for testing complex business rules that have logical conditions and outcomes2.Therefore, if the product risk analysis identifies that the complex business rules could result in costly failures, then decision table testing will be used for test case design to cover all the possible combinations of conditions and outcomes2.

The other options are not examples of how product risk analysis can influence the testing approach, because they are either not related to product risks or not based on risk levels. They are:

Performance failures were much lower than expected, so more test analysis will be conducted in this area (B).This is not related to product risk analysis, but to test monitoring and control, which is the process of comparing actual progress against the plan and reporting the status2.Test analysis is the activity of analyzing the test basis and defining test objectives2. If the performance failures were much lower than expected, then more test execution or evaluation might be needed, not more test analysis.

There is a lack of automation skills in the test team, so training for the automation tool will be rolled out .This is not related to product risk analysis, but to test management, which is the process of planning, monitoring, and controlling the test activities and resources2.Test automation is the use of software to perform or support test activities2.The lack of automation skills in the test team is a project risk, not a product risk, and it should be addressed by providing adequate training, tools, and resources for the test team2.

There are no product risks recorded around security, so security testing will be given priority as a contingency measure (D). This is not based on risk levels, but on the absence of risk identification, which is a poor practice in product risk analysis.Security testing is a type of testing that determines whether the software protects data and maintains functionality as intended2.Product risk analysis should identify the potential security risks and assign them appropriate risk levels based on their probability and impact1.Security testing should be prioritized based on the risk levels, not on the lack of risk identification, which could lead to overlooking or underestimating the security risks1.

ISTQB Foundation Level 2018 syllabus

Risk in Software Testing

Risk-Based Testing

Test Approach

The test execution schedule should follow the priority order of the tests, as well as the dependency constraints. The priority order is given by the user value column, where higher values indicate higher priority. The dependency constraints are given by the dependency column, where a test ID indicates that the test cannot be run until the test with that ID has been successfully completed. Therefore, the test execution schedule should start with the highest priority test that has no dependency, which is test 5. Then, it should continue with the next highest priority test that has no dependency or has a satisfied dependency, which is test 1. Then, it should proceed with test 2, which depends on test 1, and then test 3, which depends on test 2. Finally, it should end with test 4, which depends on test 3. Thus, the test execution schedule that best meets the prioritisation and dependency conditions is 5,1,2,3,4.

A test completion report for a test level typically includes a summary of all the testing activities that have been performed. It should detail any deviations from the original test schedule, including any changes in the planned duration or effort that were required to complete the test activities. This report serves as a record of what was tested, how it was tested, and any issues that were encountered.

Priority is an important item of information that is missing from the incident report. Priority indicates the importance or urgency of resolving the incident, based on the business needs and the impact on the stakeholders. Priority is usually assigned by the project manager or the customer, and it helps to determine the order in which incidents should be addressed. Priority may differ from severity, which indicates the degree of impact of the incident on the system or the component under test. Severity is usually assigned by the tester or the developer, and it helps to assess the risk of the incident. For example, an incident may have a high severity but a low priority, if it affects a critical function but only occurs in a rare situation. Conversely, an incident may have a low severity but a high priority, if it affects a minor function but occurs frequently or affects many users. Therefore, both priority and severity are useful information for incident management and resolution.

The other options are not essential information for the incident report, although they may be helpful or desirable in some cases. Recommendations are suggestions or proposals for resolving the incident, which may be provided by the tester, the developer, or other stakeholders. However, recommendations are not mandatory, and they may not be feasible or acceptable in some situations. Name of tester is the identifier of the person who reported the incident, which may be useful for communication or accountability purposes. However, name of tester is not critical, and it may be replaced by other identifiers, such as email address, employee number, or role. Change history is the record of the changes made to the incident report, such as status, resolution, or comments. Change history is valuable for tracking and auditing purposes, but it is not part of the initial incident report, rather it is updated as the incident progresses.

After completing the tool selection and a successful proof-of-concept, introducing the selected tool into an organization generally starts with a pilot project, which has the following objectives12:

Gaining in-depth knowledge about the tool, understanding both its strengths and weaknesses

Evaluating how the tool fits with existing processes and practices, and determining what would need to change

Assessing whether the benefits will be achieved at reasonable cost

Identifying and resolving any technical and organizational issues before deploying the tool on a larger scale

Providing training, coaching, and mentoring for users of the tool

Defining metrics to measure the success of the tool deployment

Therefore, the option D is the most typical objective of running a pilot project, as it is essential to ensure the compatibility and suitability of the tool with the current way of working, and to identify any potential risks or challenges that may arise from the tool introduction12.

The other options are not typical objectives of running a pilot project, because they are either part of the tool selection process, or the outcomes of the pilot project. They are:

To establish whether the tool is available for a free trial period (and for how long) (A).This is part of the tool selection process, which involves gathering information about the tool features, costs, support, and availability12.This should be done before running a pilot project, as it helps to narrow down the list of potential tools and to conduct a proof-of-concept12.

To provide training, coaching, and mentoring for users of the tool (B).This is an outcome of the pilot project, which aims to increase the competence and confidence of the tool users and to facilitate the tool adoption12.This should be done during and after the pilot project, as it helps to ensure the effective and efficient use of the tool and to address any issues or feedback from the users12.

To develop a clear set of requirements and objective criteria against which the tool can be evaluated .This is also part of the tool selection process, which involves defining the tool requirements based on the needs and expectations of the stakeholders, and establishing the evaluation criteria based on the benefits and risks of the tool12.This should also be done before running a pilot project, as it helps to compare and rank the potential tools and to select the most suitable one12.

ISTQB Foundation Level 2018 syllabus

Chapter 6 - Tool Support for Testing | PPT

The correct answer is A, as it states that the Wideband Delphi estimation technique is an example of the expert-based approach.The Wideband Delphi estimation technique is a method of estimating testing effort or duration by using a structured group process that involves multiple experts2.The experts provide their estimates independently and anonymously, then compare and discuss them until they reach a consensus2.This technique is an example of the expert-based approach, which is an approach that relies on the knowledge and experience of experts to estimate testing activities2. Option B is incorrect, as it states that the Wideband Delphi estimation technique is an example of the metrics-based approach.The metrics-based approach is an approach that uses historical data and mathematical formulas to estimate testing activities2. This approach does not involve experts or group processes. Option C is incorrect, as it states that burndown charts used in Agile development is an example of the expert-based approach.Burndown charts are graphical tools that show the amount of work remaining versus time in an Agile project2. They are used to monitor and control testing progress and quality. They are not examples of the expert-based approach, as they do not rely on experts' opinions or estimates. Option D is incorrect, as it states that burndown charts used in Agile development is an example of the risk-based approach.The risk-based approach is an approach that uses risk analysis to prioritize and estimate testing activities2. This approach involves identifying and assessing risks based on their likelihood and impact.It does not involve burndown charts or Agile development.

Reference:2, Section 2.6

The correct answer is D, as it describes a test summary report for executive-level employees.A test summary report is a document that summarizes the results and evaluation of testing activities for a specific activity or phase3.It may have different levels of detail and content depending on the intended audience and purpose3.A test summary report for executive-level employees is typically high-level and includes a status summary of defects by priority or budget3.This type of report provides a concise overview of the quality and progress of testing without going into too much detail or technical information3. Option A is incorrect, as it describes a test summary report for technical-level employees.A test summary report for technical-level employees is typically detailed and includes specific information on defects and trends3.This type of report provides a comprehensive analysis of the quality and progress of testing with relevant data and metrics3. Option B is incorrect, as it describes a test summary report that is neither suitable for executive-level nor technical-level employees.A test summary report that is detailed and includes a status summary of defects by priority or budget is too detailed for executive-level employees and too vague for technical-level employees3. Option C is incorrect, as it describes a test summary report that is neither suitable for executive-level nor technical-level employees.A test summary report that is high-level and includes specific information on defects and trends is too high-level for technical-level employees and too specific for executive-level employees3.

Reference:3, Section 2.7