Optimizing test execution speed is essential for keeping build pipelines lean. Depending on how your framework is structured, you can achieve full parallel execution either natively using TestNG ** or dynamically using a **Custom Excel Allocator.
Here is a step-by-step guide on configuring both approaches, along with a comparison to help you choose the right strategy.
Strategy 1: Native TestNG Parallelization (Recommended for Code-Native Suites)
TestNG natively supports parallel execution at the methods, classes, tests, or instances level using its XML configuration or Maven parameters.
1. Update testng_regression.xml
Modify the tag to set the execution mode and thread pool size:
<suite name="Regression" parallel="methods" thread-count="10">
Enter fullscreen mode Exit fullscreen mode
2. Configure pom.xml for Dynamic Overrides
Allow developers and CI pipelines to override execution settings without altering XML files by adding these lines inside the block of the maven-surefire-plugin:
<parallel>${parallel}</parallel>
<threadCount>${threadCount}</threadCount>
Enter fullscreen mode Exit fullscreen mode
3. Execution Commands
- Default Run:
mvn clean test -P runTestNGTests
Enter fullscreen mode Exit fullscreen mode
- Override Thread Count Dynamically:
mvn clean test -P runTestNGTests -DthreadCount=15
Enter fullscreen mode Exit fullscreen mode
- Full Parallel Execution (Match CPU Core Count):
mvn clean test -P runTestNGTests -Dparallel=methods -DthreadCount=24
Enter fullscreen mode Exit fullscreen mode
Strategy 2: Custom Allocator & Run Manager (For Excel-Driven Suites)
If your framework relies on an Excel-driven Run Manager to parse keyword flows and data sheets dynamically, parallelism is managed via a custom ExecutorService fixed thread pool.
Execution Command
mvn clean test -P runAllocator
Enter fullscreen mode Exit fullscreen mode
- How it works: The allocator reads active test rows (Execute=Yes), dynamically assigns thread pools based on target thread properties, and dispatches concurrent runs.
Comparison: Allocator (Run Manager) vs. Native TestNG
Feature Allocator (Run Manager) TestNG Native Entry Point allocator.Allocator.main() via Maven Exec Plugin maven-surefire-plugin executing testng.xml Test Selection Reads Excel sheets via central properties Reads testng_regression.xml test classes/methods Thread Management Java ExecutorService (FixedThreadPool) TestNG internal thread pool (parallel + thread-count) Command mvn clean test -P runAllocator mvn clean test -P runTestNGTests Pros Pure data-driven control; multi-sheet aggregation; exact instance control Lighter weight; no Excel dependency; native TestNG integration Cons Requires property tuning; multi-sheet parsing requires custom code Limited to test methods/classes; lacks Excel data loop controlWhich Approach Should You Choose?
-
Choose Native TestNG if you want:
- Simple, code-first test execution.
- Faster execution loops without file parsing overhead.
- Standardized parallel=”methods” or parallel=”classes” handling.
-
Choose Allocator + Run Manager if you want:
- Multi-sheet Excel data-driven scheduling.
- Fine-grained control over test iteration instances based on data rows.
- Integration with existing property-driven suite configs.