QTP and SilkTest Automation

GetROProperty retrieves the current runtime property value of an object during test execution. 'RO' stands for Runtime Object - this method gets the actual property value from the application being tested. GetTOProperty retrieves Test Object properties from the repository (the expected values), not current runtime values. SetROProperty doesn't exist for retrieval. GetVisibleText and GetPropertyValue are not standard QTP methods for this purpose.

Low-Level Recording records mouse clicks and keyboard actions using absolute screen coordinates, which is useful when QuickTest does not recognize standard objects. Analog recording tracks continuous movements like drawing, while Normal recording relies on identifying specific GUI objects. Therefore, Low-Level recording is the correct choice here.

In QTP/UFT and VBScript, you use CreateObject to instantiate database connection objects like ADODB.Connection. For example: Set dbConn = CreateObject("ADODB.Connection"). This creates a COM object that can then connect to databases using connection strings. The other options (dbconnect, dbopen, CreateConn) are not standard VBScript or QTP commands for database connectivity.

QTP/UFT has three main parameter types: Test/Action parameters (for passing values into actions), Data Table parameters (for data-driven testing using the DataTable), and Environment parameters (for external/environment variables). These three types cover the primary parameterization needs in QTP.

A recovery scenario in QTP/UFT is designed to handle unexpected errors during test execution. It consists of three defined components: a trigger event that detects the error, recovery steps to handle the situation, and a post-recovery test run instruction that dictates how the test should proceed after recovery.

A Standard Checkpoint in QTP/UFT is specifically designed to verify the properties and values of objects in an application. Other checkpoints serve different purposes: Text checkpoints check text strings, Bitmap checkpoints compare pixel images, and Low-Level checkpoints record raw coordinate inputs rather than object properties.

When inserting output values in QTP/UFT, you can direct the output to either the Global DataTable sheet (accessible across all actions) or a Local Action DataTable sheet (specific to that action). This flexibility allows you to choose the appropriate scope for your captured values. Option B correctly identifies that both options are available.

In HP QuickTest Professional (QTP/UFT), parameterization is highly flexible. Test engineers can parameterize checkpoints, database checkpoints, and test objects stored in the object repository to run tests with varying data inputs. Since all three components can be parameterized, the option selecting 1, 2, and 3 is correct.

According to classic software testing principles, testing is defined as executing code with the primary goal of finding defects. Demonstrating that a program works or is defect-free is logically impossible because testing can only prove the presence of defects, not their absence.

Big-bang integration is not an incremental testing approach - it integrates all system components at once rather than in stages. Top-down (A) and bottom-up (C) are both incremental strategies that integrate modules gradually. Functional incrementation (D) is another incremental approach where features are added incrementally.

Exit criteria include thoroughness measures like coverage of code, functionality, or risk (i) - this measures how completely testing was done. They also include estimates of defect density or reliability measures (ii). Residual risks such as unfixed defects or lack of test coverage (iii) are also part of exit criteria. Verifying the test environment (iv) is typically done during test planning, not as an exit criterion. Therefore options i, ii, and iii are correct.

Test closure activities include checking which planned deliverables have been delivered (i) and finalizing and archiving testware (iii). They also involve analyzing lessons learned from the testing process (iv). Defect report analysis (ii) is typically part of test execution activities, not closure - closure focuses on completing and learning from the test process, not analyzing individual defects.

Regression testing should be performed after the software has changed (ii) to verify existing functionality still works. It should also be done when the environment has changed (iv) since environmental changes can affect behavior. It's not required every week (i), 'as often as possible' is impractical (iii), and doing it just when the project manager says (v) without trigger-based criteria is not proper practice. Regression testing is triggered by actual changes, not arbitrary schedules.

SilkTest Classic uses its proprietary 4Test (often written as 4G-Test) scripting language, designed specifically for testing GUI applications. It does not natively use VBScript, Perl, or JavaScript for classic test scripts.

SilkTest projects use .t for test scripts, .pln for test plans, .ini for configuration settings, and .opt for options files. .vbs and .qfl files are standard in HP/Micro Focus UFT (QTP) rather than SilkTest.

DOM stands for Document Object Model, which is a programming interface for HTML and XML documents. It represents the page as a tree of objects that can be manipulated with programming languages. Document Object Method and Descriptive Object Model are incorrect terms.

A SilkTest project is indeed a collection of files containing all necessary information about a test project, including test scripts, application states, test plans, and frame files. This is the fundamental organizational unit in SilkTest.

The SilkTest Agent is the component that resides on the target system (where the application under test runs) to execute commands received from the SilkTest Host. It interacts directly with the application, rather than wrapping interactions solely through a browser's DOM.

A test frame in SilkTest stores application state information including: all objects on the home page (HtmlImage, HtmlText, HtmlLinks), commentary information for documentation, and the BrowserChild window object that holds the application home page. Test cases themselves are stored in test plan files, not in the test frame.