Hi, I have seen quite a few automation testers to struggle when they had to do manual testing. Whereas not the other way round (manual tester learns how to code). It has been a big surprise for me. Does someone have any insight into this? I thought that both types of testers are using similar mindset when planning and creating tests. Or not? Thanks a lot for your opinions and experience.
This is exactly what I see day to day. When I interview automation engineers, they can talk about tech and they know their tech and that’s all fine but when it comes to testing… actual testing. They often don’t know anything. They just like to write code… they don’t care that much about breaking down applications.
A lot of techies leaving school, might chose the path of test automation engineer, but they lack the skill of actual testing. They get into a bootcamp/traineeship, learning all cool kinds of frameworks and get an ISTQB but … what they don’t learn is actual testing. They just automate written test cases and can’t think of any themselves. Which is a big issue!
That’s why I would prefer to hire a tester who started out manual testing and then moved to automation testing.
Fall into this trap often. Got reminded today by Mareet P, that it’s more important to exploratory test the entire product before you start automating. before , yes, do not rush into automating a thing. Failed at that so often now it’s embarrassing.
Great question / observation @ivana_jones.
I have similar views to what has been said already.
TLDR: It’s hard to do both well, but not impossible. All depends on the person.
For me, a tester has a host of skills, which may include automation. I’ve worked with people who are great automaters and testers. And also many more who struggle to do both well.
From what I’ve seen it can be difficult to learn automation as a tester. I’ve created automation training in a previous role. To help “manual testers” learn automation. There’s so much to understand even before people can write a test, which is a barrier. For example, coding basics, version control, automated test design, maybe even docker.
Ultimately it all depends on the person. If the person wants to get better, they’ll seek out new idea and information. Hopefully with support from colleagues or the community.
I definitely agree with your observations. Personally, I think that automation testers should be regarded as developers (but they need testing experience to make the right decisions).
A manual tester would need a testers mindset and skillset.
A test automation developer would need a testers mindset but a developers skillset
A developer without testing experience (or the testing mindset) would struggle to make the right decisions regarding automation, but would not have any issues actually creating the tests. Unfortunately, without help from testing, the tests they do develop may not be very useful.
A tester without development skills would know which tests to develop, but may struggle with actually developing them. Without help from development, the tests would not exist to begin with.
I am a manual tester who moved to automation, so would definitely agree with the statement that a manual tester could develop automated tests. However, I don’t think a tester could go straight from manual testing to automation development without having the relevant skills and experience in the first place. For me, the transition from manual tester to automation developer was seamless because I’d spent years in jobs where I did both.
A manual tester could easily run tests and investigate failures. They could also carry out basic updates and maintenance of existing tests (in fact, this is a great way for testers to being to develop those essential development skills).
However, creating new tests or setting up an entire automation framework is a lot more advanced. These skills require more time to develop and most manual testers I know would struggle with this part of test automation development unless they already had the skills.
What I see is script focused testers whether they are manual or using automation struggle with discovery focused testing.
The goals, objectives and values are very different. Discovery focused testing tends to be in my experience broader, deeper and often much more collaborative with team, customer and end user than script focused testing.
The automation vs manual fails usually because they both tend to be talking only about script focused testing.
Both will struggle with discovery focused testing but there is no reason why both cannot study and learn this but they do need to be in an environment that understands and sees the value in the difference.
Thank you for sharing your experience. I wasn’t sure if my observation was correct but you exactly described what I’ve seen.
I have a very dear friend, who is a bit like this, he’s amazing when it comes to figuring out code-related problems, but when he needs to explore the app or execute some manual test or anything not related to coding, he just gets lost - like searching for an issue in Jira he pings me to help him out, and on the other hand, I’ll ping him when I need to debug a fail automated check, or something similar.
I’ve told him a few times that he’s not a QA, he’s a developer at heart, who was pushed into a QA role since his first company had an opening for that - this often happens unfortunately, the company sees an opportunity to bill you to their client and they don’t give a shit if they are pushing you into something that might not be suited for you.
My friend found himself loving to write automation code, but I think he would be better of as a developer - he’d make a fantastic developer, way better than the average, considering he’s been a QA for a few years and knows how to test.
Yes, the statement is completely true as automation testers are not familiar with the basics of testing such as coding and understanding the manual aspect of automation. Manual testers, on the other hand, have a very thorough understanding of code and test process that makes things much more streamlined when working on an automation testing tool.
That’s interesting (and sad at the same time). Does your friend create test cases from scratch? Or does he follow scripts for manual testing? On the other hand, if he left for being a developer, than he would be missing in test automation, right? It looks quite tricky, this situation.
I’ve got a slightly forward looking follow on question.
How can we support automation, and scripted focused Testers improve their investigative and discover focused testing skills?
He did work as a manual tester for the first few months, then he moved to automation. I think the best scenario for him would be to move to a company where developers are expected to be heavily involved with automation, or maybe some SDET role where he will be doing more than just automating some test cases, but also creating tooling, providing support to manual testers to learn automation, a coaching sort of a role, with lot of coding involved.
I was thinking about your question, and I don’t think there is a quick instant solution. I believe that investigative skills need to be developed over time - by doing frequent investigations and discoveries. Like 1 hour a day (or at least every second day), similar to learning how to code. If we talk about people who would have the time and willingness to learn (and have potential), then there are many ways how to learn. I think it might be easier to start on a neutral web app, like an e-shop or a similar web app as the project they are currently working on. So they can practice their observation and investigative skills only. Also, I think it’s very important to think about software in a ‘holistic’ way - how will our customers use it? What’s the reason why we build this software? What practical situations is this software supposed to solve? I believe that’s an important part of QA as well. If we build great software, but we will miss our target customers, then the quality isn’t so great (quality = ability to be used). Therefore thinking in context is crucial. Having an open mind about all possibilities is necessary as well - i.e. even business requirements can translate the initial business idea incorrectly. And we are paid to discover that - because we have the advantage of seeing at least a part of our app in reality (whereas product people and BA work mainly with ideas and designs). A few examples for practising = On e-shops, Filters are a great place to start for people who prefer the backend (numbers, business logic). Especially if there are filters on different pages (or if they are nested etc.). Finding a bug there is quite easy and fun. A role play might also be a fun way how to practice. Decide on a test scenario (e.g. find three items and put them in your shopping basket). Then pretend that you are a businesswoman in a hurry and frantically searching for these three items. She has max. five minutes, then she’s leaving. After that, pretend that you are a male who needs to buy three things but hates shopping. So doesn’t want to be overwhelmed by tons of info. And then pretend to be a teenage girl who loves shopping, who chooses these three items carefully considering their ingredients, colours etc. You will see that you will get different feelings and results about the app. Obviously, you can also just open your app on different devices and try the same scenario on each. So you will see how the same business idea looks differently on other devices. These are just a few quick ideas, but I am pretty much sure people could share way more ideas here
100% want to be sure we don’t completely filter out individual experiences.
I for example see lots of manual testers saying that attention to detail and logical thinking actually made them better programmers when they finally turned their hand to learning how to code. I’m also convinced that manual testers are far more likely to “play” and discover anomalies in an app, not because their play is unstructured, but because for them, it overall yields more “early” discoveries than an automation or coder mindset yields. The ability to move early, and move fast when it matters most.
So yes, as a coder, I struggle with manual testing, but not because I don’t know the product well (which is actually a valid reason coders do struggle.) But because the way I start off a manual test session is more often than not, too rigid. And from there I miss out on discoveries.
30+ys as a (quite average) programmer and also (I like to think above average) manager, project leader, test leader, tester, troubleshooter has learned me this:
Testing is one kind of activity
Programming is another kind of activity.
Some people got both capabilitities, some have one or the other. And there are totally different kind of passions that drives one or the other forward. I have none whatsoever love for say knowing what a Factory Class is, I can understand it but it does nothing for me. Understanding a complex system and make it work in the external interfaces, being the guy people ask when they want to know how this box is supposed to work with that box makes me skip beer evenings still.
I have met loads of guys with a fling for both worlds, but they aint many. Managers all over the place used to think all tester easily was to be transferred easily to become automators, they seem to have learned the lesson now.
Of course the same applies the other way around.
This is a good question @ivana_jones
I think a lot of other responses have pretty much nailed it - its really to do with the individual’s background and the path that they took towards their current role. Moving from being a tester to an automation role is far different from moving from a developer role to an automation role as you have a coding background but not a testing one. Developers learn about unit testing but not about the role of a tester.
I believe in what I call the ‘testers mindset’, where we as testers look at something analytically to determine how it should work, what we need to test to prove the requirements are met, and what to test to find out what could go wrong. Developers are not trained to think in the same way, so there is going to be a struggle for someone with a pure coding background to come into a manual testing role - its like asking an electrician to lay some tiles because its a task that needs doing as part of the same bathroom refurbishment. If you havent the training, you cant do the job.
Testers who have moved from a manual to an automation role can easily transition back as they had the initial training and mindset (I’ve see a lot of this) - although its not always that interesting for them to do so
Hope you all fine. struggle is an essential part of success. Manual testing could lead to automation effective testing
Speaking as one of those rare critters that is more or less equally capable of manual testing and automation, I’ve got to say that my biggest issue is balancing both skill-sets. I don’t get the time I’d like to work on automation, but I don’t want to spend all my time on automation - a nice balance of exploratory testing and automation work seems nearly impossible to find.
It doesn’t help that I’m the only tester in my group, or that we’re having some… interesting personnel challenges right now.
On the manual side I like tracking down problems and figuring out how to reproduce them. I also don’t mind the relatively mindless work of following a prepared script (usually one I prepared) for manual regression, or retesting something, especially when I’m tired and finding it hard to think.
On the automation side, I like working out how to make the test code do what I need to do for the regression checks. There’s not much to match the feeling when you solve a problem that’s been bothering you for a while… Actually that applies to the manual side as well.
I guess that says it all for me: I like being able to solve problems. Whether I’m doing that through code or through exploring the software isn’t as important to me as solving the problems I get faced with.
It seems plausible to me, but I am not really sure if its true. I always wonder if most developers can learn “just enough testing” to become at least as good as the “average” QA. Maybe all devs might not be able to become as good as the “exceptional” QAs, but just good enough to reduce the headcount in their QA teams.
Its an interesting consideration. Testing and testers themselves is such a broad area and even among ourselves we can have massively different views with regards to what testing is about.
There are a lot of both testers and companies that focus primarily on scripted testing.
In my experience developers are normally very capable of covering the testing that can be scripted and on newish products I would even go as far as saying its optimal for developers to cover this.
When testing adjusts though to be more discovery focused I’ve generally found the testers are a level above and I’d say its harder for developers to cover what this group does. It accepts that developers are human and therefore fallible and risks are very real things that are not going away any time soon. It can of course be coached over time but it is deep and broad knowledge area so its going to be tough and carry more risk.
So where developers can cover the scripted side of testing and the known risks, for many teams this will already reduce a lot of waste and reduce the need testers doing these same tasks but those smaller number of exceptional QA’s with a focus on discovery and ideally some coaching skills remain of a lot of value even when developers are skilled in and doing a lot of testing.
It is my preferred model in most contexts particularly early product lifecycle before your regression risk gets a bit on the wild side.