Quality Center and Test Automation Frameworks

Data-Driven Framework separates test data from test logic - input/output values come from data files (A), and only test data resides in those files (D). Test logic remains in scripts, making B false. Keywords are central to keyword-driven frameworks, not data-driven (C false).

A hybrid framework combining Keyword and Data Driven approaches allows test cases (keywords/steps) and test data to be stored together in external data files, separating test logic from the execution engine.

Data-driven testing has maintainability challenges (A) because each test case needs separate data files. Finding specific data files (B) is difficult as test suites grow. Error tracing (D) is harder during unattended runs, especially when recovery scenarios activate. Extensibility (C) isn't inherently worse - scripts can be as extensible as other frameworks.

Keyword Driven Frameworks make tests readable like manual test cases (A true). They don't require extensive tool training because testers only need to learn keywords, not the underlying tool (B false). The test plan can indeed be structured in spreadsheets with input and verification data (C true). Testers primarily learn keywords and the test plan format (D true). Options A, C, and D are correct.

A Hybrid Framework combines multiple framework types (B true). It includes core components like Data Driven Engine, Component Functions, and Support Libraries (C true). The App Map bridges the automation framework with the application being tested (D true). Option A is incorrect because hybrid frameworks are widely used, not limited.

Mercury (HP) QTP was built on the fundamental Record & Playback capability. While Mercury later promoted Keyword Driven Framework as the best practice, the question asks what framework they 'modeled' - referring to the core automation approach built into the tool itself. The most basic framework type is Record & Play, which captures user interactions exactly as performed.

Test Automation Frameworks are designed to be tool-independent in their architectural principles. A framework provides structure, methodology, and organization patterns that can work across different automation tools. While implementation may use specific tools, the framework concept itself is about methodology and best practices, not tool dependency.

A complete Test Automation Framework includes all these structural components: directory organization (A) for maintainability, function libraries (B) for reusable code, object repository/app map (C) for element abstraction, scenario files (D) for test cases, driver scripts (E) for execution flow, and sequence files (F) for test ordering. Each component addresses a specific framework need.

Model-Based Testing framework specifically requires creating and maintaining models (often UML diagrams) that represent the system under test. The tests are then generated or derived from these models. This is distinct from modularity-driven frameworks that focus on code structure or context-based frameworks that organize by business context.

Quality Center displays records in the order they were created or entered by default - this is the natural insertion order. Increasing or decreasing order would require explicit sorting by some field, which is not the default behavior.

Quality Center's alerting functions include automatic notification alerts (triggered by events) and follow-up alerts (for tracking). While email alerts exist in later versions, the question focuses on the core two types listed in option A.

The two methods are 'Convert Requirements to Tests' (batch conversion) and 'Generate a Test from Requirements' (individual test creation). Options B and D use 'Convert a Test' which is backward - you don't convert tests from requirements. Option C reverses the direction.

Within the Requirements module, traceability links are created between requirements (parent-child relationships). Test Cases, Tests, and Defects belong to other modules and are linked differently through cross-module traceability.

Quality Center assigns .jpg extension to screenshots and images uploaded to the system. While .jpeg is technically the same format, QC specifically uses the .jpg extension in its naming convention.

In Quality Center's Requirements module, requirement topics are organized hierarchically in a tree structure - called the Requirements tree. This allows parent-child relationships and nested organization of requirements.

F9 is the shortcut key to access the Requirements menu bar in Quality Center's Requirements module. This is application-specific keyboard mapping (varies by QC version).

Comparing the defect counts: Test Object A has X defects, B has 145% of X (1.45X), and C has 120% of X (1.20X). Since Test Object B has the highest number of defects (1.45X > 1.20X > X), it potentially has more undiscovered issues and should be given more testing attention.

Testing should be stopped when the predefined exit criteria are met, which typically include coverage metrics, defect density, and schedule constraints. Stopping based solely on project manager decisions, budget depletion, or finding no more defects is subjective and does not guarantee quality.

Quality Center (now HP Application Lifecycle Management/ALM) is fundamentally a central repository that stores and manages all testing artifacts - test cases, requirements, defects, and test results. The repository function is its core purpose - providing version control, traceability, and centralized access to the entire testing ecosystem.

HP WinRunner (legacy functional testing tool) and HP QuickTest Professional (QTP, now UFT) are both functional testing tools that integrate directly with Quality Center for test storage, execution, and defect reporting. LoadRunner is for performance testing, not functional testing. HP OpenView is network management software, unrelated to Quality Center.