Struggling with learning new skills

I’m not surely exactly what I’m after here so hopefully I’ll figure that out as I type this…

I’m really struggling with JavaScript - and just learning to code in general. I know a bit of Python, I’ve spent nearly a year running automated tests with Python/Selenium. It was the first time my team had ever done it before and I did get a bit discouraged at how flaky it was, but lacked the skills to fix it. Despite that, I really enjoyed it.

Then I moved jobs. I was thrown straight into the deep end doing API testing with Java - two things I didn’t know. My brain hated Java and I just couldn’t seem to get it to click. I suffered serious imposter syndrome especially as I felt I couldn’t lean on my dev team.

These days, I’m in an agency where I do have the flexibility from my manager to pretty much do what I want. I feel very privileged to be in this position, but I have no idea what I’m doing.

I’m out of my depth, I can’t seem to get coding to “click” no matter how much time I spend on it… If I accept the fact I can’t code, what else can I do?

If you were in a position where you can learn and implement what you want, but struggle with the actual learning, what would you do?

As I side, there have been moments where I think “is testing even for me anymore” but I want to do this so here I am, trying to figure it all out.


Some random thoughts based on what I see above:

  • If you feel testing is not for you - get out of it - otherwise, you might be struggling a lot as time passes. I generally encourage people to get out of jobs they dislike, try a different team, different tasks, another company - if you still dislike it, move on and do something else. There’s usually ~30 years of work waiting ahead of you to be done and especially important enjoy.
  • There’s no need for more crappy/bad automation engineers - but fewer and better ones, as someone was saying;
  • If you like coding and are pretty decent at evaluating code - you could be a very good automation engineer or tool builder or maybe do quality assurance for the code that developers write in javascript(identifying all kinds of coding problems and fixing their issues).
  • How well are you with the fundamentals of testing? Usually, when you have problems at a higher level, it means you don’t understand well enough the basic things.
  • How well are you with the fundamentals of programming?
  • How about the fundamentals of web development?
  • Or is it about using specific libraries, or about automation engineering, or product architecture, or dealing with complexity?
  • What if not having a specific goal is a problem in itself? Maybe by establishing a goal, you identify that you already have enough knowledge to handle the situation?

This question is a bit generic; struggling with learning is ok - as long as I enjoy it, I see some sort of progress, have some slow but constant revelations or ‘victories’.
If you don’t enjoy it, rethink it that’s the only path to reaching what and where you want. Change of perspective, approach, tool, language, people, company, place, time, etc…


Question, since I’m not sure it’s answered and I think it’s important information: do you want to learn to code? Also, similar but actually very different question, do you want to do a job that involves writing a lot of code?

You ask what we would do in your situation, and well - I was there. I was in a situ until last year where I had loads of freedom and autonomy to learn and implement whatever I felt was best; and like you I didn’t feel I had the experience to be able to do that, or the devs to lean on to help implement the stuff I wanted to do. Mostly, I knew what needed doing, what could be valuable. I knew what a good breakdown of tests looked like, where they would live, what would be tested by each moving part and when. But setting it up? Battling through endless afternoons spent crying at my desk because I had no idea what this error even meant, and I didn’t understand the explanations on StackOverflow either? Feeling constantly on the cusp of understanding, waiting for the last piece of the puzzle to click into place where I might one day have a eureka moment and everything I was trying to do would finally be easier? It was the worst! At the very core of it, looking back now, I realise that I was being given all the time I needed to do things that were actually quite advanced. And as a beginner or intermediate person, you can have all the time in the universe and it will not help. And I didn’t want to think of myself as a beginner after all the time I had spent in self-guided learning, the experience I had in multiple languages and tools and frameworks. But I was/am.

When we’re learning a new branch of skills (I wouldn’t automation or coding a skill, it is a massive blinkin’ family of skills, many of which are invisible to the learner), a lot of us need a specific goal that we’re held unpressuredly accountable for, and people there who have the time and will to dedicate towards helping us meet it.

