Obstacles in Testing

I recently had a conversation with a tester who felt that they weren’t thriving as a tester anymore. They were able to do the job they were doing but they didn’t feel like they were advancing. It got me thinking that there must be others who feel the same way.

What do you think are the biggest obstacles a lot of testers face when it comes to thriving as a tester? And what can they do about it/them?


First I would suggest they see if there are any opportunities in their current role that they could start looking in. Are there any areas of testing they currently aren’t doing? Performance, security, accessibility, automation etc. If not then start learning about those and try to implement them into their current role. Or are there things they could try doing such as mentoring and coaching others to help them progress into a more lead role. I would recommend having a conversation with their line manager around this, be open about the lack of advancement, and they should be able to help with suggestions.

If this has already been done and they are still feeling like there isn’t any room to grow then they should start to consider if its time to move on. I’ve been in the same position where I was comfortable in my role, enjoyed my team but I felt like I wasn’t learning anymore. I decided that the best way for me to advance my career was to throw myself back into the deep end elsewhere and start learning new things.


This is a great topic.
I think its too easy to get stuck in to the 2 weekly sprint cycle of knocking out stories and meeting deadlines, so that time for learning becomes really squeezed. Trying to find 10% of your time to learn never works when its separate from the tasks you are allocated.
I agree with Amy (hello again, how are you?) in that as a tester, asking questions and investigating should be in our DNA, so start diving into new things. As an example, do you have any performance tests? Any non-functional requirements? No? Pick up Jmeter, start running tests and feed back the results, and look at the abject horror on your Product Owner’s face when they realise that the application is slower than they thought - and then reflect on how you as a tester made that happen without being asked, and the new skills you have learned.
Taking time to pop your head above the parapet and look around is always valuable. Ask yourself what is missing, and what could you do about it.


First of all - my sympathies to the tester who didn’t feel like they were advancing any more. I was in a scenario where I was technically doing my job, but I didn’t like it, I wasn’t being challenged, and therefore was definitely not thriving. It is not fun to be there.

When I was in that situation, I couldn’t take the monotony of just doing my job. So, I honestly started volunteering myself to do and help more. I would help coworker Y with running their manual test cases, I would offer to document coworker X’s automation code reviews, I started helping my project manager write specifications, I read the entire manual on the version control system we were using and could now be technical support for problems my coworkers came across, etc.

These little things added up to a strong driving force towards learning more, broadening my skill set, increasing the visibility of my value to my team, and helped me gain confidence for my biggest leap - I proposed to do all the manual and automated testing (a brand new skill I didn’t then have) for a new project. That was when I discovered that I truly am a programmer at heart. All things automation provided a never-ending stream of discovery, advancement, and improvement like Amy and Steve have both mentioned.

I feel like the analogy of a snowball getting bigger as it rolls down a hill is apt for describing my job satisfaction. The more I customized my job description, the happier I was. Now, I am in a very enjoyable and meaningful position, albeit with a very hard to pin down job title.

So my word of advise is that it could be worth rethinking what “advancing” means and how it can be attained. For me, my managers weren’t handing me advancement objectives and weren’t giving me opportunities to stretch myself. So - I redefined “advancement” as “doing something I wasn’t doing before” and allowed me to start finding opportunities for my “advancement” everywhere around me.

It is worth noting that promotions and career ladder advancements started falling into place for me even though I wasn’t following any prescribed career path.

Best of luck!


Welcome @deasa

I love the analogy of a snowball rolling down a hill, but rather than it being scary, you find it enjoyable!

Something I have noticed over the past 10 years is that emphasis on career development has moved from the manager to the individual (rightly in my view). So as a tester, lead, manager etc, you ‘own’ your career and should push if there’s more you want to do or learn. It very rare to have an offer to do more turned down, as you found.



Early in my career I was debating with myself if I should continue the testing track or the development track since I had done both. I was working in what was called System Verification at the time which meant that I mainly did integration testing (putting all pieces together) and various non-functional testing like resilience, performance, security etc. At that time I felt poor developers that are this little code factory. They get told to deliver a function without any context day in and day out and as a tester I was allowed to investigate any area of the product and business to facilitate the quality of my work. I chose testing there. Later I found that the “test hand me down features day in and day out” is a reality as a tester too, but the previous realization have always helped me to get out of it.
Let’s imagine that you sit in a team responsible for the reporting of your web application. The first order of business for me would be to learn about the ins and outs of that function. After I have gotten a handle on the technical side I typically learn about the business side. How do we as a company make money out of this function. This helps me understand what to prioritize in my testing, Helps me be a tester already at the inception of features raising potential problems with the feature given the impact it has technically and from the business. After this I can either try to talk to sales or support to learn more about the users of the function or with operations to understand what is different in production vs. testing. This is mainly designed to increase my coverage.

The key points is that those activities are part of your job as much as performing a test. And in the case of resistance, as in someone wondering why you need to learn these things, the argument is one of the follwing. Either to increase the productivity / efficiency by avoiding bugs / prioritize better or connected to quality in terms of higher quality feedback so we can take better decisions.

I maybe should add that my view of testing is that performing a test is a means to an end not the goal. The goal is to provide feedback to take better decisions and your entire value lies in quality in the information you provide.


My first testing job was fairly routine. I reported to the development manager and he didn’t really know anything about testing. He had his expectations and I met them.

I could have just done my job and everyone would have been happy. But I decided to challenge myself. Could I do the testing more efficiently? I started as a manual tester. I learned about automating tests. So I started automating tests.

Then I learned how to do automation more efficiently. It usually fails because the tests aren’t maintainable. How can I make the tests more maintainable? Essentially, what problems did I encounter or that others had encountered; find a solution and implement it.

I learned about different tests. Some are WHEN you test. Others are WHAT you are testing. I learned that testing wasn’t just testing. Unit Testing, Integration Testing, System Testing, UI Testing, API Testing, etc… The list goes on. I can learn different kinds of testing.

What tools are there? Learn a new tool and use it. What limitations did I encounter? Can I work around the tool? Should I use one tool for some tests but another tool for other tests? Maybe the limitations of tool1 make it suitable for tests 1 through 50 but tests 50 to 60 are easier to automate and maintain with tool2. So rather than one tool to automate them all, use two tools.

Selenium 1.0 was good for web testing. Watir was better for Windows/IE testing. Selenium 2.0 was better than both of them. Keep looking for better tools. QTP was better at visual testing (2005) but today I’d use something like percy.io. I always challenge myself to learn a better way to do testing.

What if there is no solution out there? Join an open source project or at least participate in the community.

What if the tools I use and the things I’m doing are covered? Go into the testing community (like here) and see what challenges others are facing. Maybe you can help them with their challenges. Doing something is a start. Understanding something is much better. Teaching something is really good. Get to the point you can teach.

Bottom line, I test because it makes me happy. It isn’t a job. It is a way of life for me. :slight_smile: