What a Software Tester (QA) needs to know [closed]

Actually, QA and testers are slightly different specialties. Some people see a very fundamental difference in this and are very offended if they are called incorrectly. (QA says they don't test, they check the quality. But I don't know how it differs.)

At first glance

Usually the work of the tester is quite simple - the programmers wrote "added a mega feature", so you need to check exactly how it works, and not whether the old features were broken and rolled back old bugs (regression analysis).

But this is at first glance. In fact, sometimes the work of a quality tester can be more difficult than that of a programmer. Some testers write automated tests to test the program (not to be confused with unit testing). Make detailed inspection plans.

All kinds of testers are needed, all kinds of testers are important

The next step is to find out that testers are different. There are interface testers. They can set a non-standard one a theme for people with low vision and see if all the buttons are visible. And whether everything can be pressed if you use only one mouse or keyboard. And if you switch the interface to Chinese or Hebrew, everything is displayed normally?

Where do they teach testers?

I believe that it is impossible to learn from a normal tester, as well as from a normal programmer. You can learn many techniques, know all the testing techniques, but still not notice serious bugs and miscalculations.

I personally know two testers who definitely did not study for this (one of them does not even have a full higher education). But this does not prevent you from finding bugs that you would not have thought of.

I would add more to the answer @KoVadim.

1) Literacy, clarity of thought, the ability to identify the problem and convey it to the developer. "You don't have a damn thing working here" - this is not a tester! Identify the conditions for its manifestation, write down everything according to the points, so that the developer does not run to you later with questions like " show me how you dropped it?". To do this, you need to have a good technical erudition at least.

2) Working with technical documentation, bug tracker, request tracker, etc. See point 1: documenting the problem should be as detailed as possible, but without any frills. Good knowledge of the product under test to understand: what problems to include (there are many developers, everyone is responsible for their own, the project is usually divided into subtasks), which tasks to combine, which, on the contrary, to break into smaller ones. The ideal case is when developers and testers do not intersect personally at all, all work goes only through tickets, and at the same time everything is clear to everyone.

3) Derived from knowledge product: ability to set priorities. So as not to yell at the whole office about minor interface flaws or set high priorities for tasks that no one will solve on the eve of the release. Information noise is only distracting. But to identify a potential problem that can seriously affect something-well done!

Maybe I'll remember something else :)

About writing automated tests. You can, for example, solve the following tasks: deploying distributions/installers on different platforms. systems in different conditions (update prev. versions, installing from scratch, changing the user options in the installer, etc.). The task itself is not a bad one, and requires a careful approach to accounting (automated!) all the little things...