The more testers I talk to who are learning to code, the more I realise that the vast majority are not being given enough time and/or guidance to properly learn - and just because you’ve been given the time, doesn’t mean you can magic some learning direction and enough motivation to slog through the inevitable failures out of your bottom. You’re a person. No one expects a new dev just learning to code to be able to create complex React apps integrating with existing apis in the real world, without guidance. No one expects a new idk ops person learning their shizzle to be able to set up a balanced pipeline with authentication and monitoring across three environments and all that, without guidance. No one should be expecting a tester who is learning to code, to be able to pick it all up without solid guidance and learning objectives, and help from real humans who already know what they are doing.

It kind of annoys me tbh, because as companies and teams we know how to help people learning new skills. I see it with junior devs, coming in to existing projects and being given small bits of planned work that don’t delve too deep into the hard stuff to start off, then slowly being given more and more exposure to whacky functionality, the bits of the project that maybe aren’t that stable, where they will eventually be taught to wrestle with the same issues as everyone else. But many testers coming into automation don’t get that introduction. We have to go straight into the hardest part - setting up a project or framework. We have to work out all the issues junior devs have senior devs to help and guide them on, often without that senior figure who is accountable for our progress. And I guess this is partially because there’s been such an explosion in automation that there aren’t enough truly knowledgeable/experienced test automation engineers about to fill every team out there who has decided that automation is the answer to all their woes, and the ones that do exist are concentrated in great companies. Oh oops I’m on a rant, sorry.

As a slight aside on the ‘clicking’ of coding… I have not had that moment. I ended up moving to another company which already had a mature automation setup where other people had done the crying and tearing out of hair before me. So any time I’m stuck, can’t remember how to get X piece of information from the response and map it into a list of objects that I can compare against another list of objects, or whatever… Oh look, someone did something similar in this project, or that step file. I have other examples to look at which I know work for our exact environment and setup - not just slightly-related examples on StackOverflow or tutorial sites. So I have a playground with all the things I need to know in it already, all the parts are there, and I get to work out why they’re there, and how they fit together, without having to do it with most of the pieces missing. I get a lot less autonomy in this role than I did in my previous one, but I learnt a lot more about good structure and practices for test projects etc in three months here than I did in the two years before. And I feel like if I went back to having that autonomy now, I would be able to do much more with it this time because I’ve filled enough of the holes in my experience that I’m like a swiss cheese instead of a sieve. I just needed to go somewhere and be a junior and be taught things by people who wanted me to learn them, until understanding and solving stuff became easier. I haven’t had a click, but there’s been like… a dimmer switch, slowly bringing up the lights. And I literally did not realise that I wasn’t still sitting in the dark, until I wrote that sentence just now. xD

But yeah, I was very lucky to get the job I have now. And like you, I have had - and continue to have - times, days or weeks where I just think testing is not for me. But like you, I want to do it, I want to get good at it. I just needed the right environment that wanted me to get good at it enough to actually help.

Sorry for the big, possibly unintelligible paragraphs, and I hope that you resolve the things, and feel free to hit me up either on twitter or on the MOT slack if you ever want to rant at someone on the bad days.


Oh no, wall of text XD


In case it help, I tend to find:

  • There is so much I could learn, so much shiny, it’s hard to focus narrow enough to make good use of my limited time
  • Test code is software. So if we are building test automation we are developers.
  • The realisation I am a developer, has made me revaluate how I approach my learning for test automation
  • I need fill in gaps in my core knowledge about programming to make me a better automation Engineer
  • This is slowly helping me become a better automation engineer and Tester. But it is slow going
  • Support from other developers is very useful.
  • The opportunity to pair program with a more experienced developer to work together on a work project product code or automation, is worth 100 tutorials

Break down your coding tasks, write a few lines of code, test. Build on small successes.

This question from @ipstefan stuck out for me. The fundamentals was something I attempted to convey to testers when they wanted to learn to code. I think the fundamentals are still required regardless of what language you want to use.
I have thought about it enough to draft an outline for a series of blog posts on the basics (fundamentals was getting too long to type) of programming. I say programming (rather than coding) on purpose because the basics of programming are so essential to coding (the act of creating a program).
I commend your efforts, @froberts, in learning JavaScript and Java (while similar in syntax, there are coding differences between them). I have believed for a long time that a developer’s job is up to 50% frustration (the other half are a mix of actually creating a program, working with people, and some administration). I sense you are feeling that but you are also calling it out. You persevere and you also enjoy. I think you’re half way there. How did you answer @ipstefan’s question?

