Can a Manual Tester survive in software industry without learning Automation?

Question

I mean to say is that if I dislike coding and don't understand complex code, then will I be able to survive as a QA. Or do I need to learn test automation to grow position and pay in my career, as I see in my current company that manual, blackbox test engineers are given less credit than guys who work on tools like selenium webdriver, uft, etc?

They are sometimes mocked by developers​ who say that they are doing such a simple job of finding defects. They say that automation is mandatory to survive in this time and without knowing any automation tool, programming you can't carry on.

I test a web-based product and am good at exploratory testing, scenario testing, do proper analysis, know database SQL queries and try my best to find critical problems in functionality, but don't use programming or tools. I have contributed my bit in successful releases.

Do I need to become a technical tester to save my job in the software industry? Will manual testers lose their value and job in the future, if they don't switch to automation soon?

Answer 1

There will always be smart technical people who do not like to code. There will always be ways of taking advantage of their talents.

I'm a coder. And I love my manual tester. She sees the world differently than I do and that's exactly what I need. What I hate are manual test scripts that pile up without any automation behind them.

The solution isn't to make sure everyone is a coder. It's to pair manual testing with automation developers.

Testing is a skill. One I value because it lets me go fast yet go safe. The problem is if manual test scripts pile up to where it takes 6 months to release a new version of our product we're all going to be unemployed.

A manual tester should be able to sit down with the product and abuse it the same way the user will. They should have the best tools. They should document how they uncovered any problem the best way they can. They should reproduce the problem for an automation developer who should create an automated version of this test.

That automated test should be fast. It should be run against subsequent releases but it should be removed if the subject of its test is removed.

If all you do as a tester is run through prewritten test scripts you are being abused. If you can sit down in front of new GUI and uncover problems us code monkeys failed to think of then you're a Godsend. Please keep it up.

Answer 2

Test automation can NEVER replace manual testing.

• One classic argument is test automation can never catch random bugs that can be caught via manual exploratory testing.
• I have had two colleagues in the past who did not know any coding skills and hated coding, but they were extremely good manual testers, were able to catch bugs no one else could.

Having said that, test automation is desirable.

• The good news is there has been lots of effort going into making test automation simpler. It is possible to learn and apply record-replay test automation without any coding skills. For example, Selenium IDE, Ranorex and TestCompelte require none coding skills to make test automation.

• When you are comfortable with record-replay test automation suites mentioned above, you can progress onto test suites that are more scripts-orientated. E.g. Apply automation with Selenium WebDriver instead of Selenium IDE.

My personal suggestion is: automation and manual testing are not mortal enemies.

• As you have been an experienced tester and you are working close to developers, there are plenty of opportunities to learn coding. In IT industry, it never hurts to learn coding.

• IT companies offer internal training courses in forms of coding dojo or coding jam, they are good opportunities to tune in with the latest coding practices.

Answer 3

Can a Manual Tester survive in software industry without learning Automation?

Survive - Yes, but be valuable and desirable on a job market in the long run - No.

Let me expand on this thought.

• You can, of course, grow as a professional doing manual testing only exploring new techniques and methodologies, testing different products in various industries and fields. Trying different tools and workflows. This is fine! But, in my opinion, the next step has to be test automation.
• Regressions. If a tester, instead of writing an automated test for a problem, would record the steps to reproduce in a manual test scenario and would then rely on the fact that in the future this particular scenario would be manually-processed for every new release of the product, this process will eventually fail. On the contrary, if a tester would write an automated test for this problem and this test will be executed daily or as a part of a pre-release or post-build process, there is a much higher chance of avoiding regression here.
• Human factor. Oftentimes, especially as a post-release step, there is a need to get a high-level check of the deployed application. Doing this manually would bring the "human factor" on the table. What if you forget to check some part of an application that ended up broken? An automated test has a lower to 0 chance to "forget" and would follow what it was programmed to follow line by line.
• Human bias. Humans tend to have opinions; machines (well, I am not sure about that nowadays) do not - an automated test would strictly follow the instructions, humans may bring their own opinion with them. You may, for example, interpret words in a test scenario differently than the person who wrote it.
• Faster feedback. Automated tests provide a faster feedback playing an important role in the continuous integration and delivery processes.
• Manual testing can be boring. I remember the times when we had manual tests only. And, I also remember having motivation difficulties to follow the test scenarios step by step which eventually led to me skipping or mentally tweaking some steps I had confidence in. I remember being easily distracted from manual testing and not willing to restart from the very beginning, pretending to follow the scenario uninterrupted. Don't tell me you've never done that :)
• Load testing. You cannot generally do load/stress testing manually.
• Validation testing. Let's say you have an input with some custom validation rules. It would be generally easier, more descriptive and faster to check multiple values for this input with an automated test.
• You will be a more confident tester. If you would bring a test automation skill with you, it will boost your confidence in the job and quality you are delivering - you would know that the bugs you've caught will not make it to production because of the automated tests you've written.

