Setup and Execution
•  When UFT is started for the first time the UFT Add-in Manager is displayed. The required add-in for application testing should  be checked. 
•  References to the Function Libraries are added via the File – Settings – Resources menu option. A reference should be added for each of the applicable libraries, located in the relevant folder in the Test Resources folder. These are test specific settings; using the Set as Default button means they don’t have to be added to every test. The paths where UFT searches for other resources, i.e. reusable actions and object repositories, are added from the Options – Folders menu. These are UFT settings, not test settings and so they only need to be added once.
•  The option for which action to take When error occurs during run session may vary. It is likely to be set to stop run when the full Testset is being executed. Note that this stops the current test and moves onto the next one in the schedule, it doesn’t stop all test execution. It may be preferable to set this option to pop up message box during script development and debugging. This setting is accessed via the File – Settings – Run menu.
•  At the end of each test scenario all browsers may need to be shutdown. If something unexpected or an error has occurred, it can be difficult, or require a lot of coding, to ensure all the correct browsers are closed.  The approach can be  shutting down the IE process.. The machine running the tests cannot be used for any other purpose during execution. There is a risk that the host machine may be inactive long enough for the screensaver to be initiated. To handle this, a NoSleep utility can be downloaded from the Symantec website. This application triggers a tiny movement of the mouse cursor every 30 seconds. 
•  Some settings and global test values may need to be verified or updated before each run, particularly when a change of environment occurs. A checklist is provided below.
   o  User IDs: To cover the requirements for all the automated test scenarios a number of different user IDs may be required. Separate function library such as ApplicationSettings can be defined to store different users and their passwords,. 
   o  The scripts can start up the application several times and using the startup URL providedfrom a separate spreadsheet . Another cell in that spreadsheet can store a description for the project version and build under test. This is useful for reporting purposes.
   o  Some Client data or application data may be used in different area of the application and can be stored as a constant in the ApplicationSettings function library. 
   o  Variable client data can be fed from external spreadsheet and a separate Execl spreadsheet should be used for storing created data and results. It should be verified that it can be accessed on the machine executing the tests, and it should be closed before tests start running. 

Technical Details:  Test Suit in UFT
•  Reusable Actions and Test Scenarios: Reusable Actions include all the activity to drive the application. Each Reusable Action file contains several actions related to a particular functional area. Each action performs a specific defined functionality within the application, which may be parameterised. A seperate UFT Components document should be created for the project to provide specific details of all these files and actions. Test Scenarios are built as a sequence of calls to Reusable Actions. They have no associated Object Repositories and never perform operations on test objects.
•  Function Libraries: Function Libraries include code for reporting, accessing Excel spreadsheets and manipulating string and date values. They never perform any actions on the application.
•  Object Repositories: Object Repositories are files that store identification properties and values of the objects in the application under test. UFT then uses this information to locate the objects reference in the scripts during test execution. Multiple Object Repositories should be used, which generally align with the functional area of each reusable action files. This approach should be  taken for readability and efficiency; a single file with all  application object would grow to a large size and slow down the test execution. It does mean that there are a small number of objects repeated in more than one repository file. Learned objects should be modified to make their names more intuitive. Object identification values have to be changed with the use of regular expressions, to remove dynamic or data specific values; for example:
  o  Browser titles typically include text from client data. 
  o  WebButton & WebTable objects can include a dynamic index in the html id property.
  o  WebEdit, WebList & WebCheckBox objects may include a dynamic index in the name property.
  o  Some WebElements use the html id property with a dynamic index.

Where pages have multiple tabs, this can result in a large number of child objects in the Object Repository. To make the repository and the code in UFT more readable, a separate page can be added for each tab, and named that tab. Smart Identification can be avoided; correctly configured object properties make it unnecessary.