Software Testing Fundamentals

Finding faults during planning is most cost‑effective because defects detected early require minimal rework. Later activities like design, execution, or exit‑criteria checks are progressively more expensive, and the other choices do not offer the lowest remediation cost.

Verification checks that the product is built correctly according to specifications—"building the system right". It is not about building the right system (validation), nor is it defined by who performs it, making the other options inaccurate.

Cyclomatic Complexity measures the number of independent paths through code by counting decision points (predicates). It's calculated from the control flow graph, requiring knowledge of the code structure, making it a white-box testing technique. Black-box testing (B) doesn't examine code structure. Green and yellow box are not standard testing categories.

White box, glass box, and structural testing all refer to the same approach: testing based on knowledge of internal code structure. Functional testing (D) is black-box testing: it tests based on requirements and external behavior without examining the code, making it the odd one out.

A walkthrough is led by the author who presents the work, while an inspection is a formal peer review led by a trained moderator who follows a defined process. The other statements invert roles or claim no leader, which does not reflect the standard definitions.

To understand the question, the user needs to know that the cost of fixing a fault refers to the amount of money and resources that are required to correct an error or mistake in a product or system. It is important to minimize the cost of fixing faults in order to create a high-quality product that is efficient and effective.

Now, let's go through each option and explain why it is right or wrong:

A. Is not important: This option is incorrect. The cost of fixing a fault is important because it affects the overall quality and cost of the product. The more faults that need to be fixed, the greater the expense and the longer it will take to develop and release the product.

B. Increases as we move the product towards live use: This option is correct. As a product moves closer to live use, the cost of fixing faults increases. This is because the product is closer to being released to the public, and any faults or issues that are discovered at this stage will require more resources to fix. It is important to catch and fix faults early in the development process to minimize these costs.

C. Decreases as we move the product towards live use: This option is incorrect. The cost of fixing faults decreases as we move further away from live use, not towards it. This is because the product is still in the development stage and changes can be made more easily and at a lower cost at this point.

D. Is more expensive if found in requirements than functional design: This option is partially correct. It is generally more expensive to fix faults that are found in the requirements stage than in the functional design stage. This is because fixing a fault in the requirements stage may require significant changes to the product, while fixing a fault in the functional design stage may only require minor adjustments.

E. Can never be determined: This option is incorrect. While it may be difficult to determine the exact cost of fixing a fault, it is possible to estimate it based on the resources and time required to make the necessary changes.

Therefore, the correct answer is:

The Answer is: B

Error guessing is applied after formal techniques such as boundary value analysis or equivalence partitioning have been used, because it relies on tester intuition to uncover hidden defects. It is not the first approach, nor is it limited to inexperienced testers, post‑production use, or end‑user activities, which makes those options incorrect.

Incremental integration tests and integrates components gradually, making defects easier to identify and isolate when they surface. Big bang integrates everything simultaneously, making it extremely difficult to determine which component caused a problem. Options B and C are incorrect: big bang isn't limited to real-time applications, and incremental works for both top-down and bottom-up. Option D describes a potential risk of poor component testing, not an advantage.

A test strategy provides a structured approach to testing that ensures comprehensive coverage and risk mitigation. Option D is most correct because it emphasizes the critical business impact and potential consequences of software failure - including financial loss, reputational damage, and safety risks. While options A, B, and C describe valid benefits of test planning, option D addresses the fundamental reason testing exists: to prevent serious negative outcomes. A proper test strategy aligns testing effort with business risk and provides stakeholder confidence in system reliability.

The statement that component testing does not involve regression testing is false. Regression testing can and should occur at the component level when changes are made to a unit or module. After fixing a defect during component testing, re-running related tests ensures the fix hasn't broken other functionality within that component. Component testing (also called unit or module testing) is typically performed by developers, should have planned completion criteria, and includes both new testing and regression testing for maintained code.

Testing activities should begin as early as possible in the development lifecycle to catch defects early, aligning with the chosen answer. The other timings are either too late or impractical.

Testing provides measurable quality information and helps improve software quality, which is why it is necessary. The selected statement reflects this purpose accurately.

Black‑box testing ignores the internal code, while white‑box testing uses knowledge of the source code. The chosen option accurately captures this distinction, making it correct.

Functional system testing verifies that the system's components work together correctly when integrated. Option B is correct because it focuses on the collaborative functioning of system components. Option A describes system integration testing (testing with external systems). Option C describes end-to-end testing which is broader than component interaction. Option D describes non-functional testing (performance testing). Functional system testing specifically validates that the functional requirements are met through proper interaction between components that comprise the system.

Re-testing (confirmation testing) specifically checks that the reported defect has been fixed - it reruns the failed test case after the fix. Regression testing looks for unintended side-effects - it checks whether the fix has broken other previously working parts of the system. They serve different purposes: re-testing validates the fix worked; regression testing ensures no new defects were introduced. Option A correctly captures this distinction. Options C and D incorrectly attribute timing or personnel differences that aren't inherent to these concepts.

The decision to stop testing depends on risk assessment; it isn’t solely based on time, completed tests, or fixed faults. Therefore, the risk‑based option is the correct choice.

Parallel testing compares the output of a new system against the current system’s output to verify correctness, which is exactly the definition provided. The other choices describe unrelated concepts, so the marked answer is correct.

To solve this question, the user needs to understand the difference between functional and non-functional testing. Functional tests evaluate the behavior of a system or component against the specifications, while non-functional tests evaluate the non-behavioral aspects of a system or component such as its performance, reliability, and usability.

Now, let's go through each option and determine which ones contain only non-functional tests:

A. Interoperability (compatibility) testing, reliability testing, performance testing: This option contains both functional and non-functional tests. Interoperability and compatibility testing is a type of functional testing, while reliability and performance testing are non-functional tests.

B. System testing, performance testing: This option contains both functional and non-functional tests. System testing is a type of functional testing, while performance testing is a non-functional test.

C. Load testing, stress testing, component testing, portability testing: This option contains only non-functional tests. Load testing and stress testing are non-functional tests that evaluate the performance of a system under different loads and stress levels. Component testing is a type of functional testing that evaluates the behavior of individual components, but portability testing is a non-functional test that evaluates the ability of a system to run on different hardware and software platforms.

D. Testing various configurations, beta testing, load testing: This option contains both functional and non-functional tests. Testing various configurations and beta testing are types of functional testing, while load testing is a non-functional test.

Therefore, the answer is: C. Load testing, stress testing, component testing, portability testing.

Test execution monitoring requires metrics that show testing progress and results in real-time. Option D is correct because test cases run/not run and passed/failed are direct execution metrics that indicate: what portion of planned testing is complete, and what portion of executed tests passed. These metrics help track progress, identify blockages, and assess product quality during execution. Options A, B, and C describe useful metrics but they're either post-execution (residual defects), planning-phase metrics (test case preparation), or cost tracking rather than execution monitoring.

Black box testing techniques design tests based solely on inputs and expected outputs, without knowledge of internal code structure. Option B is correct because equivalence partitioning, state transition testing, and decision table testing are all black box techniques - they analyze external behavior. Options A, C, and D incorrectly mix in white box techniques (code testing) or test levels/types (system testing, integration testing, acceptance testing) which describe when testing occurs rather than how tests are designed. Black box focuses on what the system does rather than how it's implemented.