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

All Other

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