Equivalence Partitioning is a testing technique that divides input data into equivalent partitions (or classes) where test cases can be derived from each partition. This technique is particularly useful for testing input fields with various ranges of values.

Why other options are incorrect:

A. Decision table technique: This technique is useful for testing combinations of inputs but is not specifically focused on ranges of values.

B. Use case Testing: This technique focuses on testing user interactions and scenarios rather than testing input ranges.

D. Decision Testing: This technique involves testing the logical decisions within the code, such as conditions and branches, rather than focusing on input ranges.

Correct Option Explanation:

C. Equivalence partitioning: This technique ensures that you test representative values from each partition, which provides good coverage without the need to test every possible value.

Example:

Consider an input field that accepts ages between 18 and 65:

Equivalence Partitions:

·     Below 18 (invalid)

·     Between 18 and 65 (valid)

·     Above 65 (invalid)

You would create test cases for:

·     A value below 18 (e.g., 17)

·     A value within the range (e.g., 30)

·     A value above 65 (e.g., 66)

By doing so, you ensure that you cover the critical ranges of input values without exhaustive testing.

A. Developers lose the sense of responsibility and independent testers may become a bottleneck: One valid drawback of independent testing is that developers might rely too heavily on testers to find defects, leading to a reduced sense of responsibility for quality. Additionally, if independent testers are not well-integrated into the development process, they can become a bottleneck, slowing down the workflow.

Why other options are incorrect:

B. Developer and independent testing will overlap and waste resources: While some overlap can occur, this is not a typical drawback. Proper coordination usually prevents resource wastage.

C. Independent testers need extra education and always cost more: Although independent testers might require some initial orientation, this is not a significant drawback. Also, the cost is not necessarily higher in the long term if it leads to better quality.

D. Independent testers will become a bottleneck and introduce problems in defect management: Bottlenecks can occur, but independent testers introducing problems in defect management is not a common issue. Proper communication and processes usually mitigate these problems.

Example:

If developers assume that testers will catch all defects, they might become less diligent in their own testing efforts, leading to a dependency on the independent testing team. If the independent testers are not well-aligned with the development timeline, this can delay the release process. Proper integration and communication between developers and testers can help mitigate these issues.

D. Defined entry and exit criteria: The description provides conditions that must be met for the review process to terminate (exit criteria), but it does not mention any entry criteria that need to be fulfilled before the review process begins. Entry criteria are essential to ensure that the review process starts under the right conditions, such as the code being ready for review, the reviewers being prepared, and necessary documentation being available.

Why other options are incorrect:

A. Checklists to be used by the reviewers: Although checklists are useful, the absence of a mention of checklists in the provided conditions does not mean they are entirely missing from the process. The description does not explicitly address the use of checklists, but it does not rule them out either.

B. Deliverables such as reports, evaluation sheets or other review summary sheets: The description focuses on the conditions for terminating the review process but does not preclude the existence of deliverables. These may still be part of the process and not mentioned in this specific description.

C. Metrics for reporting on the review effectiveness, efficiency, and progress: Similar to checklists and deliverables, metrics might still be part of the broader review process even if not detailed in this specific phase description.

Example:

For a formal review process to be thorough and effective, it should include:

·     Entry Criteria: Code readiness, preparation of necessary documents, and allocation of reviewers.

·     Exit Criteria: Conditions like code review completion, defect fixes, and code versioning.

·     Checklists: To ensure all review aspects are covered.

·     Deliverables: Reports, evaluation sheets, and summaries to document the review process.

·     Metrics: To evaluate the effectiveness and efficiency of the review process.

The provided description outlines the exit criteria but lacks entry criteria, which are crucial for ensuring the review process begins under appropriate conditions.

A. Scheduling test analysis and design tasks: Test planning involves defining the scope, approach, resources, and schedule of testing activities. Scheduling test analysis and design tasks is a major part of this process as it lays out the timeline and sequence for when and how test analysis and design will be conducted.

Why other options are incorrect:

B. Initiating corrective actions: This is part of test execution and monitoring phases, where issues are identified and corrective measures are taken, but it is not a primary task of test planning.

C. Monitoring progress and test coverage: This is a major task of test monitoring and control, not planning. It involves tracking the progress of the test execution and ensuring that all test cases are covered.

D. Measuring and analyzing results: This task is part of test execution and evaluation phases. It involves analyzing the outcomes of the tests to determine if the software meets the requirements and if there are any defects.

Example:

During the test planning phase, a test manager would:

·     Define the objectives and scope of testing.

·     Identify the resources needed (e.g., tools, environments, personnel).

·     Create a detailed schedule for when test analysis and design tasks will occur.

·     Determine the test levels and the sequence of testing activities.

This ensures that the testing process is organized, and that all necessary tasks are planned and allocated properly.

i) Investigate the organization's test process: This is essential to understand the current state of testing, identify gaps, and determine how a new tool can improve the process.

ii) Conduct a proof of concept: This helps evaluate the tool in a controlled environment to see if it meets the organization's needs and integrates well with existing processes.

iv) Identify coaching and mentoring requirements for the use of the selected tool: Ensuring that the team is properly trained and supported in using the tool is critical for successful implementation and adoption.

Why other options are incorrect:

iii) Implement the selected tool on a project behind schedule to save time: This is generally a poor practice. Implementing a new tool on a project that is already behind schedule can introduce additional risks and complications, potentially exacerbating delays rather than mitigating them.

Example:

When selecting and implementing a testing tool:

