UI Objects

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.
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.

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>

- Username_WEdit_LP
- Password_WEdit_LP
- iframeLogin_LP(iL)
- Login_WBtn_iL_LP

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.

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.

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}']

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 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'

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.

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

Tasks

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.)

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 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 and GIT/Bitbucket.
Use Qualitia's 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 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.

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.

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.

All Other

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

Maintenance

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.
Restart the server at least once a month or when the memory consumption is about to reach 4 GB. You can check the memory consumption from app.log present in the RealTimeReport logs.

Synchronizations/Waits

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.

Browser not supported