ISTQB Foundation Sample Question Paper No. 2

To effectively choose a test tool, it is crucial to first analyze your needs and requirements. This step allows you to identify the specific functionalities and features that are essential for your testing process. By understanding your requirements, you can narrow down your options and focus on tools that align with your needs. This approach ensures that you select a tool that will effectively address your testing challenges and improve your overall testing efficiency.

Reviews and inspections can be considered part of testing because they help detect faults and improve the quality of the software being developed. Reviews and inspections involve examining the documentation, code, or other artifacts to identify defects, errors, or areas for improvement. By identifying these issues early on, it helps in improving the overall quality of the software and reduces the likelihood of defects being present in the final product. Therefore, reviews and inspections are an important part of the testing process.

Re-testing refers to running a test again to ensure that the previously identified faults have been fixed. On the other hand, regression testing aims to identify any unexpected side effects that may have been introduced as a result of fixing the faults or making changes to the software. Therefore, the correct answer explains that re-testing involves running a test again, while regression testing focuses on identifying unexpected side effects.

Non-functional system testing refers to the testing of quality attributes of a system, such as performance and usability. This type of testing focuses on evaluating how well the system performs under different conditions and how user-friendly it is. It helps identify any issues or weaknesses related to the system's performance, responsiveness, scalability, and overall user experience. By conducting non-functional system testing, organizations can ensure that their system meets the required standards and delivers a satisfactory user experience.

A failure refers to a situation where the visible behavior of a system deviates from what is expected or specified by the end-users. It implies that the system is not functioning correctly or as intended. This can occur due to various reasons such as errors, faults, defects, or mistakes in the system. However, a failure specifically highlights the discrepancy between the expected and actual behavior, indicating that something has gone wrong in the system's performance.

When expected results are specified in advance, it becomes easier to determine whether the system or component being tested is functioning correctly. It allows for clear criteria to be set, ensuring that the testing process is focused and efficient. Having specified expected results in advance also helps in identifying any deviations or discrepancies from the desired outcome, enabling prompt resolution of issues. Therefore, specifying expected results in advance is considered the most useful approach in testing.

As the product moves towards live use, the cost of fixing a fault increases. This is because any issues or faults discovered during the testing phase or after the product has been deployed can have a significant impact on the user experience, reputation, and overall success of the product. Fixing these faults may require additional resources, time, and effort, which can be more expensive compared to identifying and fixing them earlier in the development process. Therefore, it is crucial to address and resolve faults as early as possible to minimize costs and ensure a smooth product launch.

Beta testing is a type of testing where customers use the software at their own site, outside of the software developer's location. This allows customers to test the software in their own environment and provide feedback on its performance, usability, and any issues they encounter. Beta testing is typically done towards the end of the software development lifecycle to gather real-world feedback before the software is released to the general public.

Auditing conformance to ISO9001 is not part of configuration management because ISO9001 is a quality management standard that focuses on ensuring consistent quality in products and services. Configuration management, on the other hand, is a process that involves managing and controlling changes to a system's configuration items, such as hardware, software, and documentation. While auditing and quality management are important aspects of overall project management, they are not specifically related to configuration management.

LCSAJ stands for Linear Code Sequence and Jump, which is a white box testing technique used to test the flow of control within a program. It involves testing all possible linear sequences of executable statements and jumps within a program. Unlike black box techniques such as equivalence partitioning, state transition testing, syntax testing, and boundary value analysis, LCSAJ requires knowledge of the internal structure and logic of the program being tested. Therefore, LCSAJ is not a black box technique.

Recovery testing is not part of performance testing. Performance testing involves measuring response time, transaction rates, simulating many users, and generating many transactions to assess the system's performance under different loads. Recovery testing, on the other hand, focuses on testing the system's ability to recover from failures or disruptions. It checks how well the system can recover its data and functionality after a crash, power outage, or other unexpected events. While recovery testing is an important aspect of overall system testing, it is not specifically related to performance evaluation.

The information that need not be included in a test incident report is how to fix the fault. A test incident report is used to document and communicate the details of a defect or issue found during testing. It typically includes information such as how to reproduce the fault, test environment details, severity and priority of the issue, and the actual and expected outcomes. However, the report does not need to provide instructions on how to fix the fault, as that is typically the responsibility of the development or maintenance team.

Error guessing is best used after more formal techniques have been applied. This means that error guessing should not be the primary approach to deriving test cases. Instead, it should be used as a supplementary technique after other more structured and systematic methods have been used. This is because formal techniques such as boundary value analysis, equivalence partitioning, and decision tables are more reliable and comprehensive in identifying test cases. Error guessing can then be used to uncover additional defects or issues that may not have been identified by the formal techniques.