And, don't forget that having automation skills would also increase your value on the market.

Answer 4

Short answer: it depends, but in my opinion: YES.

Long answer: it depends... on the company, projects, and business.

As a senior test analyst, you possess all the necessary strengths that make a great tester so valuable. In addition to what you've mentioned:

• domain expertise
• analytical skills (from a testing perspective)
  • for example, you're that guy that finds defects early on (in the requirements and analysis phase) simply because you can estimate the functional impact on the product, and perhaps you're already pointing out some loopholes or missing paths.

Now, if I would run an IT department, I would definitely want some people like that. Career-wise as a manual tester your best option is to advance to a test coordination/coaching role. Even if you don't like to code, understanding the basic concepts is sufficient to manage planning and budget for a test team containing automators. Should you remain a test analyst, your pay should be at least equal to that of a functional analyst with similar experience (again in my opinion).

The issues with automation experts may be the following (although I'm not generalizing or trying to offend anyone ;-).

• They were developers before and still act like them (i.e. don't like to read requirements, just want to type some code).
  • If these guys have to write test scenarios and flesh out functional details, I would be slightly worried and let you write the scenarios and data instead.
• They automate (only/mostly) happy paths and on a screen-by-screen basis.
  • Consequently, their actual testing experience (with the application) is much more shallow than yours. Testing something manually, logging all the defects and trying to break each field: these things really give you thorough and lasting knowledge. Automating a screen just to click Save doesn't.

Also, the IT department's FTE count and the SDLC used are relevant. Say a company only has seven developers and you would be the only tester in an Agile project approach. If the employer expects all testing tasks to be performed by you only, you wouldn't be qualified (because of the automation). However, if they are truly cross-functional you could team up with a developer: you decide the scenarios and he writes the code for them.

Final note

Of course, the relevance of the above is limited by your ambitions and region: do you want to keep working for your current employer? Would you rather work somewhere else (where you'd get more appreciation but have to learn the business from scratch), or even consider consulting or freelancing? Every option offers different opportunities.

Answer 5

You will probably be okay for the next five to ten years, but I think that after that our programming practices might be so refined that you'll struggle to catch bugs that won't be noticed by the product manager, designer, project manager, scrum master, B.A., and the developers themselves . . . not to mention the 'requirebugs' that customers come up with but a QA engineer would never find because, in a typical fast waterfall environment, they have no interaction with the customer.

Companies that sell automated software tools now state that QA engineers should either learn some form of automation or start thinking about switching to another role that appears in agile environments, such as product manager or scrum master.

A product manager gets to hold that 'subject matter expert' position that many QA engineers enjoy, are essentially writing test cases in the form of requirements, AAANNND . . . you still get to test manually, if you like that sort of thing.

Another interesting role, if you have a technical mindset, is cybersecurity. You may already have many of the skills needed to pursue that growing field.

That being said, I would imagine that for the short term, there will be companies that insist on hands-on testing. The problem that I came across in those roles were:

1) my coworkers expected me to be the SME of ALL the products. And there were a lot of products. Eventually, I couldn't keep up.

2) I felt like I wasn't expanding my knowledge base, while co-workers who did automate increased their skillset and got promoted.

3) Developers, and sometimes everyone else, really expected me to QA literally everything. A database developer accused me of slacking off because he forgot to run a script after a deploy for a specific client. A graphic designer asked me to check the spellings of names on a pamphlet. Clients and client managers confused me for some sort of grouchy customer service intern.

4) Unmaintained, unloved, trashy regression tests written like puzzles (and often floating around for years after the feature was deprecated) made a thorough regression take WEEKS.

5) developers could fix bugs faster than I could write them up.

One thing I would note though if you decide to stay in QA: keep your skills as well-rounded as possible. Read design blogs, improve your grammar and writing skills, dip into web design for disability accommodation, bone up on Api's, and take a project management class. The manual engineers of tomorrow are going to have a strong knowledge base in all sorts of different fields that are pertinent to computer science.

Answer 6

From my point of view, intelligent manual testers are way more productive and important than test automation engineers.

Why?

• Test automation is better done by the software developers themselves, in form of ...

  • Unit tests
  • Integration tests
  • UI automation tests