I liked this from @undevelopedbruce:

As always, they have great opinions and great experience to back it up. What I liked about that paragraph, specifically, was “massive blinkin’ family of skills” (as only they could put it).
From your post, it seemed you had a goal of learning to code and did not realize the iceberg that coding can be. Perhaps you could step back to look at the iceberg or “family of skills”. This brings me to your question.

I know what I would do because I know how I learn. I learn by doing and failing (a lot). It is frustrating. I break down what I want to do into very small pieces and work to complete a piece.
I also learn by reading. Usually, I’m in the middle of learning-by-doing and need to read about it. I’ll read just enough to keep going. Sometimes the direction is clear, sometimes I need more reading.

There are also goals:

For me, I needed to learn a handful of new applications. One application was a workflow development tool and another is a snooty data visualization tool. I stepped back and look at them and asked what are they really? The first one is a programming tool with a different interface, and the second is Excel with its graphs on too many energy drinks.
My point is, perhaps you have analogs that help you get some foundation. If there is, test that foundation. Try something and see if it works. When I’m in that mode, I care little for the end product because I’m trying to learn how to create end products.

When I code, I usually have an idea of what the program should do. I write a few lines and test. We’re already good at testing - it’s our super power. I encourage those new to coding to write a few lines and test. If there are too many lines of code written, then the test may fail and it’s more challenging to determine why. By writing a small number of lines of code, failure are easier to find because they are usually in the lines that were just added.

Thanks for reading this far! Continue to persevere!

Break down your coding tasks, write a few lines of code, test. Build on small successes.



I know how you feel. I’ve been a manual tester for almost 5 years but learning how to code and investing time in automation it is difficult to know where to start and how to start and extremely easy to get overwhelmed.

I’d recommend trying some of the paths on here:

I found it really useful especially the quiz elements and the opportunities to code along. Some of the sections are just a good decent overview of things and can help encourage you to work out what you want/enjoy learning.
I really hope you find something that excites you sometimes it isn’t the time you spend on something it is how engaged you feel with it that helps retain it. I have also been trying for many years and only really recently felt like I’ve made any headway. Keep a list of goals and what you have achieved some far as well so even at your darkest times you can remember how far you’ve come :slight_smile:


We all come across these struggles. Over the years, I figured that coding is not for me as a test script developer. I started as a developer, and worked in very complex modules like C compilers, so I am very good at development. But, test automation code development is just not for me.

I dread the maintenance of the scripts, setting up frameworks that involve a lot of scripting, and check test statuses through scripting.

So, I have charted my path. I have become a test strategist. I analyze the product in detail, and come up with test architecture, strategy, and test plans. I guide test engineers on how to go about things. I don’t do test automation, but I guide others on the overview level so that they can take care of it. There are people who can take care of it, so I would leave it to them.

I know it’s tough to choose like that when you are not senior enough and when you don’t have a say. But if you keep doing good test strategy and prove your mettle, the organisation/management would understand that you are good at it, and let you be.

Hope that helps, and all the best!


Wow, thank you for everyone for taking the time to reply to me - some of you in A LOT of detail. I really love this community and it’s times like this where I feel grateful (and lucky!) to have found this place.

Here comes a big wall of text replying to people…!

@ipstefan to answer yours… I do want to stay in testing, it’s just trying to find that area of testing that is for me. When I look back on my career my favourite part was when I was working in a small in-house team, and all three of us were trying to figure out this shiny new automation thing and we were constantly failing fast, and learning. I want that back again, in an ideal world. It’s just hard and discouraging at the moment as I feel like I’m alone.

The fundamentals of programming… I’m struggling with some of the basics, yeah. One example that stuck out to me is there was an exercise in my book where you had to loop through an array and print it out backwards. For the life of me I just couldn’t figure it out, but for most people, it probably sounds quite straightforwards!
If that is what you and @devtotest mean but fundamentals, then I hope that answers the question.
Fundamentals of testing… I like to think I’m okay with that!

@undevelopedbruce thank you for your wall of text, I can relate to all of it! I’m happy you have found a role now where you feel supported and have started plugging in those gaps.

@fullsnacktester I think I will have to try the pairing approach… being able to see how other people see a problem and break it down would be so helpful for me. More so than when I just find the answer somewhere.

