A tester is more than a “clicker”
The popular picture is that a tester sits in front of a finished app and clicks until something breaks. That is a small part of the job. A tester gives the team information about product quality and risk: what works, what doesn’t and what could hurt users after release.
I have been testing web, mobile and backend applications for more than 7 years, and the most valuable bugs I found rarely came from clicking. They came from questions asked before the code was written.
This guide opens the “Testing from scratch” series. The next parts cover theory, test cases, defect reporting, APIs and first steps in automation.
A tester’s week
In a typical team working in sprints, a tester:
- reads requirements and user stories before implementation and asks about anything unclear;
- plans tests: what to check, with which data, in which browsers or on which devices;
- tests new features once the developer has finished them, both scripted and exploratory;
- reports defects so they can be reproduced without follow-up questions;
- checks fixes and runs regression, making sure a change hasn’t broken something next to it;
- reports on quality before release: what was tested, what is left and what the risk is.
On top of that there are team meetings, reviews and, more and more often, maintaining automated tests.
Manual tester, automation tester, QA engineer
| role | what they do | what they need to know |
|---|---|---|
| manual tester | functional and exploratory testing, defect reporting | test techniques, attention to detail, communication |
| automation tester | writing and maintaining automated tests | one programming language, a tool (e.g. Playwright, Selenium), Git |
| QA engineer | quality of the whole process: strategy, tests, automation, CI | all of the above plus planning and working with the team |
Job titles differ between companies, so read the list of duties, not just the title of the ad. Almost everyone starts with manual testing, and that is a good order: automation only tests what someone thought of first.
Skills to start with
Before you start learning tools, take care of these basics:
- Analytical thinking. You look at a feature and ask: what happens if the field is empty, if you click twice, if you lose the connection halfway through a payment.
- Writing. A defect report is read by someone who didn’t see the bug. Clear, short sentences are half of a tester’s value.
- Technical basics. Browser developer tools (DevTools), how HTTP works, basic SQL, what an API is.
- English. Documentation, tools and often the team work in English. A level that lets you read documentation and write a bug report is enough to start.
A step-by-step learning plan
- Testing theory. Learn the basic concepts: test levels and types, test design techniques, the defect lifecycle. The ISTQB Foundation Level syllabus makes a good backbone, and I cover it in the next part of the series.
- Test cases. Learn to write test cases with preconditions, steps and expected results, and to use equivalence partitioning and boundary value analysis.
- Defect reporting. Test real applications and practise describing bugs. This is what shows fastest in an interview.
- DevTools and APIs. The Network tab in the browser and Postman show you what the app sends to the server and what it gets back.
- Basic SQL. A SELECT with conditions and joins is enough to check whether data was really saved in the database.
- Automation. Only now. One language and one tool, e.g. TypeScript and Playwright.
You don’t need to complete every step before looking for your first job. Steps 1-3 and some of step 4 are a sensible minimum.
A portfolio without experience
The most common problem for beginners: there is nothing to show in an interview. You can solve this in a few weeks:
- pick an app you use, or a website built for practising testing;
- write a short test plan and 15-20 test cases for it;
- report a few defects you found, in the format used at work;
- build a Postman collection for a public API;
- put it all on GitHub with a short description.
A recruiter who sees a well-written bug report learns more about you than from a list of courses on your CV.
Do you need an ISTQB certificate
It isn’t a requirement, but it helps, especially at the start. It gives you the vocabulary teams use and shows that you have put time into learning. I hold the ISTQB Foundation Level certificate myself. The syllabus is free, so you can learn from it even if you never sit the exam.
Before the interview
Once you have the basics, test yourself on 50 QA tester interview questions. Prepare an example from your own portfolio for each question, because examples are how a recruiter sees whether you understand what you are talking about.
The “Testing from scratch” series
- What does a software tester do, and how to get started (this guide)
- Testing theory in a nutshell
- How to write a test case
- How to report defects
- API testing basics
- First steps in test automation