• Tests + Bugs from the point of view of an actual user usually are way more important than any other perspective

• Developers tend to write their tests based on their knowledge of architecture and the emerging edge cases and tend to overlook bugs which are caused by the interaction of subsystems and by implementation details (this is very important and cannot be realistically done by a test engineer)

In summary, a good manual tester focuses on aspects developers will usually not catch easily, because it would require them to shift the point of view from the intimate knowledge of implementation details to the point of view from the end-user.

Test automation engineers instead are potentially replaced by improved automated tests written by developers, since they (should) be better at implementing tests that are based on a repeatable pattern (i.e. which are able to be coded).

Just my 2 cents, as a developer of a SaaS product employing quite a lot of development best practices.

Answer 7

This smacks of a question students ask in grade school and high school. "Do I really need to know this stuff?" and "When will this apply to real life?".

The short answer is yes, you could most likely get away without ever having to do any programming. However, it could be very valuable to know enough about the subject so as to be able to deal with people that do. For example ... even though you don't like coding, understanding how to code would teach you that multiple posts in a thread are created via a for loop which can lead to bugs with the first post or the last post if the programmer fat-fingered a number. You would know that x/0 will break stuff ... or unicode could break stuff. The more you know about how the code works, the more you know about the edge cases and where to look for problems

Your job involves finding new and creative ways of breaking stuff, however, once these ways are created they should be documented and automated so that they can be tested for more efficiently in the next release.

If you are repeating the same tasks over and over again ... you are going to be replaced with an algorithm. If you are using creativity to find new and interesting problems with the thing you are testing ... you will not be replaced until AI is capable of replicating the same type of creativity.

Answer 8

Automation testing is just programming. Programming is not for everyone, but if you can do database SQL queries, then you do have enough appropriate mindset so you can learn programming if you want to.

It might be just a question of selecting a language that would a good fit. Scripting languages are DESIGNED for this role, and Python is the most popular of them. It will allow you to automate many file-shuffling tasks, text parsing tasks, query the database, etc, even if you don't want to dive into the deep end with Selenium WebDriver to automate the browser.

So you CAN stay manual tester, but your career will benefit if you explore areas outside your current comfort zone. Seriously, take a look at Python, you will like it.

Answer 9

Can a Manual Tester survive in software industry without learning Automation?

Probably not.

As the modern software world is going to a continuous deployment model, all testing shall be automated. If you like it or not. As the Agile movement grows and quality becomes a team effort, developers will try to minimize handovers. Any manual testing during development could be execute by developers. If I was a CTO or Development Manager I would want my developers to be great testers as well. You should not postpone testing until the end of the process as it is not optional. This does require teaching developers new skills to critique the product from a user perspective though.

Non-coding quality

If you're a tester and you don't like coding I would have a look at combining a Scrum Master role with software quality management. You could focus on Process, Structural and Functional quality and coach teams in how they can improve their cycle by keeping quality high. This needs a bit of technical background, but not programming persee. I love coaching technical excellence practises, which include automation. Become a software quality expert and do some consulting.

Manual testing

Still for a long time some companies will use traditional testing practises. I know some pension-funds that have a lot of manual testers. They will have them for a lot of years to come. Just as there is still a demand for COBOL-programmers, there will be a need for manual testing experts during your lifetime. You might even get paid more as no new people are being trained. You might need to relocated to such a company though.

Answer 10

First of all, I want to tell you that you are playing a very important role in your team. The skills that you have mentioned (exploratory testing, scenario testing, proper analysis and knowledge of SQL) are actually vital for a successful project. I know certain instances where some scenarios were missed during testing because of a lack of proper analysis.

In your case, I must say that it is just a matter of going for it (automation). You will be successful in that too.

Now coming to the question related to demand of manual vs automation testers. I am of the opinion that the demand for manual testers will gradually decrease. As of now, the industry has already put a lot of emphasis on automating regression testing which was being taken care of by manual testers earlier. And efforts are being made to automation more manual work that the manual testers are doing.

So, yes, smart manual testers will always be there and retain jobs. Because I don't see 100% automated testing as a good idea and even it's not feasible as well.

But, overall automation will increase with an increase in demand for automation testers. And it will adversely impact the demand for manual testers.

For you, I would suggest to start learning automation. Because if you work on SQL and understand the logic, and also you are good at identifying business scenarios, I believe that you will easily pick automation and programming concepts required for it.

After all, there is nothing wrong with having one more arrow (automation) in your quiver. :-)

Answer 11

