A production-grade Selenium automation framework built using Java, TestNG, Selenium Grid, Docker, and GitHub Actions, designed for scalable, cross-browser, CI/CD-ready test execution.
This framework demonstrates clean architecture, industry-standard design patterns, and real-world automation practices used in modern QA engineering teams.
β
Page Object Model (POM) for clean and maintainable test design
β
Strategy Pattern to remove conditional logic and support extensibility
β
Factory Pattern for runtime decision-making
β
Selenium Grid (Dockerized) for parallel & distributed execution
β
Cross-browser testing using GitHub Actions Matrix
β
Parallel execution with TestNG
β
Extent Reports for rich HTML reporting
β
Data-driven testing (CSV & Excel utilities)
β
Environment-agnostic configuration resolution
β
Tests fully decoupled from Grid infrastructure
β
CI-ready & production-like setup
GitHub Actions (Matrix: Chrome / Firefox) --> Test Docker Image (Selenium + TestNG Tests) --> Selenium Grid (Hub + Scaled Browser Nodes)(Docker Compose)
Each application page is represented by its own class, encapsulating locators and behaviors.
Examples from this project:
RegistrationPageFlightSearchPageFlightConfirmationPage
Benefits:
- Clean separation of concerns
- High readability
- Easy maintenance & scalability
Used to dynamically switch behavior at runtime without if/else chains.
Applied for:
- Browser selection (Chrome / Firefox / Edge)
- Execution mode (Local / Remote)
- Test selection logic
Core interfaces:
BrowserStrategyExecutionStrategyTestSelectionStrategy
Factories decide which implementation to use at runtime based on configuration.
Examples:
BrowserStrategyFactoryExecutionStrategyFactoryTestSelectionStrategyFactoryDriverFactory
Configuration values are resolved in the following priority order:
- CI / Environment Variables
- JVM System Properties (
-D) - config.properties
- Default values
β Works seamlessly across local, Docker, and GitHub Actions
β No code changes required between environments
Rich HTML reports with:
- Test status
- Categories
- Authors
Reports are:
- Generated after every test run
- Mounted via Docker volumes
- Uploaded as GitHub Actions artifacts
Utility support for reading test data from:
- π CSV files
- π Excel (.xlsx)
Use cases:
- Parameterized tests
- Externalized test inputs
- Easy maintenance for large datasets
- Parallel execution enabled at method / suite level
- Thread count configurable via:
- CI variables
- JVM arguments
- Config file
Cross-browser execution is achieved using GitHub Actions matrix strategy:
strategy:
matrix:
browser: [chrome, firefox]Each browser runs:
- In isolation
- Using the same test Docker image
- Against dynamically scaled Selenium Grid nodes
- Selenium Hub
- Chrome & Firefox Nodes
- Official Selenium Docker images
Browser services are defined with zero replicas by default and are scaled dynamically at runtime.
deploy:
replicas: 0This ensures:
-
No unused browser nodes
-
Optimal resource utilization
-
Full control via CI/CD pipelines
Chrome nodes
docker-compose -f grid.yaml up --scale chrome=2 -dFirefox nodes
docker-compose -f grid.yaml up --scale firefox=2 -dRun Tests by Passing Browser Explicitly
Chrome
BROWSER=chrome docker-compose -f test-suite.yaml up
Firefox
BROWSER=firefox docker-compose -f test-suite.yaml up
docker-compose -f grid.yaml up --scale ${{ matrix.browser }}=2 -d
BROWSER=${{ matrix.browser }} docker-compose -f test-suite.yaml up
-
Grid scales dynamically per browser
-
Same test Docker image reused
-
Fully automated cross-browser execution
This framework supports cron-based automation using GitHub Actions for unattended test execution.
schedule:
- cron: "0 5 * * 1"This ensures the test suite runs once every week, automatically, without any manual trigger.
-
Tests do not manage Selenium Grid lifecycle
-
Grid can scale independently
-
Same test Docker image works locally and in CI
This separation ensures that:
-
Test logic remains clean and focused
-
Infrastructure can be reused or scaled without touching tests
-
The same setup behaves consistently across local, Docker, and CI/CD environments
This mirrors real-world production test setups used in mature QA platforms.
The framework includes a retry mechanism to automatically re-run failed test cases.
-
Retry enabled using TestNG retry analyzer
-
Helps mitigate flaky test failures
-
Retry count configurable via framework settings
-
Only failed tests are retried (not successful ones)
-
Improved test stability
-
Reduced false negatives in CI
-
More reliable pipeline results
-
Clean architecture with clear responsibility boundaries
-
Loose coupling via strategy & factory patterns
-
No hard-coded environment assumptions
-
Docker-first approach for reproducibility
-
CI/CD friendly with GitHub Actions integration
-
Scalable & maintainable test execution model
-
Cross-browser & parallel execution out of the box
This framework is designed not just to run tests, but to scale with teams and pipelines.