Page Comparison

Image Added

Table of Contents
1. UI Objects
1.1. Object Naming Conventions
1.2. Object Hierarchy (Page Object Model)
1.3. Common Objects or Master Pages
1.4. Qualitia Locators and Their Usage
1.5. Dynamic Objects
2. Test Cases
2.1. Test Case Naming Conventions
2.2. Test Case Creation
2.3. Test Case Update
2.4. Test Case Delete
3. Tasks
3.1. Task Naming Convention
3.2. Task Creation
3.3. Task Update
3.4. Task Deletion
4. General
4.1. SVN (Version Control)
4.2. Environment Variables
4.3. Suite Creation
4.4. Sequencing\Parallel TC Suites
4.5. All Other
5. Maintenance
5.1. Regular Maintenance Cycles
6. Synchronizations/Waits
6.1. Waits Usage

Anchor
_Toc517099946 _Toc517099946

UI Objects

Anchor
_Toc517099947 _Toc517099947

Object Naming Conventions

• Define nomenclature (naming convention) before starting any development. For Example:
  • How 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.

    Anchor
    _GoBack _GoBack

• Try to use object name 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.

Anchor
_Toc517099948 _Toc517099948

Object Hierarchy (Page Object Model)

• Maintain objects page wise. This helps to avoid duplication.
• Using proper frames hierarchy helps to avoid any confusion on the script.

For example Login page (Username and Password Text Boxes)
<Root>
Login Page(LP)

• Username_WEdit_LP
• Password_WEdit_LP

Now, let's suppose you have an iframe on top of the Login button.
<Root>
Login Page(LP)

• Username_WEdit_LP
• Password_WEdit_LP
• iframeLogin_LP(iL)
  • Login_WBtn_iL_LP

Anchor
_Toc517099949 _Toc517099949

Common Objects or Master Pages

• Create a common object, such as Save, Cancel buttons and so forth on a page called common elements.
• In case of having objects, like, top menus and footers (Master Page) which repeats on every page, instead of creating objects for each page, such objects should be created under some master page title which tester can easily relate to.

Anchor
_Toc517099950 _Toc517099950

Qualitia Locators and Their Usage

• Object locator mostly depends in development or UI frameworks used in the application under test.

If the developers have given static id or names there is no dispute using them for identification. For example:

• <input id= 'username' type=text></Input> (id can be used for identification/even the best one to recognize the element).
• <input id='w6kyp56' type=text></input> (avoid id's in such cases it might get change with page refresh or with new build updates)
• While identifying objects with object spy, it is always better to keep the object spy IE window open. This comes in handy when the user is developing the test case and comes across an object that is not added to the repository. Instead of switching tabs and adding objects manually, the user can use the existing open instance of object spy and add objects instantly.

Anchor
_Toc517099951 _Toc517099951

Dynamic Objects

• Avoid using the dynamic attribute in locators to identify an object such as class, angular attributes, and so forth.
• Identify an element by containing text.
• Always identify the element with reference to a closest stable element using xpath axes.
• Avoid indexing as much as possible like div [7] and so forth.
• Use parameterized XPath to handle dynamic objects.

For example:

• //input[text()='{TB_Text}']

Anchor
_Toc517099952 _Toc517099952

Test Cases

Anchor
_Toc517099955 _Toc517099955

Test Case Naming Conventions

• There is nothing as wrong or right strategy for test case names. Following one strategy per project will make 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'

Anchor
_Toc517099956 _Toc517099956

Test Case Creation

• Avoid adding TC steps from test case as much as possible. Always try to use tasks.
• Test 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 development time of subsequent test cases.
• Create 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 you 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.

Anchor
_Toc517099957 _Toc517099957

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.

Anchor
_Toc517099958 _Toc517099958

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 test case name to check if you are deleting the correct test case.

Anchor
_Toc517099959 _Toc517099959

Tasks

Anchor
_Toc517099962 _Toc517099962

Task Naming Convention

• Create 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 sequence all the pages as per functionality.)

Anchor
_Toc517099963 _Toc517099963

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

Anchor
_Toc517099964 _Toc517099964

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.

Anchor
_Toc517099965 _Toc517099965

Task Deletion

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

Anchor
_Toc517099966 _Toc517099966

General

Anchor
_Toc517099969 _Toc517099969

SVN (Version Control)

• In multi-user scenario always use SVN. SVN is a version controlling tool.
• Use Qualitia's SVN integration and avoid manual check-ins of any XML files.
• Use it carefully to avoid data loss of the updates made by other users.
• Environment variables, custom actions, and external files should be committed or updated explicitly.

Anchor
_Toc517099970 _Toc517099970

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 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 name URL_Edited for easy usage.

• The environment variable can also be used to handle test case iterations.

Anchor
_Toc517099971 _Toc517099971

Suite Creation

• Define 'ResultPath' as a shared path so that all users connecting to same Qualitia project can access and manage all execution reports centrally.
• Qualitia supports multiple ways for 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 case and apply the same concept for test suites as well.
• Design Functionality/Module wise suites.

Anchor
_Toc517099972 _Toc517099972

Sequencing\Parallel TC Suites

• Properly plan execution suites for optimum execution time and results.
• Create a proper matrix of dependent test cases, independent test case, and tests that cannot be executed in parallel even on different projects.
• Avoid opening the new browser every time to save test case execution time.

Anchor
_Toc517099973 _Toc517099973

All Other

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

Anchor
_Toc517099974 _Toc517099974

Maintenance

Anchor
_Toc517099976 _Toc517099976

Regular Maintenance Cycles

• Execute suites at least once in a week. If any script is failing because of script issues or UI changes, update such scripts on dedicated maintenance day of the week.
• Verify the CR manually and carefully update the re-usable task to implement new changes. Do Dry Run of the TC as well as all the affected TCs and then add in the suite for better results.

Anchor
_Toc517099977 _Toc517099977

Synchronizations/Waits

Anchor
_Toc517099979 _Toc517099979

Waits Usage

• Appropriate wait statement should be used in the scripts to ensure flow right way.(For example waitforobjectExists, waitforobjectclickable, waitforobjectvisible, and so forth)
• Avoid using sleep statements.