Versions Compared

Old Version 10

changes.mady.by.user ravi.chandran

Saved on

compared with

New Version 11

changes.mady.by.user ravi.chandran

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

UI Objects

Object Naming Conventions

  • Define nomenclature (naming convention) before starting any development.
    For Example:
    • How a user would name the objects to identify similar objects with different properties on different pages.
    • Giving proper names or ids to the test cases makes it easier for other users to access and use the same.

  • Try to use object names from an application that will make it easier to recognize and help to reduce redundancy.
    ElementName_QualitiaClass_ParentPageName
    For Example:
    • UserName_WebEdit_LogInPage

  • If the object name is getting too long, use short names of ElementName or of Qualitia class or of parent name.
    For Example:
    • UserName_WE_Loginpage or
    • UN_WE_Loginpage or
    • FirstName_WEdit_RegPage. Here 'RegPage' is RegistrationPage.
  • Define nomenclature (naming convention) before starting any development.
    For Example:
    • How a user would name the objects to identify similar objects with different properties on different pages.
    • Giving proper names or ids to the test cases makes it easier for other users to access and use the same.
  • Try to use object names from an application that will make it easier to recognize and help to reduce redundancy.
    ApplicationNameAbbreviation_ScreenName_ObjectName
    For Example:
    AMZ_CartPage_ProductName
  • If the object name is getting too long, use short names of Object Name or of PageName. Also, maintain a file for the abbreviation list which is used while in object creation.
    For Example:
    AMZ_CP_PN
    Follow abbreviations or full name for Objects; however you cannot use both patterns in a single project

Object Repository

  • It is recommended to use the Object Repository (OR) approach for storing objects from the application under test over a Descriptive Programming approach (DP).
  • In the case of a multi-user project, it is recommended to store the tsr file at the centralized share location so that all the users can use objects from it. This eliminates the manual efforts to replicate new objects in every tsr file of users.
  • The smart identification option should be disabled while storing the objects in the tsr file unless we have an explicit requirement to keep it enabled for any object.


    Q1: What are the different methods to manage objects in UFT?

    Answer: There following are the three different methods in UFT to identify objects:

    • Shared object repository (tsr)
    • Descriptive programming (Specific to Qualitia for Desktop)
    • Local Object Repository

Q2: What are the different ways to identify an object in UFT?

Answer: Using object spy, an object can be defined using the following:

    • Local Object Repository
    • Description Properties (xpath and css as well)
    • Visual Relation identifier
    • Ordinal Identifiers
    • Smart Identification (Not recommended)
    • Insight Object
    • Virtual Object (Not recommended)


Q3: In what situations are the different methods more suitable?

Answer: It is not dependent on the situation, but technology. UFT supports certain technologies, but the default method to identify an object has some known limitations. In such cases, we need to try other options to identify objects.


Q4: Which is the preferred method for object management in Qualitia?

Answer: The Global Shared repository is the ideal method for object management while using UFT, which is also suggested by UFT as well. It is recommended to store the tsr file at the centralized share location so that all the users can use objects from it. This eliminates the manual efforts to replicate new objects in every user's tsr file.


Q5: How should Object be managed in Qualitia in a multi-user environment when team members need to work on the same UI?

Answer: Qualitia recommends only a few members of the team who are working for some duration to have the rights to edit and manage the Global Object repository. This will reduce the errors and rework.
It is also recommended to store the tsr file at the centralized share location so that all the users can use objects from it. This eliminates the manual efforts to replicate new objects in every user's tsr file.


Q6: How to avoid merge issues in a multi-user environment?

Answer: It is important to use one standard naming convention by all the users to avoid any duplicate or overwriting the existing objects while merging/creating the object repository.

The above mechanism will also help in resolving any issues during merging


Q7: What are the best practices for naming objects?

Answer:  Refer to Object Naming Convention


Q8: What are the practical challenges when resolving merge conflicts when regular expressions (parameterization) is used in Objects?

Answer: The following problems may occur:

  • Objects with the same properties under the same hierarchy
  • Objects with the same name
  • Object properties change (e.g.: regex used in object properties in tsr)

There could be a lot more scenarios. However, it would be difficult to summarize all the possible issues that can occur.


Test Cases

Test Case Naming Conventions

  • There is nothing as wrong or right strategy for test case names. Following one strategy per project will make the search easier and navigation and selections faster.
    For example:
    • The strategy of Mapping (Manual TC to Automation)
    • Module or Sub-Module wise naming convention
    • Functionality description name convention
  • Test case names should be as descriptive as possible.
    For example:
     If the test case is intended to verify the fields on the screen, start TC name by word Verify and then what you are verifying.
  • Use spaces for better readability.
  • Start your test with a sequence number. This helps in to find the test easily in the tree. The sequence number can be specified for each scenario, as well.
    For example:
    '01_Verify fields' present on Home Page or '01_Validate populated fields'