@meowy24 I will check out that learning paths. I’m a little jaded towards tutorials because I often find they just give you some videos and away you go, without bridging the gap in between. I think a learning path of multiple tutorials with actual progression could be very useful.

@testervenkat thank you for this, and I’m glad you figured out what suits you more. I feel like I’m that position now where I’m close to figuring out what is good for me and what I want, but I’m just not quite there yet!

If anyone has made it this far in my post… thank you! We all love a wall of text :joy:


You are not the only one who hates JavaScript. My diss-like stems from the fact I was programming long before Java et al. got invented, I learned some intel dissasembly (which is invaluable even today), C, then modula2, then pascal (the original not the delphi junk) then cobol, then pascal again, then C++. And then JavaScript came along - and I’ve spent years hiding from Java, but am coming to like JavaScript lately.

I’m using linkedin learning , since I started a subscription years ago, so I’m forced to use it to get my moneys worth. But it is an expensive way to learn.


This is probably the one reason there will remain easy to land test automation jobs around for anyone who can test and code. And it’s because it is hard to do both. We do not actually allow ourselves enough time to learn as coders, I think @undevelopedbruce brought this home for me again, above. You cannot easily learn to code at the same time as you are doing your tester job. I self-taught myself programming years ago, I forget how it happened though. I’ve forgotten a lot of it. I’m now also trying to learn some C#, my motivation is to write plugins for a computer-game that I really like. Always be prepared to switch languages. For me it was firstly Pascal, then C, then Powershell, and now it’s Python.

A big thing to remember is that most testers learn interpreted or script languages, and compiled languages differ a lot with interpreted languages. And this difference gives automation engineers a superpower that most developers who compile their code don’t always have. I think you get my line here, learning to program will involve learning many languages too, but always have a favourite one you can bang out something quickly with.


My favourite language is python and I don’t know if it’s because it’s the first one I learned so I didn’t have any pressure on myself, or if it’s just a nice language.

You cannot easily learn to code at the same time as you are doing your tester job.

I think I have realised this now for myself :pensive: although to be honest I’m persevering with it in the hopes that if I keep trying new things and different approaches, I’ll find my way of working/learning. I sometimes wonder if I was given total autonomy in my role too early, or if that’s just imposter syndrome speaking.


Imposter syndrome! You can still be given autonomy in your role, while having adequate support to learn and grow further. Those things are not mutually exclusive. Which you probably already know, but sometimes it’s good to hear people say. It is not a matter of you not being ready or good enough to be allowed to make decisions and be in charge of your direction, learning and tasks. You are ready. You were given the job because someone thought you were ready. And if you’re struggling to learn at a pace that you find satisfactory in the role, then it is totally acceptable to ask for support, without conceding your autonomy to make your own decisions. But then it’s easy for me to say that when I don’t know what the culture is like in your workplace. xD But also you sound like an intelligent, thoughtful person with a lot of common sense and a strong desire to learn and perform well. So I find it unlikely that you are undeserving of your role.


Thank you for your thoughtful reply, Bruce. I may just print out this reply and stick it onto my monitor so I see it every day :joy: I definitely need to remind myself of this often!


Pahaha do it! I have a wall covered in nice things people have said about me printed out. xD It is a really nice thing to have and add to over time.


Saw this today and thought of this thread. I’m not saying it applies to anyone here but rather as another point of view on learning.



Thank you for sharing this, Joe. It resonated with me and echoed a lot of the sentiments above :slightly_smiling_face:


Here are some questions to better understand your situation before suggesting solutions.

Did the company make a plan to prepare you for your work? Is there a specific problem to solve at work and do you need guidance for it?

What exactly is not clicking?

Can you share some details about what you are trying to achieve (but not too much or anything that would violate NDAs)? Its hard to suggest something without knowing a little bit about it.


Sometimes I find that people can overcomplicate test automation code. You don’t need to be a true expert in coding in my opinion. Also there’s many codeless test automation tools. This is super hot for 2021 and beyond. I believe it will get real momentum in the next year’s.

Angie Jones created a test automation site where you can learn automation skills - have you heard of it? It’s an amazing site that may help you.


And to just say, I relate to this. Sometimes I struggle with “studying”. I can’t have someone talk at me - I need practical exercises and visuals rather than text.