Do and Don'ts for a Tester

Modified on Thu, 29 Aug at 9:50 AM

ü Do’s	× Don’ts
Provide meaningful names for Nodes (Screen or Page) Features (Tabs within a screen or a page) and Controls (UI elements on the page in the tab).	Avoid using ambiguous or generic names for Nodes, Features, and Controls, which reduces readability of the GWT step in the generated Feature File. For more info, refer to Producing Meaningful GWT steps Avoid creating same feature names in different nodes.
Include intermittent verification steps in each scenario to thoroughly test the behavior of the system.	Skipping verification steps can make it harder to pinpoint the exact failure. Test results may be ambiguous or misleading without explicit verification, making it challenging to determine whether the system behaved as expected.
Always use relative XPaths.	Avoid using absolute paths since they require frequent updates whenever there are changes in the structure or hierarchy of the UI elements within the application.
Implement dynamic wait strategies in your tests to improve test execution. For example, 'wait for control visible' action instructs the system to wait until an element is visible before clicking it. Ensure it is only clicked when it is visible on the screen. algoQA includes default actions to support this process. For more information on Default actions, see Default actions.	Avoid hard coded wait (fixed time intervals) in your actions, since it may lead to flaky tests. If the element does not become visible within the specified timeframe, it could result in test case failure.
Use parameterization functionality for selecting values or verifying content in your tests.
Ensure each Control or UI Element has a unique name during node configuration. Ignoring providing unique names will lead to duplicate XPaths in the Object repository.
Ensure while picking objects, you follow the Parent-child hierarchy while automating test cases using specific frameworks.	Skipping this hierarchy makes it harder to locate and manage related objects within the application or codebase.

Ensure to generate Test Data in a Separate YAML File.	Avoid storing test data in the Feature File: Makes it harder to update or manage test data. Limits the ability to reuse test data across multiple test cases or scenarios.
Ensure to follow coding guidelines for scripts generated. Ignoring coding guidelines can result in inconsistent code styles and practices in your scripts, making it harder to understand and modify them.	Avoid meddling with the scripts. It is not a good practice to edit the generated scripts.
Include soft assertions in the scripts wherever possible. Soft assertions allow test execution to proceed even if a verification step fails and provide comprehensive test results.	Avoid using only hard assertions. Hard assertions halt test execution upon encountering the first failure.
Store the test data in the Configuration files.	Avoid storing the test data in custom files.
Use tags to execute scripts. Avoiding the usage of tags increases the execution time.	Don't generate only one Feature File. Generate multiple Feature Files.
Ensure to generate a single test case with multiple data sets.	Avoid creating duplicate test cases for different data sets
Ensure Utility files and Source code files limit is 2,000 lines of code. If the file size exceeds this limit, then create a separate file.	Avoiding it may lead to maintenance challenges.
Clear cookies and cache before starting each test.	Avoid keeping unnecessary browser tabs or windows open during testing sessions.
Ensure to set the option in the Project Settings page to take auto backups of your project files daily, weekly and monthly. Alternatively, you can set this option to take manual back up by right-clicking on the appropriate project file name using More Menu option.	Avoiding taking backups may result in data loss and disrupt the workflow.