Action with multiple destinations can avoid code duplication
Lot of times, you may have an Action resulting in different destination contexts based on some business rules. Using the multi-destination feature can avoid logic duplication by utilizing the same action under multiple conditions. You can find some examples here.
Avoid duplicating same logic in multiple actions
If you find a situation where a set of statements (or logic) is duplicating in multiple actions, think about extracting this logic into a separate action. These statements may not make sense from a Scenario or Business Keyword point of view, but you can still extract this as a separate Action for the purpose of reusability.
You can call this action from several other actions as needed. With an ability to share an action, you can make use of this common action across multiple contexts also. This promotes reusability and greatly enhances the maintainability of test logic.
Here is an example, where an Action, "Verify Transfer Amount and Confirm" is calling "Verify Footer Links" as a called-Action. Footer link verification may be useful in many other Actions and hence that logic is centralized in one Action.
Local actions can eliminate clutter and improve re-usability
Many times, you may define Actions to be used internally in other Actions (Local Actions). such "called" actions may not be of significance from the Scenario point of view. It is best to turn-off Scenario visibility of such actions. This avoids clutter when you are building a scenario. Remember, you want to provide as clean a list of keywords to the Scenario developer as possible. Small and incremental practices like these have a significant impact on the overall clarity and maintainability.
Use functional Wait logic in Actions – avoid hard coded wait statements
It is a good practice to insert a synchronization statement (wait-*) at the beginning of every major action to make sure necessary pre-conditions on the screen are available. Many times, automation execution reliability is impacted due to timing issues. A statement in your action logic might attempt to act on an element before it is fully rendered on screen. In accelQ, you can insert wait statements based on element availability, state of enabled/not, attribute value, css attribute value etc (functional waits). Here is a detailed article.
When you insert a wait statement, depending on the need, you have an ability to abort test case if desired state is not achieved.
As much as possible, avoid hard coded fixed-time wait statements. In some cases though, it may be particularly tricky to determine the readiness of an element. If you do need to insert a hard-coded wait statement, limit it to a maximum of 5 seconds (after all other avenues with functional waits are exhausted).
Action sharing is a powerful feature that can avoid a lot of code duplication. Common navigation actions and business actions such as Logout are applicable in most pages in the application. Define these actions in one of the Contexts and share with rest. You will be managing element definition and other dependencies in a central place. Consider following two Scenarios.
Scenario 1: Login and Logout - Makes use of Logout functionality in Account Summary Page
Scenario 2: Update User Email - Makes use of Logout functionality from Profile Info Page
Perform Logout action can be defined in Account Summary Page and shared with the Profile Info Page.