“I can’t code. Is my job/career at risk?”
Answers on a postcard. 
(Also known as: is ‘manual testing’ dying)
3 Likes
No, testing by human is because of human’s critical thinking, curiosity, researching skills, collaboration with right stakeholders, empathy while testing, and yes it is true human user of the system in the end.
Coding skills are important to move forward for any testing professionals who still want to be amazing in the fast moving SDLC.
2 Likes
I wonder if we ought to be trying to replace the term “manual testing” with something that gives a better impression of what it is we’re trying to test for. “User Error Mitigation Testing”, perhaps?
4 Likes
This XKCD about time spent automating tasks also applies to testing, IMO:
Not everything can be automated, and some things just aren’t worth automating. Even if something can be automated, the quality of information that you get from automated checks can be of a poor quality compared to what a human can tell you. Even where automated checks are valuable, a human is often (always?) required to verify failures and take appropriate action.
Therefore, the value of skilled exploratory testers is unlikely to evaporate any time soon. That’s not to say that automation is not a valuable skill to learn - in fact, I’d argue that the best, most robust automated checks are written by skilled exploratory testers.
3 Likes
Quality investigation? Quality researching? 
1 Like
“I can’t code” -> would you like to learn a little bit about it?
Try some Coding Pirates…
“Is my job/career at risk” -> No, but it might be changing.
It might be changing to focus on helping others to setup the tests.
3 Likes
Why not treat this as other risks, break it down and explore it a bit further?
Let’s ask a for more questions:
Q1) Is traditional manual software testing at risk of changing?
A) Yes! Embrace it, lead the change don’t let it “happen” to you
Q2) Will all future testing be automated?
A2) No, but hopefully an increasing amount of repeatable execution will be automated. That still leaves room for a lot of value to be added by Test Analysts and Exploratory Testers.
Q3) What are you going to do about it?
A3) I hope now is an excellent time to be inspired to get more technical. Being able to read code, understand in more depth about deploying and running software. If your lucky and interested you could get involved in debugging, log analysis and bug-fixing. You can also do a lot to support test-automation, without being a software developer.
Controversial comment (opinion):
In my experience, it is rare to find a single person who is both a good test analyst, and a good software automation Engineer. I think there is an ideal pairing/team to be created from Test Analysts and Software Developers to work together to great excellent automation. If your not interested in getting deeper with development, I would highly recommend you focus on being an excellent Analyst. This would also give you transferable and related skills, in roles such as Business Analysis.
Hope this helps
8 Likes
I think your answer is perfect! Like everything in software development, software testing is also changing and everyone involved needs to be part of the change.
There is always going to be room and need for manual testing, but that can’t be your only contribution to your team. If you don’t do more, even if that doesn’t mean test automation, you are in risk of being left without a position.
2 Likes
Exactly - actually manual test execution takes up way less then 50% of my day as a Senior Test Analyst. And I don’t do much automating 
1 Like
Greetings!
In my opinion, the scope of manual testing is changing and shifting (shifting left!). While there may be some opportunity for manual testing of a software product, the test cases must be written to explore risk and a few edge cases. I think the larger opportunities are at the beginning of product construction.
Learning to code will help you parse things you might see in Visual Studio, Eclipse, or other IDE. It will also provide a foundation for design but it may not be necessary. The design of a product is very much driven by a business need.
I encourage you to listen on conversations about product design and ask questions around the various choices and terminology to learn how business need gets translated to code. Use your testing background to probe designs for testability, fault tolerance, flexibility, and first simplest implementation. These questions just might be the new manual testing and they occur at the started of product construction - shifting your focus left!
Don’t stop there! You know about and design tests for risk. Take what you learn about the design and investigate it for risk. Then, start asking questions about the risk in the requirements (YES, the requirements), the design, and the implementation.
My suggestions take you well beyond the current understanding of “manual testing” but they are within your skill set. Tap your curiosity, learn about systems, facilitate collaboration, and engage your project team during planning and design stages.
Joe
I think the answer to this is partially related to your own company’s context. I know some companies have stopped hiring testers who don’t code (or hiring testers at all!) and instead only hire automation engineers or rely on developers to do all the testing. But for every company I’ve seen that’s doing this, I also see companies who are embracing the role of of a tester and everything it can entail.
I think that the role of a tester is expanding, in many different directions. There are the ways that @devtotest described, for some excellent examples. Learning to code is just one of the ways that the role can change.
In my personal experience, I’ve made efforts to learn to code and have discovered it’s just not something I enjoy doing. But I’ve found that learning to read code has been an incredibly valuable skill. Also learning about design patterns and other code conventions has helped me relate to the developers on my team and collaborate with them on system design. While I don’t think I will ever be a dedicated automation engineer or other type of programmer, the skills I’ve learned have definitely helped me be a better tester overall.
2 Likes
I am really sure…if you keep thinking about dying or living …You will die for sure 1 day.
Better Do you testing (either functional or automated) with full passion. Then, you will not think about all this stuff.
Coming to main question, I am so called Manual tester and trying to learn programming language, Just Basic level. WHat i have found is that it opens your mind in broader way to test the application.
What is good is that in also,…More your learn in different technologies …More it will help in your testing in thinking perspective.
I have seen many people doing automation testing…They just making fools of client by clicking and retrieving the behavior of element and automate nearby that flashing HTML Reports.
But, if you learn everything about every technology and work…It will be helpful in long run in the testing career and will place you above all as a "“TECHNICAL TESTER”.
Then, so called Manual testing or whatever will not die…Instead of that, It will live for forever.
Yes.
Sorry, but no amount of reality will stop companies from trying to save money. Testing can’t be automated, there’s a different mindset to testing, check vs test; it’s all great and true and vital to testing but as far as wider business is concerned (with few counterexamples) I’ve seen nothing but a slide into the depths. I became a tester to explore. Now the industry wants to put things in the way of the freedom of that exploration.
You will need to follow this change to remain relevant. That is what businesses need, even if it’s not what they should do. We love quality, companies love cost effective application of resources to achieve the minimum amount of expense for the maximum amount of profit - and if that means making the testing job boring and repetitive, driving out the most passionate and creative or people who just don’t like coding on large development projects, then that’s what’s going to happen.
1 Like
Actually no, your job won’t be at risk. You cannot be replaced because your role profile has changed. But you may be asked to upskill and you should push your employer to support this anyway.
Even though you can’t be replaced, good luck in getting another tester role if you cannot code, which is the sentiment in this post I believe.
I should add, learning to code isn’t just about being able to automate. Being able to script a myriad of simple tasks is a real timesaver. And understanding how code is built, the problems that occur and therefore where there is greater risks has to be of interest to testers.
I think that depends on what we mean by “at risk”, I suppose. I’d consider being forced into coding a huge negative, and therefore a risk to my job. I may not be fired, but I wouldn’t want to do it any more. I can code, and I’ve written a lot of tools, and a few Selenium suites, and I’ve worked with other proprietary test automation systems, and I despise the monotony and the overhead of behemoth automation projects. They are useful tools, but the tools are becoming a replacement for thought and craft instead of being an aide. I also think that when we force testers into coding positions we deny ourselves those that have no love for coding and reduce the diversity of our teams, and diversity is important to support testing’s inductive natures. In that sense I’d say it’s at risk.
3 Likes
To me writing code is not important, the ability to read and have a basic understanding of it is.
just makes you a better communicator if you can discuss it with a Dev more in there own language. (yes Devs do have there own language).
I come from a basic SQL and SAS background and find communication and understanding when passing back basic results from test sessions have a greater Value.
Manual Testing will never be “Dead” no matter how good a computer is It cant replicate a user at 9am on a Monday morning half asleep clicking and pushing random buttons and bringing down the system.
1 Like
No. Automating a test is HOW you conduct the test. It is not WHAT you test. Some people know WHAT to test and this is always valuable. I’ve worked with clients who have testers who do not automate. I have them pair with coders. The tester figures out what to test and the coder figures out how to automate it.
That said, what to test is a skill and how to automate the test is a skill. If you can do both, you are going to be more valuable to a company. But a lot of times I see coders who can automate a test but often miss important tests. So they’ll still need someone who knows what to test.
3 Likes
I like the part “fast moving SDLC” 
1 Like
Manual testing isn’t anywhere near the point where it isn’t needed anymore. And not having a technical background isn’t necessarily a bad thing, depending on the application you are testing. I agree that there are very few developers that can successfully switch between a development and test role. In general, developers don’t make good testers. There are exceptions, but in over twenty years of testing, these are truly exceptions to the rule.
However, having come from a Customer Service background, I can say that taking the initiative to learn at least some technical aspects of the program you are testing, goes a long way with the developers in regards to credibility. You will receive less push-back on issues and you find and a greater willingness on the developers part to have a conversation with you, as a tester, on what makes something tick. This leads to more technical knowledge and greater credibility.
Also, if you truly love testing, learning of any type is what makes us tick. You will also find, that something you learned on project A, while not a direct fit with project B, can and will apply. This again adds to your credibility as a tester. It truly is a win win situation.
Dear Tester,
It could be.
But take heart, you can still have a great career in testing without becoming a programmer.
One thing though. You will probably need to grow in some technical skills. There is a ton of work for testers that have key technical skills (take API testing as an example). You don’t need to be able to code, but you do need to keep learning. If you are content with doing what you’ve always done I think your job just might be at risk. Pay attention, learn new things, add value and you’ll be just fine 
Sincerely,
Another Tester