Optimizing Parallel Test Execution in Robot Framework Using Pabot and Excel

‍

Reducing execution time while preserving scalability is essential in test automation. Robot Framework's simplicity and adaptability have led to its widespread adoption. Nevertheless, sequential execution may slow down development timelines as test suites expand. The Robot Framework-based parallel test is available with Pabot.

In order to enable data-driven test execution at scale without compromising performance or maintainability, we will examine how to integrate Pabot with Excel-based test data in this blog.

Data-driven testing is supported by Robot Framework, and many teams save test data in Excel spreadsheets. Pabot distributes Robot tests among available CPU cores to allow for concurrent execution. When several tests run concurrently and access shared resources (such as Excel files), a problem occurs. Inadequate isolation might result in uneven outcomes which can be controlled using file locking mechanisms.

Hence, understanding how to structure test cases and Excel data for parallel execution becomes crucial.

Need for flexible parallel script execution - which allows the users to choose which scripts run concurrently. Also, while doing so, the system must efficiently manage input data from and output data to the Excel file. As part of logging back data into Excel, the system should include execution status, relevant data points, and detailed test results (including timestamps). 

In a single or sequential test run, reading input data from Excel, updating the system at runtime, and writing results back to the same Excel file is straightforward. However, when executing tests in parallel using Pabot, this becomes challenging. When multiple processes (threads or parallel executions) try to write to the exact same location in a file, especially with a file format like Excel, which is not inherently designed for concurrent external write access by multiple processes, you often get:

• Overwriting: One process writes, and then another immediately writes over that same spot, effectively erasing the first write.
• Race Conditions: Processes "race" to write, and the outcome depends on which process gets there first and how the operating system handles the contention.
• File Corruption: If multiple processes try to open, modify, and save the same file concurrently without proper locking mechanisms, the file structure itself can become damaged, making it unreadable

Due to the above reasons, when trying to approach the problem statement, we hit a snag - which just didn’t lead to corrupted files and lost information; it gave us a completely wrong picture of our test results. To overcome this, certain keywords within Robot Framework helped us manage these concurrent write limitations effectively. 

So, to overcome the pain, the approach below will be followed.

1. Libraries Installation in Robot Framework

• Open Command prompt and run the pip install robotframework-pabot  command to install the pabot library
• Declare Excel-related libraries as shown below in the test case file
  
  • Library: RPA.Excel.Files
  • ExcelLibrary

2. Handling Excel in Parallel Runs through the below

• Acquire File Lock, Release File Lock will keep the Excel file securely handled while writing test-specific data retrieved from the system
  
  • Acquire File Lock: During parallel execution with Pabot, this keyword ensures that the Excel file is locked while data is being written, which prevents conflicts or overwrites. It securely handles writing test-specific data retrieved from the system.
  • Release File Lock: Once the data is successfully written to the Excel file, this keyword releases the lock, allowing other parallel processes to access and update the file safely.
• Write results in separate workbooks in the same Excel so that we can efficiently handle the data without interruption. 

3. Script Execution Flow Chart using Excel Files

‍

4. Code Snippet to invoke Excel and get the input data

‍

‍

5. Code Snippet to update Excel with the result

‍

‍

6. Parallel Script Execution Flow

‍

‍

7. Example Scenario

Consider a regression suite containing 06 test cases, but only 3 need to run in the current execution. Instead of modifying the automation script, we can update the Run_Test column in Excel

• Input Excel Sheet:

‍

‍

• ‍Output Excel Sheet:

‍

• ‍Command to run pabot
  pabot --processes 3 --include Regression tests/
  Note: While this scenario is quite manageable during a single or sequential run, it becomes challenging to manage during parallel execution, which will overwrite the Excel sheet during pabot.

8. Internal Working

The execution of the Excel-driven Test Automation based on the following conditions.

1. Test_Case_No: The first criterion is the test case number. This condition determines if the given test case number is present in the Excel document or not. Execution moves on to the following stages if test case number is available. If not, the process ends without going further.
2. ‍Run Test: The second criterion is the value of 'Run_Test' in the Excel file. The test moves on to the following steps if it is set to 'Yes'. If it is set to 'No', the loop ends and the Excel sheet's result is noted as 'Skipped'.

• Simple Test Data Management: Non-technical testers can easily modify or expand test cases directly in Excel by adding or updating rows and columns—no coding knowledge required.
• Code-Data Separation: Since test data is maintained independently from the test logic, there's no need to alter the underlying code when changes are made to the data.
• Parallel Test Execution: By leveraging tools like Pabot, multiple test cases can be executed simultaneously in a well-structured and scalable manner using Excel-based inputs.

Here are the challenges we faced when we first started using Pabot:

• Excel file locking
• Data Overwrites

Our solution to the challenges:

• Utilizing the 'Acquire File Lock' and 'Release File Lock' keywords
• Use of dynamic input files and separating the output from the input sheet

With this, our parallel runs became more stable and significantly faster. The total test execution time was reduced by more than 50%, without any output data getting overwritten or corrupted.

We recommend starting with small test sets and gradually expanding to identify any data dependencies that might break parallel execution.

Robot Test Framwork with Pabot is powerful, but parallel execution is a double-edged sword when Excel files are involved. Without the right locking mechanisms and test architecture, it can lead to chaos like overwrites, data corruption and even failed runs. Parallel execution shouldn’t come at the cost of quality and with Cloud Peritus, it never does. By combining the power of Pabot with enterprise-grade locking strategies and dynamic Excel integration, we create test suites that deliver both velocity and accuracy. Our teams bring years of experience in solving concurrency conflicts and maintaining data fidelity under pressure.

This is how Cloud Peritus builds future-ready automation that's built for scale and always on track for faster delivery. Ready to scale up your automation? Talk to our experts today.

Reach out to us at info@cloudperitus.com

Cloud Peritus has been at the forefront of innovation since its inception and has since played an integral role in delivering game changing solutions to its clients time and again, resulting in 5 star reviews from across the board.

Feel free to check us out at Salesforce AppExchange.

If you found this interesting, check our other articles on the topic of QA and AI in Salesforce Testing.

1. Choose Wisely: Picking the Right Test Cases for Salesforce Automation Success!
2. Automate Everything: An Introduction to Robot Framework with Python
3. The Power of Parallel Execution in Provar Using Apache ANT