Distributed Agent Execution – ACCELQ

Subscription: Enterprise Edition

Distributed Agent Execution in ACCELQ allows users to distribute the execution of a given test job across multiple agents, thereby significantly reducing overall execution time. By spreading test cases among several agents, this feature improves efficiency. This guide provides an overview of how to configure and use Distributed Agent Execution, along with details on additional features, behavior, and best practices.

Difference from Parallel Execution

Unlike the parallel execution feature in ACCELQ, where a given test job is executed on a single agent with multiple parallel threads, distributed execution splits the job across multiple agents. Additionally, you can enable both distributed agents and parallel threads, meaning each agent can run multiple threads concurrently. This combination offers a considerable multiplier effect, maximizing the potential for using low-configuration hardware or virtual machines to achieve high throughput.

Achieving Parallel Execution for Desktop Applications

Distributed Agent Execution is particularly useful for application environments that limit one user session per machine or applications that only allow one instance per machine. This is especially significant for desktop automation scenarios, where achieving parallel execution is particularly challenging. Traditional parallel execution might be impractical in these cases, but distributed agent execution overcomes this limitation, making parallel execution feasible for desktop apps.

Note: Distributed Agent Execution is available exclusively in the Enterprise Edition and is not currently supported for Mobile Testing.

How to Enable Distributed Agent Execution for a Run

Access Agent Selection: When preparing to run a test job, click on the Agent Selection section in the Run modal.
Toggle Distributed Agents: Turn on the toggle labeled "Distribute execution across multiple Agents" to enable distributed execution.
Agent Selection Options:
- You can either multi-select named agents from the dropdown menu.
- Alternatively, choose the "Dynamic Agents" option, allowing ACCELQ to automatically allocate available agents at runtime. If choosing the Dynamic Agent option, specify the number of agents you want to utilize for the test job.
Parallel Threads per Agent: Specify the number of parallel threads per agent. This count represents the maximum number of concurrent threads for each agent, depending on the agent’s configuration and capacity. If a specific agent cannot support the specified number of threads, it will default to its maximum capability.

Test Case Distribution Across Agents

When you select the distributed agents option with a specified number of agents, ACCELQ will divide the test job into a corresponding number of independent sub-jobs. Each sub-job is assigned an approximately equal number of test cases and distributed to the selected agents. Here’s how it works:

Job Creation: For instance, if you select three agents, ACCELQ will create three sub-jobs, each responsible for handling a portion of the overall test cases.
Grouped Display: The distributed sub-jobs are displayed as a group within the Results Grid for easy reference and management.
Job Management: If you delete the consolidated job row in the Results Grid, all associated sub-jobs are deleted. If the main job is in progress and you attempt to abort it, all the corresponding sub-jobs are also aborted. However, you can delete or abort individual sub-jobs without affecting the others.

Note: Distributed execution has some implications on test sequencing and parallel operations that you need to keep in mind.

Results Collation

With multiple agents executing different parts of a test job simultaneously, ACCELQ collates the results automatically. All sub-jobs are grouped together with features that allow you to easily switch between individual sub-job reports or view the consolidated report for the entire distributed job. This approach ensures a seamless experience without requiring manual collation of results across sub-jobs.

Indicators for Reports: When viewing a test job report, ACCELQ clearly indicates whether the report belongs to a sub-job or a full distributed job execution. Navigation links are provided for easy switching between the full report and the specific sub-job reports.

Notifications

Notifications for distributed job execution work as follows:

Kick-off Email: You will receive a single email notifying you of the initiation of the distributed test job.
Completion Emails: You will receive multiple test completion emails, one for each sub-job. However, when accessing the results in the Results Grid or clicking the link in the completion email to access the online report, the results are collated and presented in a unified view. This ensures seamless navigation from any sub-job report to the consolidated report, avoiding the need to manually visit all sub-job links separately, even in cases where multiple agents (e.g., three agents) are used.

Additional Considerations

Data Dependency Between Test Cases: ACCELQ allows sharing data across test cases using Run Properties. In a distributed setup, be aware that cross-test-case dependencies may lead to unpredictable results. This happens if the test case that generates a value runs on a different sub-job than the test case that needs that value. Plan data dependencies carefully to avoid such issues.
Job Teardown Actions: If you configure Job Teardown Actions to run at the end of a test job, note that these actions will run once per sub-job in a distributed execution environment. This behavior may need to be considered when designing teardown actions to prevent unwanted repetition.
Static Test Suites: Test cases configured in Static Test Suites may not strictly adhere to the intended execution order when using distributed agents. Since test cases are distributed across multiple agents, they will run independently, affecting the predefined order.
Aborting Jobs: Aborting a sub-job only impacts that particular job, allowing the remaining jobs to continue executing. However, if you want to abort all the sub-jobs, you should abort the consolidated job report.
Agent Allocation: Agent allocation for sub-jobs is static. Once a sub-job is assigned to an agent, it does not get reassigned dynamically. If an assigned agent goes down, the sub-job waits for intervention, and you may need to abort and rerun the job with a different agent.
External Report Access: If you have enabled an external access passcode for viewing reports, the same passcode will apply to all sub-job reports in a distributed job.

Best Practices for Distributed Agent Execution

Plan Data Dependencies Carefully: Avoid scenarios where test cases depend heavily on the output from other test cases in the same run, as distributed execution can result in those test cases running on different agents.
Design Teardown Actions Appropriately: Ensure teardown actions are designed with distributed behavior in mind to prevent redundant activities across sub-jobs.
Use Parallel Threads When Possible: Combine distributed agents with parallel threads to maximize the efficiency of hardware resources, especially when working with lower configuration agents.
Monitor Agent Health: Keep an eye on agent availability to ensure that sub-jobs are not stuck waiting for a downed agent. Use the ReRun feature to reassign such jobs to healthy agents.

Conclusion

The Distributed Agent Execution feature in ACCELQ significantly optimizes test execution by leveraging multiple agents to handle different parts of a test job concurrently. This not only reduces the total execution time but also ensures efficient resource usage, particularly when combined with the parallel execution feature. With thoughtful configuration and understanding of its nuances, this feature can dramatically enhance testing efficiency, especially for complex testing environments.

For more details on Teardown Actions, Run Properties, or other advanced topics, refer to the linked resources in this guide.