When it comes to some of the QA, they are some emphasis on automation and programming even in some of the āTesterā roles.
Like learning playwright, JavaScript or selenium.
But if a tester enjoys aspects like exploratory testing, accessibility testing and manual testing, more than automation, how can they progress if there is demand with automation?
Would they need to take a side path?
Every answer to a software development question starts with āIt dependsā¦ā
With that in mind, it dependsā¦
Iāve spent the last 25+ years flipping between development and testing. When I have been testing, there has been a lot of automation involved. Also development of test tools. But a big part of identifying automated tests has been manual, exploratory testing. Also clarifying requirements and hunting down test cases specified or suggested within those requirements. Sometimes you need to lean into code a bit more (for example, non-functional testing of highly application-specific functionality), but often you do not.
Some things that I advocate right now are developers taking responsibility for their work by doing their own testing - and also synchronous teamwork in pairs or mobs. These sorts of things are ripe opportunities for a manual tester to take advantage of.
Because of this advocacy, I get people telling me (a lot) about how developers donāt have a ātesting mindsetā and are awful at testing, as a result. That they only focus on validating that software works, rather than investigating where it can fail. My standard response is that it isnt a skill issue, but a training issue. However, there are obvious opportunities for someone with testing expertise.
If developers are not very good at identifying test cases, a testing expert can identify tests for a coding expert to implement. It isnt necessarily the case that itās an either/or situation. And research into applicable test cases (that is, exploratory testing) is definitely something a manual tester can do.
There are also opportunities for pairing and mobbing with developers, filling the skills gap with your testing expertise and experience. Coaching them into good approaches to quality. It does depend on the flexibility of your environment (especially in terms of switching from working in isolation, to working with others directly) and whether your management has a fixed view of what is needed, or are open to suggestions from a testing expert.
I certainly do not see it as a dead end, if you are not interested in coding. Itās not entirely straightforward, either. You need to take hold of your career progression, instead of letting others decide it for you.
Show them the demand in exploratory testing, accessibility testing and manual testing. Companies are often blind in what they need and just yell āautomationā - " Robots" - āmore developersā which often doesnāt solve it.
Show them the importants of something like accessibility testing and grow into that domain and become a leader/expert!
Automation isnāt always the future 
I stepped away from it also
Yeah I noticed some of them mentioned automation and no one in the team can code or use an automation tool. Learning it all from scratch
They want automation to reduce the amount of manual testing
Automation and manual testing arenāt opposites, unfortunately. If manual testing means active hands-on exploration of the software, and the risk assessment and test design and strategy building that that involves, then thatās a requirement for automation also. Otherwise, how we would know what to tell the automation to do, and how would we interpret the results?
I think the problem might be that a certain kind of manual testing, where very simple checks are made with written test cases, looks like it can be replaced with automation tools. The issue there is that humans doing testing is more powerful than tools doing checks, even if the testing is shallow. The solution, to me, would be to put the agency and responsibility into the hands of testers, and then use the automation tools to support that effort where itās appropriate. Obviously thatās not always possible, and on occasion not the best course of action.
If you want to add automation to your roster you donāt lose your other skills automatically. That is to say you can be a āmanualā tester who knows how to use automation tools and thatās perfectly okay. If you take an automation role thereās a reasonable chance youāll spend a lot of time writing, debugging, fixing, running and reviewing code and its output. Thatāll depend on your situation. There are companies that will let you test, some that want you to follow lists of instructions, and others that want you to put the instructions in a computer. Finding the right role is difficult, but thatās the true answer to your question, I think.
This challenge faces a lot of of testers.
Its the fun and motivation factor that goes the experiments and investigative side of testing that they both enjoy and feel its the highest value they offer, the wonder of just not knowing what you will discover today is a big part of it.
Automation for me is a very different skill and mindset, its more a building and problem solving hat for me. Yes there are elements of good test design but when Iām working on automation my focus is usually getting the tool to do what I want it too and to get things stable so they are of value.
I would suggest learning automation regardless though, a lot of times it can just get your foot in the door and broaden your toolbox which is a good thing.
On the otherside you can go deeper into specific risks, accessibility remains a good one as more compliance laws are coming out in many countries at the moment but also something like security and penetration testing fits really well with that exploratory and investigative fun side of things.
Being able to strongly argue the value of the types of testing is really important, I sometimes talk about hands on, highly technical, risk based testing instead of using the term manual for example. Maybe not those exact words but using language in a way emphasise its higher value that may not currently be seen by others.
You may also need to be very selective when choosing companies that get this as many mainstream companies and sellers of automation will try and push testers down that builder path rather then discovery, exploration and investigative paths.
@andrewkelly2555 I would say I enjoy automation. I feel itās just getting better at doing the live coding tasks in a job interview. I find that the tricky part. When you on the spot it feels like itās more pressure. But I feel like I enjoy coding and automation.
I enjoy using Playwright and JavaScript