QTP and Quality Center Testing

Error guessing is an experience-based test design technique where testers use their intuition to guess where defects might exist. It supplements formal techniques by leveraging domain knowledge and past defect patterns. It is NOT limited to specific test levels (B is wrong), NOT exclusive to UAT (C is wrong), and IS repeatable as a technique (D is wrong).

Regression testing involves re-running previously executed tests to verify that recent code changes haven't adversely affected existing functionality. Test capture/replay tools record manual test interactions and play them back automatically, making them ideal for repeated regression cycles. Integration and system testing can benefit too, but regression requires the most frequent re-execution.

A testable requirement must be specific, measurable, and verifiable. Option C is testable because it specifies a concrete performance threshold (less than 1 second) under defined conditions (specified design load). Options A (user-friendly) and D (portable) are subjective with no clear pass/fail criteria. Option B (0 faults) is theoretically untestable because proving absolute zero requires infinite testing.

Risk-based testing prioritizes test effort based on the likelihood and impact of failures. High-risk areas (critical functionality, complex logic, frequently changed code) deserve priority because defects there cause the most harm. While coverage and fault counts matter, they're secondary to targeting areas where failures would be most damaging.

System testing evaluates the integrated system against requirements. It's typically performed by independent test teams (A is true), uses more functional than structural techniques (B is true), and faults found late are expensive to fix (C is true). However, end-users participate in USER ACCEPTANCE TESTING, not system testing (D is the false statement). System testing precedes UAT.

Quality Center test management involves five phases: Specify Requirements, Plan Tests, Execute Tests, Track Defects, and Specify Releases. These phases form the complete test management lifecycle from requirements through defect tracking and release management.

The correct order of Quality Center test management phases is: Specify Releases (defining the release cycle), Specify Requirements (documenting what to test), Plan Tests (designing test cases), Execute Tests (running the tests), and Track Defects (managing bugs). This sequence follows a logical flow from release planning through defect management.

Quality Center allows you to define multiple filter items to display only records that meet your specified criteria. You can create complex filters using multiple conditions, not just single or limited items, providing flexible data filtering capabilities.

In QTP (QuickTest Professional/UFT), the shortcut key SHIFT+ALT+F3 is used to start and stop analog recording mode. This mode captures actual mouse movements and keyboard operations at the screen coordinate level, useful for testing applications that QTP cannot recognize at the object level.

The Object Repository in QTP/UFT stores test objects along with their properties and values. This centralized storage allows tests to reference objects without hardcoding property values, making tests more maintainable. When object properties change in the application, you only need to update them in the Object Repository.

GetROProperty (Get Run-Time Object Property) in QTP/UFT retrieves the current property value of an object during test execution. This differs from GetTOProperty which retrieves test object properties from the Object Repository. RO properties reflect the actual state of the application at runtime.

In QTP/UFT, the F12 key is the shortcut for inserting a Standard Checkpoint. Checkpoints are verification points that compare actual values with expected values. Standard Checkpoints verify object properties and values during test execution.

A Text Area Checkpoint in QTP/UFT verifies that a specific text string is displayed within a defined area in a Windows application. Unlike standard Text Checkpoints which verify text anywhere on an object, Text Area Checkpoints check for text within specified screen coordinates or a rectangular region.

The same QTP (QuickTest Pro) code CAN access session objects of different browsers using descriptive programming or by creating separate browser/session objects. The limitation is not inherent to QTP - it's about how you design your automation framework.

Descriptive programming does NOT guarantee cross-browser compatibility. While it helps with object identification without repository dependencies, browsers render differently and some elements have browser-specific properties or behaviors. Additional handling is often needed for genuine cross-browser compatibility.

The statement claims that .Object method is not applicable in Firefox, which is false. Firefox supports standard JavaScript object methods like those on Object.prototype (toString, hasOwnProperty, etc.). The question likely refers to a proprietary IE-specific method, but as written, False is the correct answer.

QTP code written for IE generally cannot execute on Firefox without modifications because browsers have different DOM structures, object recognition patterns, and event handling. While some scripts may work with minor changes, significant modifications are often needed for compatibility.

Windows 3.1 is a 16-bit operating system from 1990-1992, far too old to support QTP 9.2 (released around 2007-2008). QTP 9.2 requires modern 32-bit Windows versions like 98, ME, 2000, XP, or newer. Windows 98, ME, and XP are all compatible environments.

QTP scripts do not work seamlessly across browsers due to differences in object recognition, DOM implementation, event handling, and browser-specific behaviors. A script built for IE typically requires modifications when run on Firefox, Netscape, or Opera.