Automation testers struggle with manual testing

There are a lot of automation ā€œengineersā€ out there that are the test equivalent of code monkeys. They can copy-paste and modify/extend existing tests, but often struggle with any actual ā€œengineeringā€ work or testing, i.e. they donā€™t realize when they should be refactoring, approaching problems differently, missing the forest for the trees, etc, and they can only implement test cases that are spelled out clearly in acceptance criteria, really struggle to shift left and participate in requirement gathering or design discussions, etc.

My theory is that this is due to all the bootcamps and online courses out there professing to teach test automation. Folks get lured in by glossy sales pitches and dreams of large salaries, but donā€™t do their homework to realize that these type of training programs essentially get your foot in the door, and tech is one of those careers where you need to be constantly growing and evolving.

Often, these people have no actual interest or passion for tech nor testing, so it becomes really hard for them to push themselves to develop the deeper understanding and to build the context and skill sets they need to be strong coders and/or testers.

7 Likes

This is an interesting one, I do often think of automation and manual testers as two totally different types of tester. Automation testers are usually testing at a high level and their main skills is getting the technical side of the automation working e.g. finding the best elements to select to avoid flaky tests etc.
Manual testers on the other hand go into deep dives and should be leaving no stone unturned. The automation testers pick up the easy repetitive tests leaving the manual testers to work their magic with their exploratory and other non-functional skills

Saying that I do try and get some of the automation testers to do a bit of manual testing from time to time. Rough Ratio of 95:05 just so they keep some of their testing brain

3 Likes

Hi @katepaulk

I think you are quite rare in not minding switching from automation to manual, as many testers find it boring.
One thing that you mentioned does resonate with me as I hear it a lot - testers not getting the time to invest in keeping automation skills going. Its difficult as often manual testing is prioritised which does mean less time honing coding skills - and its probably ok for a day or two, but if its a week or more, then I can see it becomes difficult to get back into what you were working on before.

I hope that you and your company can find a way through the interesting personnel challenges that you have (I love that phrase btw!).

Steve

3 Likes

For me this flags some of the huge fundamental views around testing particularly when the term manual is loosely utilised. For me manual means scripted testing and I have to admit I find scripted testing painfully dull but similarly coding automation for me is not really that interesting either, useful but not that interesting for me. I used to code production and lost interest so if I spend more time on automation I may as well go back to coding production products directly.

I suspect low code tools for me would be even more on the dull side.

So for me both manual and automated scripted testing is fairly dull.

On the other hand though I love testing, discovery, experiments, tools, exploring, investigation, research analysis, collaboration, analytics, sociology, psychology and the whole risk aspect of never quite knowing what you are going to find.

The things I love about testing for some it does not even come on to their radar as being what testing is all about because for them its something else and in many cases all they have encountered is scripted testing.

I do not think automation engineers have much of a problem with manual scripted testing at all, maybe a little short in the script design side as optimising a script for automation has a different focus.

I do though think a lot of manual testers and automation engineers will struggle with testing with much more of a discovery focus and that is often because its not a focus for a lot of companies and all their focus is more on scripted testing.

4 Likes

Yes, you are right. I donā€™t do scripted testing at all, so I havenā€™t realized that some companies use test scripts a lot. I meant unstructured testing (like the exploratory one). I would have a hard time with scripted testing as well.

2 Likes

As a developer who switched to test automation, and eventually doing both manual testing & test automation, I did actually struggle at some point, but I always believed that if you did not struggle, you didnā€™t learn anything new from the experience.

When I freshly transitioned to QA as a manual tester, the pressure is indeed high because my peers expect me to be much more well-versed since I can see the internal workings of the application, which I told them that if I rely on the code itself, bias will eventually develop and will rely on what developers worked on rather than the requirements itself.

My team leader gave me a valuable advice - look at the system as a business user and slowly steer away from being tempted to look at the code, debug the code, or even attempt to fix the code (since I came from a software development role) - it is no longer my job to help them and there are much better ways to help them resolve easily, such as stack traces, error messages, replications that hopefully is not intermittent. Be the advocate of quality by getting through the experience itself.

In my experience, itā€™s the lack of opportunities available for them to give their all on manual testing that prevents them to acquire the tester mindset. Itā€™s fun to be always curious and creative, but it gets killed easily when your peers do not support it (for biases of Dev vs. QA salaries), thus the opportunity loss.

I hope this helps. :smiley:

7 Likes

Sorry for late answer been on holiday tripsā€¦
What you write is true, but I am thinking the other way around. I do find vaults and understand sytems, and do it good. But automation is a programming activity, and while having programmed in different ways since BASIC in the 1970ā€™s I have never had the spirit for progamming. Other guys lose sleep over progamming problems and get flow from programming but I do not. I do however do get flow from verifying and finding bugs. I am a much better tester than a programmer. So why should I automate and not guys that do it best?

Ok, I can admit getting slightly absorbed making our selenium suites running, and running better, but I constantly have a feeling of being the wrong guy doing it.

I know that tis is kind of reverse the thread title, but I kind of wanted to make the case for the other way around too.

5 Likes

Kind of. If you test something fairly trivial to automate.

If on the other hand the automation turns into being a pretty complicated programming task its a matter of programming competence/lust. To find the necessary test case to verify the programmers product as well as being the little devil that find those bugs, thats both - as I see it - as necessary skills for a SW tester(probably any kind of tester), but being a geek is something else.

Testers understands best what test cases are needed. If the ā€œautomation testerā€ is really a programmer, sharing skills is probably a good idea.

2 Likes

Again, sorry for a late reply. Havent been in MoT for a good while.
Automation has been a discussion at my operations, but since it is government funded there seem to be noone prepared to pay the costā€¦ guess some of you have heard that story.

Anyhow, the discussions are not only among the testers but also among the programmers that do see the benefits of e2e automation. Our current best thinking is that the programmers should set up the framework and do the architecture. It would be, frankly, stupid to assume that guys that do program only once in a while should be able to make the testing framework as guys that have been programming as a profession and a passion for decades. We have a very low grade of automation, and I work closely with several teams of programmers. I do have a, dare I say, a very good view of what requirements mean in terms of the Web programming we do, and do communicate and take part in the development very early in the process. And I see what they do programmatically. While finding loads of bugs in what they do, thats my passion, I have the deepest respect for the craftmanship of making well structured data programs, and I know much enough about programming to understand that - a tester will not do a program as good as a programmer. And a non-trivial test automation is a quite complex computer program. So what not let the guys that are the proā€™s do what they do best?