Software Testing and Quality Center

System testing is conducted by testers or independent teams, not end-users, making option C the false statement. End-users participate in User Acceptance Testing (UAT), which comes after system testing and validates whether the software meets business needs. System testing verifies technical requirements, while UAT validates business requirements from the user's perspective.

Capture and replay tools automate execution of existing test cases. This benefits regression testing the most because regression tests are executed repeatedly across software releases, making automation highly cost-effective compared to one-off tests.

Alpha testing is conducted before release at the developer's site by a limited group of potential users or market representatives. This differs from beta testing, which occurs after alpha at users' own locations with a broader audience. Alpha allows developers to observe and guide testing directly, while beta provides more realistic usage conditions.

A failure is the observable incorrect behavior that occurs when executing software with a fault. Faults (or bugs) are defects in the code that may remain dormant until triggered by specific inputs. Errors are human mistakes that introduce faults. Only failures are directly visible to end-users through incorrect behavior.

Functional system testing validates the entire system's end-to-end behavior against functional requirements, treating it as a black box. Integration testing verifies component interactions (option A), interoperability testing checks external system interfaces (option B), and performance testing measures response times (option C). System testing focuses on what the system does, not how it's built.

Static analysis analyzes code without executing it, finding issues like unused variables, dead code, or syntax violations. Memory leaks typically occur dynamically during runtime execution, making them impossible for standard static analysis to reliably detect.

Acceptance testing validates whether the system meets business requirements and is ready for deployment from a business perspective. Unlike earlier testing phases focused on finding faults, acceptance testing confirms the solution delivers expected business value. It's conducted by business representatives or users, not necessarily all users, and focuses on what the system should do for the business.

Re-testing (or confirmation testing) runs the same test cases to confirm a specific defect is fixed. Regression testing runs tests on unchanged parts of the system to ensure no new defects or side-effects were introduced by changes.

Inspection is the most formal review type, characterized by peer examination, defined entry/exit criteria, formal roles, and collection of metrics. Walkthroughs and management reviews are less formal and lack strict entry/exit metrics.

Reviews and inspections are static testing techniques that examine documentation or code without execution. Like dynamic testing, their purpose is detecting defects and improving quality, making them part of the broader testing discipline. Static testing finds faults earlier and cheaper than dynamic testing, complementing test execution. The testing lifecycle includes both static and dynamic techniques.

Error guessing is an experience-based, informal technique. It is most effective as a complement after formal, systematic techniques (like boundary value analysis) have been applied to ensure no obvious gaps remain uncovered.

Testing should stop when defined exit criteria (completion criteria) are met, ensuring objective quality goals are satisfied. Running out of time or tests is resource-based, not quality-based, and finding no faults may just mean tests are ineffective.

Structural, white box, and glass box all refer to the same testing approach that examines internal code structure and implementation. Functional testing is different: it treats the software as a black box, testing based on inputs and expected outputs without knowledge of internal design. The question tests recognition of equivalent testing terminology.

In HP Quality Center's Test Plan module, deleting a folder does not permanently delete the tests immediately; instead, the tests are moved to the system-created 'Unattached' folder, allowing recovery. They do not go to the Subject folder, and they are not permanently deleted right away.

HP Quality Center integrates directly with HP functional testing tools, specifically HP QuickTest Professional (QTP) and HP WinRunner. HP LoadRunner is a performance testing tool, not a functional testing tool, and HP Openview (misspelled as Operview) is a network management platform.

Quality Center Dashboard provides executive-level visualization with graphs, charts, and summary metrics across the testing lifecycle. Foundation is the backend database, Business Process Insight isn't a QC module, and Service Test is for service testing - none give executive overview.

In the Requirements module, you select requirements and use the 'Cover' or 'Add Test' buttons to link tests to requirements. While you can see requirements on test details, the actual linking happens from Requirements module. Test Lab is for execution, not linking.

Quality Center is fundamentally a repository - it stores and manages test assets (requirements, tests, defects, cycles). 'Testcases' and 'Defects' are items within the repository, not its main function. Load testing is separate functionality.

Parameters make reports reusable - you can run the same report template with different filter values (by date, by tester, by status) for different purposes. Without parameters, each report is hardcoded to one specific view. Saving, naming, and cross-project use aren't parameter advantages.

Quality Center supports enterprise databases - Oracle and Microsoft SQL Server. Access is a desktop database, not supported. Sybase is also not a supported QC database (supported are Oracle, SQL Server, and in some versions, MySQL).