Test Automation Architecture
How I design automation frameworks so they stay maintainable at scale. The same principles guided the enterprise work described in the case studies.
Layered design
1. Scenarios (BDD)Business-readable feature files. No locators, no waits.GherkinCucumber
✔ Non-engineers can review coverage.
2. Step definitionsThin glue mapping steps to page and API actions. Reusable, no logic.StepsHooksTags
✔ Steps are reused instead of duplicated.
3. Page objects and API clientsSingle home for locators and endpoints, so a UI change is a one-file fix.Page Object ModelREST clients
✔ UI churn never reaches test logic.
4. Core servicesDriver lifecycle, environment config, AI self-healing locators, LLM test-data generation, logging and screenshots.ConfigSelf-healingLLM dataLogging
✔ Cross-cutting concerns live in one place.
5. CI/CD and smart test executionOn each commit or pull request, the pipeline diffs the change against the base branch, maps changed files to impacted tests and runs that set first. Shared code or config changes, or low-confidence mapping, fall back to the full suite.JenkinsGitHub ActionsGitLab CI
✔ Faster feedback without silently skipping coverage.
6. Execution and reportingParallel, sharded runs with Allure and HTML dashboards. Quality gates block the merge on failure.ParallelShardingAllure
✔ Every run is auditable and gated.
AI agents that speed up script development
Five agents sit around the framework and remove the slow, repetitive steps between a business requirement and a merged, running test. Each one hands its output to the next.
LLM reasoning layerPrompted with team standards, existing repo context and the change at hand; outputs are reviewed by engineers
▼
1
Requirements to Acceptance CriteriaReads requirements from Confluence and writes compliance-format acceptance criteria into the Jira ticket.Faster BA to QE handoff2
Feature File and Step ReuseTurns the criteria into Gherkin and detects existing step definitions so nothing is duplicated.Authoring cycle: 3 days to 18 hours3
Component and Locator ReuseInspects the DOM, reuses existing page objects and locators, and generates framework-conformant new ones only when needed.Less duplicate code, faster scripting4
Code ReviewReviews the merge-request diff against POM and framework standards and posts inline comments.Adopted across 4 active QE repos5
Smart Test ImpactAnalyses commit diffs, runs the impacted subset for fast PR feedback, then the full regression as a safety pass.Fast feedback without losing coverage
▼
Framework and CI/CDReviewed scripts merge, run in the pipeline and report back; failures and flaky results feed the next cycle
Combined impact across the agents: regression cut from 5 days to 4 hours, 25% fewer production defects, and SDET onboarding reduced from 3 weeks to 10 days. See each agent in detail.
Live view: how the 5 agents plug into the framework
Click a stage, or let it auto-play. Each agent takes an input from the delivery flow and hands a reviewed output to the framework and CI/CD.
Input
Output into the framework
Performance testing architecture
Performance checks run as a pipeline stage, with the same pass or fail discipline as functional tests.
Load modelWorkload profiles from real traffic: baseline, load, stress, soak.
Load generatorsGatling or JMeter scripts in the repo, run from CI agents.
System under testServices in a production-like environment with seeded test data.
ObservabilityLatency, errors, CPU and memory from APM and dashboards, correlated to the run.
SLO gateBuild fails if p95 latency, error rate or throughput breach the budget.
Results are compared with the previous baseline so regressions are caught at the commit that caused them.
Key design decisions
| Decision | Why |
|---|
| BDD over raw scripts | Scenarios double as living documentation and keep product, dev and QE aligned. |
| Page Object Model | Isolates UI churn from test logic and keeps maintenance cost low. |
| Self-healing only as a fallback | The LLM proposes a locator when one fails, and the fix is logged for review. Silent healing hides real regressions. |
| Environment-driven config | The same suite runs in dev, QA and staging; production gets read-only smoke checks. |
| Parallel by default | Independent tests and isolated data keep feedback fast; this is how a 5-day regression became 4 hours. |
| Test pyramid, not UI-only | API and contract tests carry most coverage; UI covers critical journeys. |
Smart Test Execution: architecture requirements
Running everything on every commit does not scale. Smart test execution selects the tests that matter for each change, without trading away safety.
| Requirement | What it means |
|---|
| Change-to-test mapping | Tests are tagged by feature, service and risk; the commit diff (changed files versus the base branch) is mapped to the impacted tests through that traceability layer. |
| Risk-based prioritization | Critical-path and historically flaky or failing tests run first, so the fastest feedback goes to the highest risk. |
| Safe fallback | If the impact analysis has low confidence, or the change touches shared code or config, it falls back to the full suite. Selection must never silently skip coverage. |
| Tiered pipeline | Smoke on every commit, impacted tests on pull requests, full regression nightly and before release. |
| Explainable selection | Every run records why each test was included or excluded, so engineers can audit and trust it. |
| Isolated, parallel execution | Independent tests, isolated data and sharding across workers keep the selected set fast. |
| Feedback loop | Escaped defects and flaky results feed back into the mapping and priorities over time. |
| Measurable outcomes | Track selection accuracy, escaped defects, pipeline time saved and flaky rate to prove the approach works. |
Results this approach delivered
- Regression cycle cut from 5 days to 4 hours across 3,000+ tests and 12 microservices
- 25% fewer production defects
- Selenium to Playwright migration with a 12-engineer, three-country SDET team
Browse the repositories
