Test automation can be thought of as having three layers:
- Core: application-independent code, useful for any test domain.
- Domain level: code specific to the test domain.
- Test level: the actual tests.
As much code as possible should be pushed (refactored) into the core: base classes, helpers, logging, reporting.
Of what remains, as much as possible should be pushed (refactored) into the domain level: page objects, REST endpoint objects, data objects, intermediate base classes.
What’s left, then, is just the tests themselves.
So: an engineer who works only on the core and the domain level (but not the test level) is not really a tester at all.
To borrow from mountain-climbing vocabulary, that engineer is not a climber, but is instead a sherpa. The sherpa’s job is to do the heavy lifting, build base camps, and keep the climbers progressing safely and happily.
The test automation sherpa, a specialist, makes domain-specific automated testing possible by building the core and the domain layer.
Using those, the tester creates and executes the automated tests, and interprets their results.
Makes sense?