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
- UI tests (in JS) should be only a very small part of your overall test (about 4%),
- about 16% test should be for the API (written in JS, other scripting language like Python, or possibly even in a core app language), and
- 80% unit tests (written in the web application’s core language, which in most cases is NOT JS).
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:
- new toolchanin (node.js) which is also written in JS. Good example of dogfooding, but it requires the total commitment.
- language itself is changing, abandoning the “awful” parts mentioning above (ECMAScript versions,
"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).
But also some of our 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 better language for file manipulation, text parsing and building command-line tools (DevOps tools), has fewer hidden traps than JS, 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.