Software Testing and Quality Control

Recovery Scenarios are specifically designed to handle unpredictable exceptions during testing, such as unexpected pop-ups, crashes, or object state changes. Do Loop is for controlled iteration, IFTHEN is conditional logic, and Select Case handles multiple conditions. Recovery Scenarios provide event-driven exception handling.

In Quality Center's workflow model, defect addition may be restricted based on project settings, user permissions, and testing lifecycle stage, not universally available from all modules.

After a developer fixes a defect, testers should execute not just the specific test case for that defect but also related test cases to ensure the fix didn't introduce new issues. This is part of regression testing.

Test Analysis and Design is a formal test process phase where requirements and design documents are analyzed to identify test conditions and design test cases. This statement correctly describes activities in that phase.

Test comparators are software testing tools designed to compare actual test execution outputs (such as files, databases, or UI states) against expected results to identify discrepancies.

Retesting checks if a specific defect fix works. Regression testing checks if the fix broke other parts of the system. They are different - retesting is focused on the fixed issue, regression is broader.

Integration testing involves testing the interactions between integrated modules or systems. It can employ both black-box testing (verifying inputs and outputs without seeing internal code) and white-box testing (examining internal logic and code structures). While integration testing is a level of testing rather than a method, it commonly uses both approaches at module interfaces.

Scheme Validation is the recommended QTP functionality to verify object repository XML files conform to the QTP object repository schema. The other terms (Scheme Verification, XML Validation, XML Verification) are not actual QTP features.

Testing cannot prove software has no faults - it can only demonstrate the presence of faults. Complete absence of faults is theoretically impossible to prove through testing alone. Finding faults, building confidence, and identifying performance problems are all valid testing objectives.

State Transition Testing is a black-box technique because it tests the system's external behavior as it transitions between different states without knowledge of internal code structure. The other options are all white-box techniques: Statement Testing examines code execution paths, Path Testing analyzes logical paths through code, and Data Flow Testing tracks how variables are used and defined throughout the code.

The statement is false because Alpha Testing is conducted internally at the developer's site, NOT at the customer site. Alpha testing is performed before release by the development team or internal testers. Beta Testing is the phase that occurs at customer sites after alpha testing is complete. This distinction is important in the software release lifecycle.

Option B is NOT a reasonable test objective because it's impossible to prove software has absolutely no faults - testing can only demonstrate the presence of defects, not their absence (Dijkstra's principle). The other options ARE reasonable: finding faults (A) is testing's primary purpose, giving confidence (C) through thorough testing is valid, and finding performance problems (D) helps ensure quality.

Static white box testing involves analyzing the internal structure, design, and source code of an application without actually running the program. This includes code reviews, inspections, and walkthroughs to identify logic errors or security vulnerabilities early in the development cycle.

Code coverage is a Dynamic White-box testing technique. It requires executing the code with test cases (dynamic) and analyzing the internal structure/branches (white-box). Static analysis examines code without execution, while black-box testing ignores internal structure.