To answer your questions:

1: What is the use of for ?

UI of web pages, when the UI is written using JS-based UI front-end frameworks like Angular and friends as is the current standard (there are many: Short and Brutal Lifecycle of JavaScript Frameworks)

2: If JavaScript is used for testing, what kind of things are tested using JavaScript?

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:

TL;DR: JavaScript is ubiquitous (especially for the frond-end), is here to stay for a long time, and good to know if you like it, but is not strictly necessary (beyond learning the trivial basics), because other languages (like Python) are a better fit IMHO (give you a better return on your time invested in mastering them) for most of use cases beyond UI (like API testing, custom DevOps tools etc).

Not all testers are writing tests for a living.

A manual tester has little or no immediate need to 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.

Learning JavaScript is a bigger decision. It would be useful ONLY if the tester works/is interested in testing front-end/UI parts of an application written in some JS framework.

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 language, designed for small code snippets by inexperienced programmers, used way beyond it’s original scope, and full of quirks and traps. Even according to experts who like JS there are problematic features of JavaScript that are not easily avoided – and you “must be aware of these things and be prepared to cope”.
  • new IDE (seems that everyone writes JS tests in Visual Studio Code), where everything is configured by JavaScript literals
  • 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 in other languages.

I think that the strongest argument for learning JavaScript for QA is Appium (for testing apps for iOS and Android, in JS) and how important it is for your career. But for some reason, it was not mentioned in any other answers.

Source link


Please enter your comment!
Please enter your name here