In this section:

Table of Contents
minLevel2


Test Case Creation

  • Avoid adding TC steps from a test case as much as possible. Always try to use tasks.
  • Test a TC with different datasets to cover all conditions.
  • Avoid press keys.
  • Divide the complete test case into tasks as this increases reusability/modularity and also reduces the development time of subsequent test cases.
  • Create a test case using chunks of reusable tasks. For example: To fill some form along with attachment and to submit tasks you may create following a set of tasks:
    1. Open URL
    2. Login to Application_LP
    3. Navigate to Required page_Home_UP
    4. Fill the form of that screen_UP
    5. Upload attachment_UP
    6. Click the Submit button_UP
    7. Validate submitted values_UP
    8. Logout_MasterPage
  • Set appropriate flags for tasks to achieve excepted output from TCs
  • Ensure your design test case appropriately depending requirements of sequential and independent executions or both.
  • In Test Case description, provide dependencies, assumptions about the test case in the description field, and keep updating it timely.

Test Case Update

  • While updating any Test Case, first ensure if that TC is not dependent on any other TC. And if it is, then make changes to the scripts considering its effect on other scripts or update in a way that will make the minimal effect to the other scripts.
  • Always ensure that changes being made to TC are not impacting any iteration of the test case.
  • Cross-check dependency of tasks while updating them for any particular TC - give it to the owner of the task or decide on one person who will take such calls.
  • Cross-check the dependency of Objects while updating for a particular TC – give it to the owner of the object or decide on one person who will take such calls.

Test Case Delete

  • Before deleting any TC, ensure that any other TC is not dependent on the script you are about to delete. Such dependencies are not documented by the testers. So, try maintaining a list of dependencies, both direct and indirect.
  • Re-verify the test case name to check if you are deleting the correct test case.

Tasks

Task Naming Convention

  • Create a task with proper names making it easy for users to access. This would be very helpful as the same task can be used in multiple situations, and the user should be able to judge the task flow by the task name.
  • Even if its small functionality of the application, make a reusable task out of it, and ensure that the name of the task should be descriptive itself.
  • If the part of the functionality can be used individually in different test cases, divide the task into multiple reusable tasks.
  • One of the preferred task names
    For example:
    <pagename>_<functionality description>:
    SignupPage_Fill in all required fields

This helps to sort the tasks, and in case functionality covers multiple pages sequences all the pages as per the functionality

Task Creation

  • Prefer to create as many reusable tasks as you can. For achieving this, you may need to analyze the application and its elements completely.
  • Create reusable tasks by which these tasks can be reused in other scripts wherever required.
  • Divide flow in chunks and create tasks on the basis of these chunked flow.
    For example:
    • Click the Save button
    • Click the Submit button
    • Click the Cancel button
    • Upload Files, and so forth

Task Update

  • Before updating any task, check where the same task is used in any other scripts (TCs). Check with the owner if it is not impacting other scripts flow, or similar change is required for their flow as well.

Task Deletion

  • Before deleting any task, ensure that the task will not be required in the future to automate scripts.

General

Version Control Tool for Multi-user Scenario

  • In multi-user scenario always use version control tool. Qualitia integrates with SVN.
  • Use this integration and avoid manual check-ins of any XML files.
  • It helps when multiple users are working on the same Qualitia projects in collaboration, and it also prevents data losses of the updates made by other users.
  • Environment variables, custom actions, and external files should be committed or updated explicitly.

Environment Variables

  • Keep values that are dynamic and change very frequently under Environment variables. These can be used across the test cases.
  • Avoid changing environment variables inside the script. Such changes raise to trivial problems.
    For example: If script fetches URL of the page in between the execution and saves to the same EVN variable URL again. If this test case runs in the suite sequence, all the following Test case will try opening the new URL and might fail. So, create a new variable with the name URL_Edited for easy usage.
  • The environment variable can also be used to handle test case iterations.

Suite Creation

  • Define 'ResultPath' as a shared path so that all users connecting to the same Qualitia project can access and manage all execution reports centrally.
  • Qualitia supports multiple ways for the execution of test cases. Try and implement any of the methods instead of doing online executions.
  • Always implement error handling flags on important and critical tasks under test cases and apply the same concept for test suites as well.
  • Design Functionality/Module wise suites.

Project

  • De-activate projects that are created and are not used for any development to avoid any performance-related issues.