To answer your questions:
The front-end of a web-based app. And even for web-based apps, whose UI is written using one of the JS frameworks, JS in not the only (and often not the best) language to write tests. And the app backend is most likely written in a different language, not JS.
More detailed answer, to things you haven't asked, but should:
Not all testers are writing automated tests for a living.
A manual tester has little or no immediate need to learn any programming language. Programming induces specific thinking to a person, so it is beneficial if some manual testers do not think as a programmer would, so they can find bugs which programming-thinking person will miss.
But many learn "some" programming anyway, mhd's answer explains why (even if I disagree that every manual tester needs to learn basic programming).
Learning SQL helps with investigating data in database-related issues. No need to be an expert, being able to grok and tweak SQL queries provided by expert developers is enough.
Learning a simple language like Python allows a tester to write simple tools manipulating data, searching for patterns etc.
Recently we had several questions related to the test pyramid:
Consensus is that
We (in our company) have many UI tests in Python/webdriver, are currently considering transition to JS/protractor, and it is a steep and long learning curve. Because you need to learn:
"use strict;", TypeScript).
Many of these complications (and strategies to handle them) are important for front-end developers (because they do not have control which variety of JS is installed on users device - and not even which browser version from which vendor, each with own bugs in JS implementation), but they are unnecessary baggage for a QA tester with substantially better control of the environment.
I am not sure if switching to writing UI and API tests in JS is worth the effort. From a test developer's POV, dealing with expected conditions (synchronous) is much easier than asynchronous promises in JS.
So, in my opinion, learning JS might be a valuable addition to an automated tester's skillset (for reasons listed in answer by Alexey R., but also might not be necessary if the automated tester is expert in another language like Python, and furthermore tests for the middle level of the test pyramid (API/services level) can be more productively written and maintained in Python than in JS. For UI tests, JS is almost required, for the API/services layer, not so much.
We are currently considering writing some basic UI tests in JS, but maintaining another set of UI tests in Python, which we plan to use also for API/services tests and which are in our core app language (Python, as are most of the tools for DevOps). The reason is productivity: our devs are more productive in Python than JS (write more reliable and maintainable code). We have few JS experts but for most other devs, to attain their current Python level competency in JS will take a year or two (or more, as our main app and DevOps language remains Python). This might change as we gain more experience in JS for production-level deployment, and JS is becoming more strict and reliable ("use strict;" TypeScript etc).
Edit, Dec 2018:
(1) As API testing is becoming more important (for good reasons), another layer of the problem area is solidifying: JS is great for GUI tools for manual API testing like Postman and Insomnia (which uses JS literals), but those GUI tools suck as runners of regression test batches. Such regression are much better handled by unit test runners.
(2) If a GUI tool promotes "variables and templates" as cool features, you know they want to have REAL programming language (Greenspun's tenth rule: Any sufficiently complicated program contains a bug-ridden, slow implementation of half of Common Lisp)
(3) JS literals are almost identical to Python literals. Requests is amazing Python library for API testing, and Insomnia generates Python code snippets to be used with requests library, ready for unit tests. So you have flexibility of manual API testing, and flexible language (Python, with REAL variables, templates, files, parsing and everything) for unit tests. And using requests from python interpreter is almost like Insomnia.
(4) API testing allows tester to test less in JS (less GUI-level testing), and more in the backend language. Using Pareto 80/20 rule, instead of 80% unit tests and 20% GUI tests (in JS), we have 80% unit, 16% API (80% remaining 20%), and just 4% in GUI.
But also some of our (backend) Python dev experts are not eager to invest many years of life mastering JS, and might switch jobs to keep improving Python skills instead of being forced too deep into JS.
In my experience, while JS might be an important language for a UI automation tester, Python is a far better language for file manipulation, text parsing and building command-line tools (DevOps tools), has fewer hidden traps than JS, better libraries (with little gems like argparse ) and also is easier to learn as a first language.
So while learning basics of JS is easy and fun, (if you have experts handing the complexities), and you should do it, including learning about the quirks and traps, but mastering JS with all its complexities might not be needed if you are competent QA engineer in other languages.
Knowing basics of JS will let you:
Additionally, knowledge of a programming language used in a project may be helpful even for a QA engineer that tests manually.
I think the basic question should be "Why a software QA engineer should learn programming".
Which programming language to learn is not important, it can always change. As a QA Engineer, you can work on projects from several platforms (web frontend, web backend, mobile, desktop, IoT devices etc).
A QA Engineer could be required to:
Why would programming help a manual QA Engineer:
Programming is just a part of the QA Engineer role, but in my opinion, an important one. It's also not as complex as a developer's work, so I think that every QA can learn how to program at a basic level and bring more value to the project.
With the popularity of JS Frameworks like
Nodejs, there has been a surge in the testing frameworks using JS- be it an E2E framework like
Cypress or API testing frameworks like
I agree with Peter's answer and I think it puts a lot of valid points.
A frequent argument for the surge of these JS frameworks and need to learn JS is that there are a lot of advantages if your automation framework is developed using the same tech stack that your UI/API uses. There is a good amount of valid points and arguments given in this excellent post.
If you hold a cat by the tail, you learn things that cannot be learned in any other way.
It is always advantageous to think in terms of how learning a skill would be a unique value-add to one's existing skill set and the current and future projects.
// The Why
// Front End
// Back End
// The Value
P.S. You can find a neat list with JS automation frameworks & tools here.
Next to that the Node.JS runtime environment is the fastests growing and largest package registry in the world, with which you can quickly build handy command-line tools, possibly to automate your testing efforts (e.g. data generation or chain stuff).