Developers typically use static analysis (i) to analyze code for potential errors or vulnerabilities, dynamic analysis (iv) to analyze code behavior during runtime, and test data preparation (vi) to create test cases and input data. On the other hand, an independent test team typically uses performance testing (ii) to assess system performance, test management (iii) to plan and organize testing activities, test running (v) to execute test cases, and test data preparation (vi) to create test cases and input data.

The purpose of test completion criteria in a test plan is to plan when to stop testing. This criteria helps in determining the point at which testing activities can be considered complete, based on certain predefined conditions or objectives. It ensures that testing is not continued indefinitely and helps in managing resources and time effectively. By setting specific criteria, such as achieving a certain level of test coverage or meeting specific quality standards, the test team can determine when it is appropriate to conclude testing activities.

Inspection is a formal review process that involves comparing documents with predecessor documents. This means that inspection requires the existence of written documents to be compared. Therefore, the statement "inspection is appropriate even when there are no written documents" is not true.

Testing should be stopped when it depends on the risks for the system being tested. This means that the decision to stop testing should be based on the level of risk associated with the system. If the risks are deemed acceptable or within the tolerance level, testing can be stopped. However, if the risks are high or there is a potential for severe consequences, testing should continue until the risks are mitigated or reduced to an acceptable level. This ensures that the system is thoroughly tested and any potential issues are identified and addressed before deployment.

Acceptance testing is a type of testing that is performed to ensure that the system meets the business requirements and is acceptable to all users. It focuses on testing the system from a business perspective, ensuring that it meets the needs and expectations of the stakeholders. This type of testing aims to validate the system's functionality, usability, and overall suitability for the intended business use. It involves testing the system against the business requirements, user scenarios, and expected outcomes to ensure that it performs as expected and satisfies the business needs.

Regression testing should be performed after the software has changed and when the environment has changed. This is because regression testing is done to ensure that the changes made to the software do not introduce any new bugs or issues and that the existing functionality still works as expected. Therefore, it is important to perform regression testing after any changes have been made to the software to catch any potential regressions. Additionally, regression testing should also be done when the environment has changed to ensure that the software functions correctly in the new environment.

A static analysis tool would be the best option for finding unreachable code. Unlike code reviews or inspections which rely on human analysis, a static analysis tool can automatically scan the code and detect any sections that are not being executed. It can identify code that is unreachable due to conditional statements, loops, or other control flow structures. This makes it a more efficient and reliable method for identifying and removing unreachable code from a codebase. Coverage tools and test management tools are more focused on measuring test coverage and managing test cases, so they may not be as effective in identifying unreachable code.

The main purpose of the integration strategy for integration testing in the small is to specify which modules to combine when and how many at once. This means that the strategy outlines a plan for integrating different modules of the software system, determining the order in which they should be combined and the number of modules that should be integrated at a given time. This helps in managing the complexity of integration testing and ensures a systematic approach to combining modules for testing purposes.

The expression that best matches the given characteristics or review processes is s=4 and 5, t=3, u=2, v=1. This is because the process is led by a trained moderator or leader (s=4) and also uses entry exit criteria (s=5). It is undocumented (t=3) and there is no management participation (u=2). Additionally, the process involves a walkthrough (v=1).

The given answer, 10000, 50000, 99999, is a result of designing tests for valid equivalence classes and valid boundaries. These inputs cover the lower boundary (10000), an equivalence class within the valid range (50000), and the upper boundary (99999) of the order numbers on the stock control system. By testing these values, we can ensure that the system handles both the minimum and maximum values correctly, as well as a representative value within the valid range.

A typical commercial test execution tool is capable of performing various tasks such as replaying inputs, comparing expected outcomes with actual outcomes, recording test inputs, and reading test values from a data file. However, generating expected outputs is not a function typically performed by these tools. This task usually requires human intervention and expertise to determine the expected outputs based on the test inputs and the system under test.

The Test Plan document of the Test Documentation Standard includes various components such as test items, what is not to be tested, test environments, and schedules and deadlines. Quality plans, on the other hand, are not typically included in the Test Plan document. Quality plans are separate documents that outline the overall quality objectives and strategies for the project, whereas the Test Plan document focuses specifically on the testing activities and approach. Therefore, the correct answer is Quality plans.

Early test design can prevent fault multiplication by identifying and addressing potential faults early in the development process. It can also find faults that may have been overlooked during requirements analysis. Additionally, early test design can cause changes to the requirements as faults are discovered and addressed. However, faults found during early test design are not necessarily more expensive to fix, and early test design does not necessarily require more effort.

