A tester is the person responsible for making sure a working product — and not a bag of surprises — reaches the user. They usually don't write the product's code and don't decide what to build — but they're the only one whose whole job is the question "does this actually work the way it should".

The role is often called QA engineer, or just QA. Below we'll cover what such a person is busy with during the day, how they fit into the team, and which words around this profession are worth knowing from the very start.

What a tester does every day

The work isn't just "click some buttons". A typical set of tasks:

  • Understands the task. Reads the description of a new feature, the mockup, the requirements. Asks questions if something is unclear or contradictory — often it's at this stage that the first problems surface, before any code.
  • Designs checks. Thinks through how the feature will be used correctly and incorrectly, and writes test cases or checklists.
  • Checks. Walks through the scenarios, compares the actual result with the expected.
  • Files bugs. Clearly describes the problems found in a bug report, so the developer can reproduce and fix them.
  • Re-checks. When a bug is fixed — confirms it's gone and that nothing nearby broke (regression).
  • Communicates. With developers, analysts, the manager. A significant part of the work is agreeing on what counts as a bug and what's more important to fix first.

Why the team needs a separate person for this

A logical question arises: why doesn't the developer just check their own code? They do — but that's not enough, for two reasons.

A blinkered eye. The author of the code subconsciously checks it the way they intended. They know "where to click" and skip the problem spots without noticing. A fresh person behaves differently and finds what the author won't see.

A different mindset. The developer thinks "how to make it work". The tester thinks "under what conditions will this break". These are opposite attitudes, and holding both in one head at once is hard.

So a tester isn't an "under-developer" but a separate role with its own view. A good QA saves the team far more than they cost: one bug caught in time in payments pays for months of work.

QA, QC, and testing — the difference

Three words a beginner constantly confuses.

  • Testing — the checking process itself: walked through scenarios, found bugs. It's a concrete activity.
  • QC (Quality Control) — checking an already-finished result: does the product meet the requirements. Testing is part of QC.
  • QA (Quality Assurance) — broader: not only "check the finished thing" but building the process so there are fewer bugs. For example, spotting a contradiction in the requirements in time is already QA, even though there's nothing to test yet.

In practice almost everyone is called "QA" regardless of the nuances, and that's fine. What matters is understanding the idea: the earlier and more systematically quality control kicks in, the fewer problems reach the user.

Junior, middle, senior — where to grow

Testers, like developers, are split by level:

  • Junior — the beginner: walks through ready-made test cases, files bugs, learns to ask the right questions.
  • Middle — independent: designs checks for a new feature themselves, masters test design techniques, can work with APIs and the database.
  • Senior — takes on the testing strategy, helps the juniors, influences processes and quality overall.

Manual testing is the entry into the profession for most people. It's where you start, and then you choose where to develop: into automation, analysis, performance, security, or management.

Where this applies

Understanding your role isn't an abstraction — it determines how you work. A tester who thinks of themselves as a "button-clicker" waits for ready-made cases and stays silent when they see something odd in the requirements. A tester who understands the role gets involved early, asks questions, and thinks about the risk to the user.

Where beginners stumble:

  • They wait until everything's ready, instead of getting involved at the requirements stage, where bugs are cheapest.
  • They're afraid to ask questions ("what if I look dumb"). But it's exactly the tester's questions that often expose holes in the task.
  • They treat bugs as conflict with the developer. It's not "you did it badly" but "let's ship something good together".

What to learn next. See how manual testing differs from automated and how the software lifecycle works — to understand at what moment, and exactly how, you plug into the team's work.