1.    Investigate the organization's test process: Identify current testing methodologies, tools in use, and areas needing improvement. This provides a baseline for what the new tool should address.

2.    Conduct a proof of concept: Before full-scale implementation, test the tool with a small, controlled project to ensure it performs as expected and integrates with existing systems.

3.    Identify coaching and mentoring requirements: Determine the level of training and support needed for the team to effectively use the tool. This may involve setting up training sessions, creating documentation, and providing ongoing support.

By following these steps, the organization can make a well-informed decision on the tool selection and ensure a smoother implementation process.

Decision coverage (also known as branch coverage) measures whether each possible branch (decision) in the code has been executed at least once.

In the given diagram:

·     Node A has two branches: one to B and one to C.

·     Node B leads to D.

·     Node C leads to D.

·     Node D has two branches: one to G and one to E.

·     Node E leads to F.

·     Node F leads to G.

The test case follows the path A → B → D → E → F → G.

Branches covered by this test case:

1.    A → B

2.    B → D

3.    D → E

4.    E → F

5.    F → G

Branches not covered by this test case:

1.    A → C

2.    C → D

3.    D → G

To achieve 100% decision coverage, all possible branches need to be covered. Since the test case does not cover the branches A → C, C → D, and D → G, only 50% of the branches are covered. Thus, the correct answer is 50%.

Why other answers are incorrect:

·     75%: This would require covering 3 out of 4 branches at D and at least one branch from C to D, which is not the case.

·     90%: This would imply covering almost all branches, which is not possible with the given single test case.

·     100%: This requires all branches to be covered, but branches A → C, C → D, and D → G are not covered.

First, let's be clear about the partitions it should be:

 0-4000 ->0%

4001-5500 ->10%

5501-33500 ->22%

33501-infinity ->40%

(notice that the partitions don't share any boundaries with each other) Second, notice that they are asking about values the would fall in the SAME partition so the correct answer would be "£5800; £28000; £32000" as all the values fall under the third partition.

A. The test approach that will be applied at system integration testing: The master test plan includes high-level details of the overall testing strategy, including the test approaches for various levels of testing, such as system integration testing. This provides an overview of how testing will be conducted across different stages.

Why other options are incorrect:

B. A list of the names of the testers who will carry out the performance testing for the final iteration: The master test plan typically does not include specific names of testers. This level of detail is more appropriate for detailed test plans or schedules.

C. A detailed identification of the resources that will carry out structural testing in the first iteration: While resource planning is part of the master test plan, detailed identification of specific resources for particular tasks in specific iterations is typically handled in more detailed planning documents.

D. A description of how the test cases are cross-referenced to requirements in the test management tool: This is more detailed information that would be included in a test design specification or test case specification document rather than in the high-level master test plan.

Example:

The master test plan might outline:

·     The overall test strategy and objectives.

·     The test levels and phases (e.g., unit testing, integration testing, system testing, acceptance testing).

·     The test approach for each phase, such as the methodologies and techniques to be used in system integration testing.

·     High-level resource requirements and schedule.

·     Risk management and mitigation strategies.

It provides a comprehensive view of the testing effort and how it will be managed and executed across the project.

D. Detailed overview of the risk-based test approach being used to ensure the exit criteria to be achieved: A senior manager, who is not a test specialist, would likely not need a detailed explanation of the specific testing methodologies or approaches. This level of detail is too technical and not relevant to their decision-making needs. They are more interested in high-level summaries and actionable insights rather than detailed technical processes.

Why other options are appropriate:

A. Recommendations for taking controlling actions: Senior managers need actionable recommendations to address any issues or risks identified during testing. This helps them make informed decisions to steer the project in the right direction.

B. Status compared against the stated exit criteria: Providing the current status in relation to the exit criteria helps the senior manager understand whether the project is on track to meet its goals and if any criteria are at risk of not being met.

C. Product risks which have been mitigated and those which are outstanding: Highlighting both mitigated and outstanding risks gives the senior manager a clear picture of the project's risk landscape, which is crucial for informed decision-making and prioritization.

Example:

In a test progress report for a senior manager, you would include:

·     High-level summary: Current status of testing activities.

·     Progress against exit criteria: Whether testing is meeting the pre-defined exit criteria.

·     Risks and issues: Key risks that have been addressed and those that still need attention.

·     Recommendations: Suggested actions to mitigate any identified risks or issues.

Avoiding overly technical details ensures that the report is accessible and useful for the senior manager's strategic oversight role.

A. needs configuration management just like requirements, design and code: Testware, which includes test cases and test data sets, is a critical part of the software development process. It needs to be managed and controlled through configuration management to ensure consistency, traceability, and integrity. This allows teams to track changes, maintain versions, and manage dependencies just as they do with other software artifacts.

Why other options are incorrect:

B. should be newly constructed for each new version of the software: This is not practical or efficient. Testware should be reusable across different versions of the software where applicable. Only specific parts may need updates or additions for new features or changes.

C. is needed only until the software is released into production or use: Testware is also needed post-release for maintenance, regression testing, and future updates. It should be preserved and managed throughout the software lifecycle.

D. does not need to be documented and commented, as it does not form part of the released: Proper documentation and comments are essential for understanding and maintaining testware. Even though it is not part of the released product, it is crucial for ongoing testing and quality assurance processes.

Example:

Using configuration management for testware ensures that all team members have access to the latest versions of test cases and test data. It allows for better collaboration and ensures that any changes to the software can be properly tested using the correct test cases and data. This practice is essential for maintaining the quality and reliability of the software product.