What a tester actually does all day

An ordinary day

A morning check-in, fifteen minutes. What was tested, what was found, what's blocking.

Reading new tickets. You read what the developers built and decide how to check it. Problems often surface at this stage — in the description itself: requirements contradict each other or don't cover an obvious case.

Testing. The actual work: walking scenarios, trying edge cases, watching behaviour with bad data.

Writing up what you found. Every problem described so a developer can reproduce it without your help.

Retesting fixes. What was repaired yesterday must be checked today.

Discussions. With developers about whether it's a defect. With the manager about what to fix first. With the designer about whether it was intended.

How the time divides

Actual testing takes less than half the day. The rest is reading requirements, writing things up, retesting, discussing, and waiting for fixes.

That surprises beginners as much as developers are surprised to learn they write code a quarter of the time.

What's unexpected

A lot of talking. A tester is the link between the people who designed it, the people who built it, and the people who'll use it. Silent work isn't on offer.

You have to argue. The developer says "that's not a bug, it's intended". The manager says "that's minor, the release matters more". Your job is to convey the risk, not to win the argument.

Responsibility without authority. You don't decide whether to release. Your job is to give an honest picture: what works, what doesn't, what we're risking.

Repetition. Retesting the same things is a normal part of the job. Hence the pull towards automation.

The key skill

Not attentiveness, though that's needed. The ability to explain why it matters.

Finding a bug is half the job. The other half is describing it so people want to fix it: what's broken, who it affects, what it threatens. "The button doesn't work" and "the user can't pay, money is taken and no confirmation arrives" describe the same thing, and the reaction differs entirely.

Who it suits

People who notice inconsistencies and find that engaging rather than irritating. People who can methodically check thirty variants without losing attention by the thirtieth.

It suits poorly those who dislike arguing and explaining: a substantial part of the job consists of exactly that.

Finding out whether it's for you

Take any service and try to find ten problems in it — not only outright bugs but inconveniences. Write each up properly.

If the process felt interesting rather than tedious, that's a good sign. And you now have your first piece of portfolio work.