There will always be value in manual testing, although the level of value will likely vary based on industry. My background is in embedded firmware, which is very tightly coupled with hardware. Most of our QA work is manual, because there are so many things that you just can't reasonably automate (cabling changes, swapping hardware components, etc).

In my experiences, someone who develops useful, high-quality manual tests is much more valuable than an ace coder who can automate anything but misses lots of problems. You can always work with a more programming-oriented colleague to convert your manual tests into automated tests. Some companies even formally split QA into two separate groups: one group performs manual tests and generates test plans, and the other takes those test plans and creates automated test scripts (each group doing what they do best in order to achieve the best outcome).

Answer 12

The way the industry is trending, it is a good idea to learn how to code. With all of the different languages, tools, and free resources available, there is no better time than now. You don't need to become a master coder, you just need to learn how to write automated tests, which should lighten your workload.

The ability to adapt to change is a competitive advantage. I would also posit that learning to code is good for long term mental health. Learning new skills and keeping your mind fresh is much more beneficial than rotting your brain watching television.

Answer 13

'if I dislike coding and don't understand complex code, then will I be able to survive as a QA': Answer: Yes. Areas such as ACCESSIBILITY TESTING do not need automation exposure at all. At the same time, each country has brought accessibility rules and regulations to their Acts hence accessibility engineer is a growing role for manual tester in recent times.

PS: Relying on manual testing skills, it is not possible to switch to any organisation since most of the general QA roles are automation dependent from 2012 onwards.

'Do I need to learn test automation to grow position and pay in my career, as I see in my current company that manual, blackbox test engineers are given less credit than guys who work on tools like selenium webdriver, uft, etc?'

Answer: it is recommended but not 100% compulsory. QTP has been famous during 2006-2011 and selenium is famous from 2012 and the trend goes towards cypressio.But the challenge is on programming languages since we should learn more than one in java, javascript,dotNet,Python etc. Reference: Free Courses on Selenium, Cypressio

'Do I need to become a technical tester to save my job in the software industry?'

Answer: Yes-thats recommended. ISTQB Test Automation Engineer is a best route to target with your experience. (Syllabus Reference)

'Will manual testers lose their value and job in the future, if they don't switch to automation soon?'

Answer: It's 100% myth and not true at all. Refer to one of the 'Best Automated Software Testing Books of All Time' stating in Section 1.1 that there is a great future for manual testing. Read the section 1.1 here: https://books.google.co.uk/books/about/Advanced_Selenium_Web_Accessibility_Test.html?id=pTCPDwAAQBAJ&printsec=frontcover&source=kp_read_button&redir_esc=y#v=onepage&q&f=false

Answer 14

I test a web-based product and am good at exploratory testing, scenario testing, do proper analysis, know database SQL queries and try my best to find critical problems in functionality, but don't use programming or tools.

I wonder how you access a database without tools... I think you already use a lot of tools, bez perhaps you are not aware of that.

Do I need to become a technical tester to save my job in the software industry?

Software industry is almost by definition technical, so having technical skills won't hurt your career.

And so going back to what you said:

... I am good at exploratory testing

You need to take into account that exploring technical side of the products you test is, and perhaps should be, a part of a more complete exploration. If you consider yourself an Exploratory Tester, but at the same time shy away from technical testing, then it doesn't exactly sound like a good strategy to me. It even sounds like a contradiction.

---

What you need to get straight is:

1. test automation
2. tool supported testing

Number 1) is what you talk about. All those Test Automation Specialists who write test code in Selenium and what not. Personally I don't think having these skills will be necessary in order to survive in the testing industry. However, number 2) is what I believe is necessary to survive in the testing industry. Technology is evolving and you can't be efficient without tools, or you can't even do certain tasks without them.

Let's consider this example: you most likely use some collaboration tool like Jira etc. where you fill in bugs etc. Can you imagine working without it? Perhaps this is not so obvious. Let's iterate on it. Let's say you're testing a web application. Can you imagine testing it without DevTools in the browser? I don't because it'd feel like being blind. Can you imagine testing it without http proxies? How do you then effectively test frontend vs. backend validations on input fields? Another example could be testing how an application handles a lot of data. Do you add in all the data manually entry by entry? I hope not, I hope you're more efficient and write a code snippet that generates and saves the data for you. It's not exactly programming, but you still need to do this to become effective in exploratory testing.

Do you see where I'm going? Testing without tools could be even unrealistic nowadays. So the only way forward is to embrace them, learn some of them, explore others and see what value they can bring to you.

Answer 15

Add value to be valuable.

Whoever finds critical, valuable defects regularly will be valuable to the product, team, company or to the Industry.