Software Testing and Quality Control

Testing should be stopped based on risk assessment for the system being tested, not simply because all tests are done, time is up, or faults are fixed. Risk-based testing considers the cost of remaining defects versus the cost of additional testing. Even with all planned tests run, high-risk areas may need more testing.

Early test design (i) prevents fault multiplication by catching issues before they propagate, (iii) finds faults in requirements and design, and (iv) can cause requirement changes when testability issues emerge. Statement (ii) is false because early faults are CHEAPER to fix, not more expensive. Statement (v) is false as early design reduces overall effort.

Non-functional testing evaluates quality attributes of a system rather than specific functional behaviors. This includes properties like performance, usability, reliability, security, and scalability. The distractors incorrectly define non-functional testing as testing for functional bugs or isolating specific software features for functional execution.

Incidents can be closed without being fixed if they are duplicates or invalid (i), and incidents must be raised during independent testing (v). However, incidents can be raised against documentation (ii), the final stage is closure (iii), and incident records must contain environment details (iv), making the other options incorrect.

Statement coverage requires every statement to be executed at least once. With test values P=60, Q=50, both IF conditions are true and all 4 statements execute, achieving statement coverage in 1 test. Branch coverage requires both true and false outcomes for each decision. There are 2 IF statements (branches): P+Q>100 and P>50. The second branch (P>50) is only reached when the first is true. With P=60, Q=50 both are true; with P=30, Q=40 both are false. Thus 2 tests achieve full branch coverage.

One test case where the IF condition evaluates to True is sufficient to execute all statements. However, for full branch coverage, a second test case where the condition evaluates to False is required to cover the implicit else branch, making one test for statement coverage and two for branch coverage correct.

Before selecting a test tool, you must first understand what problems you need it to solve. Analyzing needs and requirements includes identifying what types of testing you do, what features you need, what skills your team has, and what constraints exist. Attending exhibitions, vendor demos, or checking budget are all steps that happen AFTER you know what you need. Buying a tool without analyzing needs leads to shelfware.

When introducing a new testing tool, it should be used by everyone who may eventually use it, not just a small pilot team. This approach helps identify diverse use cases across different roles, uncovers a wider range of issues early, and builds organizational buy-in. A small team might not discover limitations that would affect other users, and vendor contractors don't understand your testing context like your own team does.

Black box techniques test software without examining internal code structure. Equivalence partitioning, state transition testing, and syntax testing are all black box techniques - they focus on inputs, outputs, and external behavior. LCSAJ (Linear Code Sequence and Jump) is a white box structural testing technique that requires analyzing code paths, branches, and control flow within the program's source code.

Beta testing is performed by actual users or customers at their own location using the software in their real environment. This differs from alpha testing (done at the developer's site) and allows testing in diverse, real-world conditions. Independent test teams typically perform system or acceptance testing, not beta testing. Beta testing is particularly valuable for commercial software rather than bespoke/custom software.

Developers focus on code-level testing, making static analysis and dynamic analysis tools typical for their workflow. The test team focuses on system-level verification, meaning they rely on test management, performance testing, test running, and test data preparation tools to design, execute, and monitor comprehensive test suites.

Acceptance testing focuses on validating whether the system meets business requirements and is acceptable for release from a business perspective. It is not primarily about finding faults (that's system testing) or ensuring acceptability to all users (impractical). Testing with other systems is integration testing. The key is business validation - does this system deliver the expected business value?

This question asks for the FALSE statement about component testing standards. The statement that black box design techniques all have associated measurement techniques is false. In practice, not every design technique has a corresponding measurement technique. The relationship is not symmetric or complete - while measurement techniques exist for some design approaches, there isn't a one-to-one mapping for all techniques.

Test execution tools can record test inputs, replay them according to scripts, and compare expected vs actual outcomes. However, they cannot automatically generate expected outputs - this requires human knowledge of what the correct results should be. Expected outcomes must be specified by testers or derived from specifications. The tool automates execution and verification, not test design.

Re-testing focuses on running the exact same tests to verify that a specific defect has been fixed. Regression testing ensures that changes or fixes have not introduced new side effects or broken unmodified parts of the system.