← back to the section

Everyone starting out has the same doubts: "what if I get nowhere without programming," "what if it's boring routine work," "what if AI does the whole job in a couple of years." Taking a denial on trust is useless, so every myth below is taken apart on one tiny example — a sign-up form with three fields: email, password, promo code. Start with the fact three of those myths grow out of: you cannot check everything.

three fields, ten sensible values in each email password promo code ≈ a thousand combinations — over two working days for one form emptyspace onlylength edgeduplicate emaildifferent casedouble click same bugssix checks choosing, not enumerating — that is the job

You cannot run every combination. A tester's value lies in which six they choose.

You can't check everything — and that's not an excuse

Three fields, about ten sensible values each: empty, a space, short, long, non-Latin characters, special characters. That is 10 × 10 × 10 — a thousand combinations, over two working days for one form at a minute per run. A product has a hundred forms, so exhaustive coverage would take years, before browsers, phones and slow connections come into it. Hence the conclusion the next three myths rest on: a tester's job is selection, not enumeration.

Myth: a tester must know how to code

This doubt is the most expensive one: it makes people postpone starting for a year — "first I'll learn Python." Yet bugs are found with a scenario: a "100% off your first order" promo code plus a refund of one item out of two — the discount came off the whole order, the refund was subtracted on top, and the shop sent money to a customer who had never paid. The whole tool was a guess that discount and refund are calculated separately, plus walking the scenario to the end instead of stopping at the word "paid."

The honest half of the myth: with the browser's developer panel open (F12, DevTools) you see the page sending amount: -450 and the server happily accepting it — the amount check is missing on both sides, and that goes into the bug. Technology doesn't find bugs for you, it shortens the path from "something is wrong" to "here is where it's wrong". That's why the program includes web basics, client-server and HTTP and SQL — reading and understanding, not writing code, which a year or two in becomes your main accelerator, automation included.

Myth: testing is easy

From the outside it's "click around and see what breaks" — right up to the first form you have to check in an hour. You can run a hundred combinations of normal data and find nothing, or you can run six checks:

  • leave a field empty — the most commonly missed case there is;
  • a space instead of a value: empty to a human, a non-empty string to the program, so the "field is filled in" check passes;
  • the password on the length boundary: exactly the minimum and one character below — the mistake sits at the edge, not in the middle;
  • an email that already exists in the system;
  • the same email in a different case: Ivan@mail.com after ivan@mail.com — one address to a human, two to the database;
  • click "Sign up" twice while the page is still thinking.

The other 994 add nothing: the program treats anna@mail.com and boris@mail.com identically. Values inside a group behave the same way and things break at the edges of groups — seeing those groups and edges is the craft: equivalence classes and boundary values, the test design techniques.

Myth: the tester is responsible for every defect in the product

Quality belongs to the whole team: the analyst writes the requirements, the developer the code, the manager moves the deadlines. The tester's part is that the team knows the state of the product and the problems found before the release. And since you can't check everything, a missed bug is not negligence but a consequence of choice: that check wasn't run because others were.

Accountability is still healthy — a bug that shipped to production (the live version real people use) will have the team asking "how did that happen?". A proper review is not a hunt for the guilty: it asks whether the check was on the list, whether the requirements said anything about this case, and whether there was time for regression. All three are about the process, and each answer has a fix: add the check to a checklist, ask the analyst sooner, ask for one more day of re-checking. If the team looks for someone to punish instead, the problem is the team (QA in Agile and Scrum).

Myth: AI and automation will soon replace testers

There is a grain of truth in it: AI drafts test cases (checks written down step by step) from a task description, helps phrase a bug, and repetitive regression has in many teams been taken over by automated tests.

The boundary shows on the same form. Ask a model for sign-up checks and it produces a valid address, an invalid one, a short password, empty fields — exactly what the task description says. What won't be on the list:

  • the same email in a different case — the model doesn't know that in your product the address is stored as typed, so Ivan@ creates a second account alongside ivan@;
  • the double click on the button — it wasn't on the team a month ago, when that duplicated orders;
  • the confirmation email after changing the address in the profile — it goes to the old address, because the mailer reads from a different table.

The model has no context: how your product is built and what has already broken in it lives in the team's heads and in the bug history. The profession doesn't disappear, but demand shifts towards people who think in checks and use AI as a tool.

An exercise with a ready yardstick: ask AI for checks on a sign-up form and compare its list with the six above. It usually names two or three, and almost never the duplicate in a different case or the double click.

Four more myths, answered shorter

  • "It's nothing but routine." What repeats — regression — is the first thing handed to automation; exploratory testing is out of a machine's reach, because a machine only checks what was written down in advance.
  • "Nobody hires you without experience or a degree." A degree isn't asked for on your first job — what matters is whether you can reproduce someone else's bug from a vague description. Experience is earned the same way: five real bug reports on any public product.
  • "Attention to detail is what matters most." By the fifth run through a screen your eye stops noticing the obvious: the brain substitutes a picture from memory. So attention is propped up with structure — a checklist instead of memory, written-down steps, a fresh person on the critical scenario.
  • "Three months of a course and I'm a tester." A program gives you the ability to design checks and describe bugs; knowledge of a specific product, its processes and its tools is only picked up on site.

What you actually need before starting

A beginner's first task sounds mundane: "check that the fix in the cart didn't break anything." You read it (part of the text will be in English), reproduce the fixed behaviour, write down your steps and tell "it doesn't work" apart from "it works differently than I expected." Hence four requirements.

  • English at "reading with a dictionary" level. Documentation, tool interfaces and half the bug trackers are in English; enough is searching for the text of an error message and reading the first answer.
  • Confident computer skills. Take a screenshot with the button highlighted, open the product in an incognito window — otherwise your "bug" turns out to be your own stale cache.
  • Basic logic. "The field is required, so it can't be left empty; let's check what happens if we leave it empty anyway."
  • Persistence. Reproducing a problem that appears every other time means a dozen attempts and a record of how they differed.

HTTP, DevTools, SQL, Postman and Linux are not needed before you start — that's the "Tools and practice" phase (client-server and HTTP, API testing, the Linux terminal). Learning them first is the most popular way of never starting at all.

What the first month looks like

Less is asked of you than you fear: run a ready list of checks and write down everything that differs from the expected result; turn a customer's "payment doesn't work" into exact steps; check a small fix and whatever sits next to it. And you will certainly be asked what you didn't understand in the task — half the problems are found there, before any code. Designing checks from scratch on an unfamiliar product comes a month or two later.

In short

  • A thousand combinations on a single form is over two working days: the job is choosing checks, not enumerating them.
  • Things break at the edges: empty, a space instead of a value, the length boundary, a duplicate, a different case, a double click.
  • You don't need code to start; technology is an accelerator from "something is wrong" to "here is where it's wrong", not an entry ticket.
  • A missed bug is reviewed as a process: was the check on the list, was it in the requirements, was there time for regression.
  • AI takes over the mechanics and not the context: it doesn't know what has already broken in your product.
  • Before starting you need English with a dictionary, confident computer skills, basic logic and persistence.