Test Automation Architecture
Test Automation Architecture
This domain tests your ability to design a test automation architecture that separates concerns, isolates change, and supports long-term maintainability. The exam focuses on layers, components, abstraction, and design principles rather than on one vendor’s framework.
Core rules
- A test automation architecture typically separates test definition, test execution, and test adaptation, with the system under test at the boundary.
- Design principles include separation of concerns, modularity, reuse, abstraction, encapsulation, readability, scalability, and portability.
- Abstraction should hide SUT interaction details behind page objects, service clients, or keywords so that a change in one interface does not ripple through every test.
- The architecture must support test data management, logging, reporting, configuration, and environment selection.
- Record-and-playback can demonstrate a concept, but it rarely scales because it embeds brittle locators and duplicated logic.
Worked example
A keyword-driven design defines business keywords such as “place order” and “refund payment.” Each keyword calls a service client or page object; page objects alone know selectors and API endpoints. When the checkout page changes, only the checkout page object changes. Reasoning: the test expresses intent, the adaptation layer absorbs SUT detail, and maintenance is localized. This is architecture, not scripting.
Traps
- Mixing test logic with SUT interaction code.
- Over-layering a small solution until it becomes hard to trace.
- Relying on UI automation for checks better suited to APIs.
- Using brittle locators and duplicated setup code.