Free Practice Questions for ISTQB CTAL-TTA Exam

Failure Mode and Effect Analysis (FMEA) is a structured approach to identify and address potential failures in a system, product, process, or service. The major factors involved in calculating risk priorities in FMEA are typically the severity of the potential failure, its likelihood of occurrence, and the ability to detect it. These factors are usually combined to form a Risk Priority Number (RPN) for each potential failure mode identified. However, the specific factors mentioned in the options like functionality, reliability, usability, maintainability, efficiency, and portability are quality characteristics that could be considered in an FMEA analysis but are not directly used for calculating risk priorities. Likewise, financial damage, frequency of use, and external visibility might influence the severity or impact of a failure, but they are not standard factors in calculating risk priorities in the context of FMEA. Therefore, the most relevant factors for calculating risk priorities in an FMEA context would typically be the likelihood of the failure occurring and its potential impact, which aligns with option C: Likelihood and impact.

It's important to note that while these explanations are based on general principles and practices related to fault seeding and FMEA, the specifics might vary slightly in different contexts or with different methodologies.

When evaluating a component for maintainability, several metrics are considered:

Coupling: Refers to the degree of interdependence between software modules. Lower coupling is preferred for maintainability.

Cohesion: Refers to how closely related the responsibilities of a single module are. Higher cohesion within modules is preferred.

Commenting: Refers to the presence of comments within the code. While useful, excessive commenting is not necessarily an indicator of maintainability.

Complexity: Refers to the complexity of the code, often measured by metrics like cyclomatic complexity. Lower complexity is preferred.

Given these metrics:

d. Low measure of complexity: Indicates the code is simple and straightforward, which enhances maintainability.

f. High measure of cohesion: Indicates that modules have clear, well-defined responsibilities, enhancing maintainability.

h. High measure of complexity: This should generally be low for better maintainability, but in this context, the assumption is an erroneous inclusion in the preferred list.

Thus, the best combination suggesting that the component does NOT need refactoring for better maintainability is d, f, h.

References:

The selection of metrics and their desired values are based on software engineering principles covered in the ISTQB CTAL-TTA syllabus, which emphasizes low complexity and high cohesion for maintainable software design.

API testing involves testing the application programming interfaces directly and is often a critical part of integration testing. Here are the clarifications for each option:

A. API testing cannot be applied to distributed systems: This is incorrect. API testing is commonly used in distributed systems to ensure that different components interact correctly.

B. Combinatorial testing cannot be applied to API testing: This is incorrect. Combinatorial testing techniques can be very effective in API testing to cover various parameter combinations.

C. API testing may require the use of specialized tools: This is true. API testing often involves tools like Postman, SoapUI, and others to facilitate sending requests and validating responses, which may not be feasible manually.

D. APIs are loosely coupled, so timing glitches will not happen: This is incorrect. Even though APIs are designed to be loosely coupled, timing issues can still occur, especially in asynchronous operations and in systems where timing is critical.

Therefore, the correct answer is C. API testing may require the use of specialized tools.

Acceptance Test-Driven Development (ATDD) enhances both functional and non-functional aspects of the project, providing a collaborative approach to acceptance criteria that developers, testers, and stakeholders agree upon before development begins. Using ATDD alongside TDD (Test-Driven Development) ensures that both the internal system logic and the user-facing features adhere to the specified requirements, thereby increasing the likelihood of delivering a quality product that meets all stakeholders' expectations .

The correct description of continuous testing is that each new build of the system triggers a pre-defined set of tests to be executed automatically. This approach ensures that any changes or additions to the system are immediately validated, helping to catch issues early and streamline the development process .

For a project where the reuse of software components is a key objective, it is essential to ensure that all modules, data, and interfaces are uniquely identified. This facilitates the tracking, maintenance, and reuse of these components in different parts of the software or in other projects. Unique identification helps in preventing confusion and conflicts that may arise due to the reuse of components that have the same name but different functionalities or interfaces.

The term 'isolated' as a characteristic of a unit test means that it should test only the code for which it was originally written. This ensures that the unit test is focused, minimizes dependencies on other parts of the codebase, and errors can be traced back to specific units without ambiguity .

Analyzing the given pseudocode for potential anomalies in data flow:

Declare C, F, Z Decimal Set Z = 32 Read F Set C = (F-Z) * 5/9 Free C, F, Z Print F

The potential anomaly is with variable F. It is used after being freed, which typically indicates an error in managing the variable's lifecycle within the code.

Explanation: Freeing a variable typically indicates that it is no longer available for use, but F is used after this operation, which could result in undefined behavior or errors.

The pseudo code provided for the Price program shows a potential for an infinite loop due to the way the 'Del_Charge' variable is being manipulated. The loop is set to continue 'WHILE Del_Charge > 0', and within the loop, 'Del_Charge' is initially set to 5 and then potentially decreased by 2 if 'Sale_Value > 60000'. However, at the end of each loop iteration, 'Del_Charge' is increased by 1. This means that if 'Sale_Value' is not greater than 60000, 'Del_Charge' will not decrease and will instead increment indefinitely, causing an infinite loop. Even if 'Sale_Value' is greater than 60000, the decrement by 2 could be negated by the subsequent increments if the loop runs enough times, potentially leading to an infinite loop situation. There is no guaranteed exit condition once the loop is entered, which is a control flow anomaly.

Quantitative Questionnaires are the best elicitation technique for questioning a large number of stakeholders specifically to obtain information for non-functional acceptance criteria. This method allows for collecting measurable, numerical data from a broad audience efficiently, which is crucial for understanding and defining non-functional requirements such as performance, scalability, and usability