Non-functional testing is testing how the system performs its functionality. Non-functional testing is testing system attributes, such as usability, reliability or maintainability.

Log defects​ is done during the "Fixing and Reporting", ​

Explain the documents to the participants is done during the "Initiate review ",

Gather metrics is done during the "Fixing and Reporting" and ​

Allocate the individual roles is done during the "Panning" phase of the review process.

- Test data preparation tools is related to preparing data for dynamic testing

- Early defect detection is related to early testing which is achieved by static testing

- Scribe is a role in conducting reviews which is a static testing technique

- Compilers is sort of static analysis tools which is a static testing technique

From channel 1 you can not turn the TV off as the Off column says NO on channel 1 (3rd row).

So the "Off from Display Channel 1" is an invalid one.

Meanwhile, you can switch to channel 2 when you are displaying channel 1, you can switch to channel 2 when you are live and you can standby when you are live.

A structured way of error guessing is called “fault attack” where the tester enumerate through a list of possible defects and design tests that attack these defects. The list can be built over time based on tester experience. So the answer is ​Experience, defect and failure data, knowledge about software failures are the best basis for fault attack testing

Exploratory testing is a suitable approach when there are poor specifications or time pressures because it allows testers to be flexible and adaptive, making the most of their knowledge and experience to identify defects quickly without relying on detailed documentation.

Why Option C is Correct:

·     Exploratory Testing: This approach involves simultaneous learning, test design, and test execution. Testers use their creativity and intuition to explore the software, making it ideal for situations with limited or unclear documentation and tight deadlines.

Why Other Options Are Incorrect:

A. Use case testing: This approach relies on use cases derived from specifications to validate the software. If the specifications are poor, use cases might be incomplete or inaccurate, making this approach less effective.

B. White box testing: This approach involves testing the internal structures or workings of an application, which typically requires detailed knowledge of the code. It might not be feasible under time pressures and poor specifications.

D. Specification-based testing: This approach relies heavily on specifications to derive test cases. With poor specifications, this method would struggle to define accurate and comprehensive test cases.

Example:

·     Exploratory Testing Scenario: Given a new feature in an application with vague requirements and a tight deadline, a tester uses exploratory testing to quickly interact with the feature, identifying key functionalities and potential issues without needing detailed test scripts or specifications.

Exploratory testing allows testers to adapt and focus on finding defects efficiently, making it the best approach under poor specifications or time constraints.

The scenario describes a defect found and fixed, followed by verification and additional testing to ensure the fix works correctly and that the code is robust. The types of testing mentioned are:

Why Option C is Correct:

·     Functional Testing: This is implied by the testing of the system’s response to network disconnection, which is a functional aspect of the system.

·     White Box Testing: The mention of 100% statement coverage indicates that the internal code structure was tested, which is characteristic of white box testing.

·     Re-testing: After fixing the defect, the code is re-tested to verify that the fix works, which is re-testing.

Why Other Options Are Incorrect:

A. i, ii and iv: Performance testing is not mentioned or implied in the scenario. The focus is on functional correctness and code coverage.

B. i and iii: This omits white box testing, which is indicated by the statement coverage.

D. i, iii and iv: Again, performance testing is not relevant to the described scenario.

Example:

·     Functional Testing: Verifying that the system properly handles network disconnection without crashing.

·     White Box Testing: Ensuring that all statements in the code are covered by tests, indicating thorough internal testing.

·     Re-testing: Running the same tests after fixing the defect to ensure the issue is resolved.

This ensures a comprehensive approach to validating the defect fix and improving the overall quality of the software.

TC 1 triggers rule 6 (standard class flexible ticket and rail card holder) so generates the actions eligible for upgrade and concessionary fare but does not authorize the holder to travel.

TC 2 triggers rule 7 because James holds a railcard but has a super saver ticket, so is not eligible to use the service.

Deriving test cases from use cases focuses on the interactions between the user and the system, as well as the interactions between different components of the system. This approach is particularly beneficial for certain types of testing.

Why Option D is Correct:

I. Deriving test cases from use cases is helpful for system and acceptance testing: Use cases describe the system's behavior from an end-user perspective, which makes them ideal for designing system and acceptance tests to ensure the system meets user requirements.

IV. Deriving test cases from use cases is helpful for testing the interaction and interference between different components: Use cases often involve multiple components interacting to fulfill a user scenario, making them useful for testing the interactions and integration of these components.

Why Other Options Are Incorrect:

II. Deriving test cases from use cases is helpful only for automated testing: This is incorrect because use case-derived test cases can be used in both manual and automated testing.

III. Deriving test cases from use cases is helpful for unit testing: Use cases are typically higher-level and focus on user interactions and system behavior, which is not the primary focus of unit testing. Unit testing is more concerned with testing individual components or functions in isolation.

Example:

·     System Testing: Use cases help create test scenarios that validate the system as a whole, ensuring it behaves correctly from the user's perspective.

·     Component Interaction Testing: Use cases can reveal how different components need to work together, and test cases derived from them can ensure these interactions are correctly implemented.

By focusing on user interactions and component integrations, use cases provide a comprehensive approach to testing, making option D the correct choice.