I often look at job postings, especially those with the role title of Automation Architect and those with titles pertaining to “automation leadership”. Why? Because I want to see what competencies different companies want to hire. Or, at least, the competencies they think they want to hire; we’ll get to that in a minute. This research helps me collaborate with my leadership regarding potential client needs so that we know how to staff and train with regard to testing and automation leadership.
One competency that frequently appears in these senior-level leadership or architecture roles is something akin to “the ability to create an automation framework from scratch”. On the surface, this appears to be a reasonable skill that a team would want in an architect. After all, what’s the architect going to do if they’re not building a framework?
That competency may be valuable, but in many cases, I’m not sure that’s not the primary development an architect should be performing. Allow me to explain.
If we think about our automation in terms of a stack, that stack has two primary subdivisions: the general layers and the domain-specific layers. The general layers are pretty much what their name says they are, i.e., those layers which are reusable across most applicable applications. One example of general layer features includes those features provided by the lower-level raw tool(s) such as Selenium or REST Assured upon which the other layers are built. Another example is “helper functions” built in the abstraction/encapsulation layer, such as those that perform waiting for GUI elements or parsing of API messages. The domain-specific layers are those that are not general, i.e., those layers that implement how to interact with our specific applications; by their definition and in practice, domain-specific layers are seldom applicable across domains/applications. These layers contain company-or-organization-specific code, page objects, BDD-tool files, and amalgamated behaviors. See the diagram below:
Most “popular” programming languages have automation stacks, or sub-frameworks, that handle some portion of the general layers on top of many readily-available raw tools. There are no readily-available stacks that I know of that handle our domain-specific layers; no framework or stack developer can anticipate all possible applications and how they will be implemented.
Of course, in some cases, the existing frameworks layered above our raw tool of choice may not be suitable for our specific needs; some of our application implementations are outliers and that’s just the way it is. Most of us, however, are not outliers; we often think we are, but we usually are not. Architects should be leveraging the appropriate frameworks that already exist. By doing this, we can spend our time working on the domain-specific parts of our frameworks (or stacks), coaching less-senior team members on automation design and implementation, and working with the teams on ways to make the team more effective and more efficient.
Now, to be fair, not every framework will be appropriate for every context. What might make a specific framework unsuitable for our needs? Here are some possibilities:
- The framework hasn’t been updated in “a while”. This could indicate that no one is maintaining it anymore.
- The framework is under a license that is not acceptable to our company or us.
- The framework doesn’t support an operating system on which we need to execute.
- The framework doesn’t support a development framework that we require, e.g. .Net MAUI or Java 17.
Note, that for the latter two bullets, it may be possible for us to contribute to the framework by adding the missing features that we need. After all, adding what we need to an existing code base should be less effort than creating a new framework from scratch and the ability to work in this kind of shared environment is an immensely valuable skill for automation architects. Additionally, this approach can reduce the effort required for the “base framework”, thereby allowing us to spend more time on creating visible value for those team members who participate in creating the automated scripts. Contributing to existing projects has the added bonus of giving back to the community from which we are also benefiting. Naturally, working this way assumes that the candidate framework is open source and that the maintainer(s) are interested in community collaboration.
Yes, when job descriptions talk about framework development, some of them may mean “development of the domain-specific layers on top of an appropriate, readily-available framework”; after all, this domain-specific code needs architectural guidance too. It’s likely, however, that those job descriptions were written with a mindset of developing a framework “from the bottom up”. That’s fine. There may be no good candidates to use or evolve, but it’s incumbent upon organizations and architects to perform due diligence in order to decide which, if any, framework is appropriate.
The previous sentence is important! This is a key skill that “automation architects” must possess: the ability to evaluate the appropriateness of existing tools and frameworks. Applying this skill enables their framework users can go about their own core competencies in a valuable manner. At the conclusion of these evaluations, teams might conclude that there is not sufficient value to adopt or adapt an existing framework.
Pursuant to the two previous paragraphs, perhaps more automation architect job descriptions should contain an item akin to, “the ability to evaluate existing automation frameworks to determine their appropriateness for the organization’s use”. Because really, how many more Selenium/Playwright/Cypress/whatever frameworks do we need anyway?
Like this? Catch me at an upcoming event!
Responsible Automation 