40

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 software industry. Will manual testers loose their value and job in future, if they don't switch to automation soon.

|improve this question
  • 7
    You seem to make this very black-and-white, while the answer is probably a shade of grey. You don't have to become a developer in order to do test automation and when you do test automation it doesn't have to be the only thing that you do. A former colleague of mine was a manual tester with no software background at all (he was a former car mechanic) but he was able to learn a bit of coding so that he could make his life easier. The idea is to automate repetitive tasks so you can focus on finding the important bugs. – Cronax Jun 12 '17 at 12:51
  • My company only employs manual testers currently. While we do use automated testing to varying degrees, our testers aren't involved in this process at the moment, although we're keen for them to be. The skills employed by a manual tester are absolutely essential, even if going down the route of automated testing. Automated testing is not absolutely necessary. – Ian Newson Jun 13 '17 at 10:57
  • "Those who can't do, teach. Those who can't teach, lead." After you have been with a company long enough, study to become a manager. You don't have to know how to do automation, just how to lead those who do know how to do automation. – Keeta Jun 13 '17 at 12:53
  • Being strong on QA methodology is valuable when it comes to doing the work, but does not stand out on a resume. Anytime you are trying to justify your disciplines existence, you have already lost the argument. – David Cain Jun 13 '17 at 17:16
  • I don't think the world is changing at the pace the OP thinks. There will be always be people behind the curve. Having good tests is hard, and people don't like doing difficult things if they can get away with it. I know from 1st hand experience that the software industry is enough of a friendly environment, that companies can get away with a quite large amount of lack of discipline, waste and poor practices before it actually sinks them. ... So cheer up :D – Nathan Cooper Jun 14 '17 at 13:05

12 Answers 12

38

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 see's 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 it's 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 God send. Please keep it up.

|improve this answer
  • 3
    I find your claim that you are a "coder" to be dubious at best. I have never known a dev to like QA... Shenanigans! :) – Taegost Jun 12 '17 at 18:59
  • 1
    @Taegost: It depends. I went from junior developer to team lead to scrum master and once I reached the team lead stage I loved testers. When you are responsible for completing stories/tasks I can sort of see why you'd hate QA because they add work. When you are responsible for live site not going down you'll love QA because you'd rather have them find bugs than users. – slebetman Jun 13 '17 at 5:33
  • @Taegost I think "And I love my manual tester. She see's..." implies that OP hands off their work to another person for testing. – Carrosive Jun 13 '17 at 9:41
  • 1
    It makes me so happy to see people who think that way... I've been doing QA and Release Management for a long time and it's a very rare thing to see devs who don't see QA as more than a roadblock – Taegost Jun 13 '17 at 12:34
  • 2
    @Taegost I see QA as one of many audiences that my code has to satisfy. One skill that QA could work on to help me is to learn just enough coding that I can present an automated script to them, walk them through it, and give them the confidence to sign off that the automated version is equivalent to the manual version. My dream is to free QA from repeating tests so they can focus on creating new ones. – candied_orange Jun 13 '17 at 14:14
14

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 latest coding practices.

|improve this answer
  • 3
    @Davor Yes, if you want to constantly spend more time on automation of very specific, mostly single-use task, instead of doing it manually. Or wanting to invent very, very good general-purpose AI. – user11153 Jun 12 '17 at 12:13
  • 9
    @Davor Everything you can do manually can be scripted, sure, but it needs to be scripted. Let's take a bug you wouldn't anticipate, maybe simple css clipping, sure you could get the rectangles and check for clipping but probability says you do not test every text on your application for it. A manual tester sees it regardless of the test case he's currently working at, a script only checks what we tell it to check. – Daniel Jun 12 '17 at 13:15
  • 5
    @Davor - many things you do manually should not be scripted. You can automate anything. But in a business you must always consider the value versus the cost. – Joe Strazzere Jun 12 '17 at 13:32
  • 5
    @Davor it often takes far more time to script it than to just do it. Automation is a labor savor, not a religon. I automate when a) it's automatable and b) doing it manually is starting to peeve me off. – Harper - Reinstate Monica Jun 12 '17 at 14:34
  • 3
    You can't script checking for bad user experience. – David Cain Jun 13 '17 at 17:19
8

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.

|improve this answer
8

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 which 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.

|improve this answer
3

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.

|improve this answer
2

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?".

Short answer is yes, you could most likely get away with out 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 dont 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.

|improve this answer
1

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.

|improve this answer
1

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 which would a good fit. Scripting languages are DESIGNED for this role, and Python is 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 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.

|improve this answer
0

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 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 of manual testers will gradually decrease. As of now, 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 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 in having one more arrow (automation) in your quiver. :-)

|improve this answer
0

Add value to be valuable.

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

|improve this answer
0

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).

|improve this answer
0

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 the architecture and the emerging edge cases and tend to overlook bugs which are caused by 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 which 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.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.