A test management tool is a tool that supports traceability, recording of incidents, and scheduling of tests. It helps in managing the entire testing process by providing features such as test planning, test case creation, test execution tracking, defect management, and reporting. This tool helps in organizing and coordinating testing activities, ensuring that all necessary tests are executed and documented, and providing visibility into the testing progress and results.

The given code snippet has 4 statements: "Switch PC on", "Start 'outlook'", "IF outlook appears THEN", and "Close outlook". To achieve statement coverage, at least one test is needed that executes all 4 statements.

The code also has 2 branches: one branch for the "IF outlook appears THEN" statement, and one branch for the "Close outlook" statement. To achieve branch coverage, at least 2 tests are needed: one test that executes the "IF outlook appears THEN" branch and another test that executes the "Close outlook" branch.

Therefore, the correct answer is "1 test for statement coverage, 2 for branch coverage".

Test managers should not re-allocate resources to meet original plans. This means that they should not change or adjust the allocation of resources in order to adhere to the original project plans. This could potentially disrupt the project and lead to delays or other issues. It is important for test managers to report on deviations from the project plan, sign the system off for release, raise incidents on faults they have found, and provide information for risk analysis and quality improvement.

Top-down integration testing is not part of system testing because it is a type of integration testing. System testing focuses on testing the entire system as a whole, ensuring that all components work together correctly. It includes various types of testing such as business process-based testing, performance testing, requirements-based testing, and usability testing. Top-down integration testing, on the other hand, is a specific approach to integration testing where higher-level modules are tested first before lower-level modules are integrated. Therefore, it is not considered a part of system testing.

BS7925-1 is the correct answer because it is a standard that specifically focuses on testing terms and provides definitions for them. ISO/IEC 12207 is a standard for software life cycle processes, not specifically for testing terms. BS7925-2 is a standard for software component testing, not for testing terms. ANSI/IEEE 829 is a standard for software test documentation, not for testing terms. ANSI/IEEE 729 is not a recognized standard for testing terms. Therefore, BS7925-1 is the most appropriate standard for providing definitions of testing terms.

The statement that expected outcomes are defined by the software's behavior is false. Expected outcomes are not solely determined by the software's behavior, but rather they are derived from a specification. The behavior of the software is just one factor that contributes to the expected outcomes, which also include outputs to a screen, changes to files and databases, timing constraints, and other specifications outlined in the testing process.

The correct answer is "test specification". The IEEE 829 test plan documentation standard includes test items, test deliverables, test tasks, and test environment. However, it does not include a specific section for test specification. Test specification is typically included in the test plan, but it is not explicitly mentioned in the IEEE 829 standard.

Static analysis is a method used to analyze code without actually executing it. It can detect certain issues like the use of a variable before it has been defined, unreachable code, the re-definition of a variable before it has been used, and array bound violations. However, static analysis cannot determine whether the value stored in a variable is correct. It can only identify potential issues based on the code structure and syntax, but cannot verify the correctness of the values assigned to variables during runtime.

The code has two if statements. For statement coverage, we need to test both if statements, so only one test is required. For branch coverage, we need to test both the true and false branches of each if statement. The first if statement has two branches (P+Q > 100 is either true or false), and the second if statement has two branches (P > 50 is either true or false). Therefore, a total of two tests are required for branch coverage.

The given code has two branches: one for the "IF" statement and one for the "ELSE" statement. To achieve branch coverage, we need to test both branches. Therefore, we need 2 tests for branch coverage. Additionally, the code has four statements: the "IF" statement, the assignment statement for C = A - B, the assignment statement for C = A + B, and the "Print" statement. To achieve statement coverage, we need to test all four statements. Therefore, we need 2 tests for statement coverage.

"Otherwise" means ELSE...the next "IF" is therefore a nested IF

When a new testing tool is purchased, it should be used first by everyone who may eventually have some use for the tool. This is because different individuals or teams may have different requirements and perspectives on how to best utilize the tool. By involving all potential users from the beginning, it allows for a comprehensive understanding of the tool's capabilities and limitations. It also promotes collaboration and knowledge sharing among team members, ensuring that the tool is utilized effectively across the organization. Additionally, involving all potential users early on can help identify any issues or challenges that may arise during implementation, allowing for timely resolution.

The statement "black box design techniques all have an associated measurement technique" is false. Black box design techniques focus on testing the functionality of a component without considering its internal structure or implementation details. These techniques do not necessarily have an associated measurement technique because they are primarily concerned with the inputs and outputs of the component. Measurement techniques are more commonly associated with white box design techniques, which involve testing the internal structure and implementation of the component.

The correct answer is i and v are true, ii, iii and iv are false. This means that incidents may not be raised against documentation, and incidents should be raised when someone other than the author of the software performs the test. However, an incident may be closed without being fixed, the final stage of incident tracking is not fixing, and the incident record does include information on test environments.