As automation becomes more and more prominent Iām finding it difficult to break into this area as a contractor. I appreciate itās my job to upskill and Iāve gained some experience in Selenium IDE and writing BDD feature files from a business perspective. Iāve also taken a course in Intellij with Java.
However, more and more employers are looking for testing professionals with coding skills, sometimes more than 1 language. Are there companies still out there who appreciate testers who can work alongside a developer to create automation tests without being an expert coder. ? Also where does AI fit in, can that bridge the gap ?
Get the most out of asking a question.
Is the topic title a question?
Does the topic title include a āquestion markā?
What are you asking of the community?
How can they help you?
What context can you share to increase the likelihood of someone replying to your question?
I havenāt seen companies where an automation engineer creates automation alongside a developer. Itās usually alone or with a BA/tester as support.
Automation without being an expert coder is sought after in companies with low budgets(about 30% lower than the IT software engineerās average salary), where they would want a max of 1-2 years of experience with a bachelorās in CS for example.
Iāve not seen it mentioned(looking for jobs in central Europe in 2 of the countries with the highest salaries).
I use it to search for code examples of a solution that I think of. One of my last searches: āIn playwright how do I use the locator ātohavevalueā with a regex that has also a variable inside?ā
I know other automation engineers that use it, and developers as well - it can reduce time significantly when youāre looking in how to solve a problem quickly(as the internet is full of garbage)
You are asking to unpack a whole lot of stuff, both real and theoretical
Many jobs are expecting a large pile of skills even from the newest of testers. Under five years seems to be considered ājuniorā and still the expectation is that the person has pretty extensive knowledge of quite a few technologies. Usually that son that even this newer tester will fit in with an existing soup of technologies. and it is unfortunately a puzzle piece matching scenario in which the adjudicator might be constrained by company demands or may even not have extensive QA experience themselves (and so approach the hiring of the role from their perspective as a developer) AND as a contractor you are expected to arrive and contribute on day 1. No easing into it.
So what do?
You might consider diving deep into one popular pairing of e2e framework and language. (python + Playwright, javascript + Cypress) the new automation tester roles seem to focus on the UI layer testing. Do lots of practice tests. Create a github and treat it like contributing to any product, with the associated branching, PRs and merges. this can serve as a portfolio for your work. THis might be your āinā then when āinā seek to find opportunities to work closely with developers and help them extend their own tests, unit and integration. Look for the missing cases. did they include negative tests? null inputs? this will get you exposure to other languages while providing examples of the tests in that language and you can figure out how to extend those examples.
Im leaving the AI part on the table. Mostly Ive found its use is currently best served as an idea generator.
I am currently in the job hunt and have 10 years of QA experience at a fortune 500 with a very complex system. We had around 650 people in the IT dept of which we had ~450 SEās , ~225 BAās and 47 QAās. Of the 47 QAās about 15 were contractors brought in to stand up an automation framework for products and teams that did not have one. The teams and products that had any automation were mainly created via developers (typically struggling devs or low level devs) The other 32 of us full time QAās , some of us begged to work on the automation, were told we were more valuable in the manual stuff and they didnāt want us handling any automation tasks.
Its a big quandary for companies, they want to automate but they donāt want to spend time on the uplift and adoption of the automation. Itās a cost on a balance sheet that doesnāt show immediate gains for business stakeholdersā¦who, most by the way, understand the upside of automation even less so then there IT counterparts.
The begging eventually led to an odd period of downtime when we were going through a leadership re-org and we had a whole business quarter (almost 4 months actually) to tighten up some stuff and they āallowedā us to attempt an automation project of an end -to-end workflow critical to our system, one that was also very time consuming to test.
We got paired with a few devs and were told we would learn the language/framework they wanted us to learn. The language they felt would be most beneficial. So we did our automation through Puppeteer, which isnāt even really a framework, using Typescript/JS as the coding language.
By the time we were done we were writing our own scripts and kicking them off from a prompt in a terminal manually, they were not in a pipeline.
Here I am thinking I am doing automation, and its not even a snippet of whatās needed. There were so many paths that could have been more effective and useful for my career going forward, but i just didnāt know.
Alas, I go on this rant because while automation shows up in almost every job description for QA in this day and age, I have had multiple interviews now where the automation scripting isnāt even part of the job in the end. It seems like these are companies that āwould like to have automationā but donāt have it, or they have one person trying it and need someone to help get it going. Yes, some companies have a robust automation framework and the ask of automation is legit, but those reqs seem to be more specific to automation ask.
Every time I see a QA req asking for 5 programming languages, automation and the whole nine yards of QAā¦then I see āpaying 75k/yrāā¦I laugh. Anyone with those skill sets taking that job has brain damage.
From my own perspective if I am hiring for a role that is primarily automation I would be looking for good coding skills.
I work with small teams so often that engineer would be working semi-solo, i.e they are part of the team they work with but need to be fairly autonomous on the automation and that takes good coding skills.
The market varies on this quite a lot though, larger teams can often be more flexible and bring in people who will build better coding skills over time. There are a lot of base level automators on the market, generally these are good at grinding out scripts but when it comes to the architecture they struggle, the ones with the architect skills are rarer but thatās often what is needed so that maybe the realistic expectation aspect.
Iād even put my own automation skills at that grinder level, I can code and I do quite a bit of automation but its average and I feel Iām fairly slow at it compared to my own expectations, its not my main focus though and I usually have access to a developer for some aspects. AI can assist quite a bit as a buddy but nowhere near as good as sitting beside a developer yet in my experience.
As primarily a tester rather than full on Automator I still feel I need basic coding skills and at a minimum be able to read and understand code as a secondary skill, this is becoming more normal.
My type of role is getting rarer though, where itās highly valued tend to be off-mainstream companies.
If you are learning its likely you need to be in the office as part of a larger team where you can grow and develop your skills, many teams still need the grinder level but as a contractor the expectations will again be much higher and at that level I do not feel itās not an unrealistic expectation for coding skills.
Low code tools on the face of it may offer something but I struggle to see the fun and learning aspect and they also tend to distance the automation from the team that may reduce learning even further, not sure they are best use of a testers skills as well but not an area Iāve looked at from a specific role focus perspective.
I know this thread hasnāt been active in a couple of weeks, but I actually used to work at a company that was basically a bridge between Hiring managers at companies with roles that need to be filled, and 3rd party agents with clients looking for jobs.
The reason job postings have all these odd and over the top requirements generally falls into one of two reasons:
The person that wrote up the posting has little to no knowledge of the job and made it up based on similar jobs from the past (almost always putting ALL the info from those postings without any regard to the seniority level/job title)
They are purposefully trying to make the job sound ridiculous for a reason, whether to weed out people that are too scared of not being āthe perfect fitā, try to find someone so desperate they will just apply to anything, or they want to fill the role internally but are required by law to also post it publicly.
Overall, the ridiculous requirements are almost always meaningless because very rarely does the actual Engineering or QA director/manager write them. If you like the company, apply whether you are perfectly qualified or not.
