Reflection: What I Would Learn If I Started QA Today
A senior tester's honest letter to their younger self about skills, mindset, and what actually matters.
I’ve been in QA for a while now. Long enough to have strong opinions. Long enough to look back at my early years and cringe a little.
Not because I was bad at the job. But because I was learning the wrong things in the wrong order, nobody told me.
So this is the article I wish had existed when I was starting out. Not a tutorial. Not a tool list. Just an honest reflection from someone who’s been in the trenches and wants to save you some time.
The first thing I’d change: stop thinking QA is about finding bugs.
It took me an embarrassingly long time to unlearn this. When I started, I thought my job was to break things. Find the bugs, report them, done. The more bugs I found, the better I was doing.
That’s not wrong, but it’s dangerously incomplete.
The real job is to give your team information they don’t have yet. Information about risk. About what could go wrong and how badly. About what users actually do versus what we assume they do.
A tester who only finds bugs is useful. A tester who shapes how the team thinks about quality? That person is irreplaceable.
I’d also get technical faster. Much faster.
Not “learn to code” in the intimidating sense. But enough to stop being dependent on developers to confirm your suspicions.
Here’s what I mean practically:
Learn how APIs work. Not just how to test them, but how they actually work. HTTP methods, status codes, headers, and authentication. Most bugs today don’t live in the UI. They live in the layer underneath it. If you can’t test that layer, you’re missing half the picture.
Pick up basic SQL. Just enough to query a database yourself. So many bugs hide in data, and if you need to wait for a developer every time you want to check what’s in the database, you’re always two steps behind.
Learn a little scripting. Python or JavaScript. Not to write automation frameworks from scratch, but to write a 20-line script when you need one. Generate test data. Parse a log file. Call an API and check a response. Small scripts change your relationship to the work.
None of this has to happen in month one. But it should happen in year one.
Speaking of automation — I’d approach it completely differently.
When I started, automation felt like the goal. The more tests you had running in CI, the better you were at your job. I chased coverage numbers. I built big Selenium suites. I was proud of them.
Then I watched teams ship confidently broken software because all their automated checks passed.
Here’s what I know now: automated checks verify that known behavior still behaves as expected. Testing discovers what you don’t know yet. Both matter. Neither replaces the other.
If I were starting today, I’d learn Playwright; it’s genuinely good. But I’d learn it after I had a clear answer to the question: “What makes a test worth automating in the first place?” The tool is the easy part. The strategy is what most people skip.
The skill that took me the longest to develop — and that I’d prioritize much earlier — is risk-based thinking.
It sounds fancy. It isn’t.
It’s just asking: if something breaks here, how bad is it? Who gets hurt? What does the user lose? How likely is it to break?
Coverage tells you where you’ve been. Risk thinking tells you where you should go next.
I built this skill mostly by accident, reading user support tickets, sitting with a customer success team, and watching how real people used the software we were testing. The patterns of where things actually break are rarely where we expect them to break.
Please spend time close to users (if you can) early in your career. It will calibrate your instincts in a way that no amount of test theory can.
One thing that’s genuinely new if you’re starting today: AI changes the game in both directions.
On one side, it helps. AI tools can generate test cases, write boilerplate automation, and analyze logs. That’s real and useful, and you should learn to use them well.
On the other side, AI creates entirely new categories of bugs that most existing QA knowledge doesn’t cover. Non-deterministic outputs. Hallucinations in generated content. Prompt injection vulnerabilities. Model behavior that drifts over time.
If you’re working on any product that uses AI, and soon that will be most products, you need a testing vocabulary that barely existed five years ago. Learn what LLM evaluation looks like. Try adversarial prompting. Understand what “correct output” even means when the system is probabilistic.
This is the frontier right now. Getting there early is worth a lot.
Here’s something nobody told me when I started: how you communicate findings matters as much as how you find them.
The best bug report I ever wrote was three sentences and a screen recording. The worst were long, detailed documents that sat unread in a Jira backlog.
A bug report isn’t a legal document. It’s a call to action. What’s broken? Why it matters. How to reproduce it. Everything else is noise.
And beyond reports, learn to have uncomfortable conversations. Sometimes your job is to tell a PM that a feature isn’t ready the day before a release. That conversation never gets easy, but you can get better at it. Doing it with tact and evidence, instead of hesitation or aggression, is a skill worth developing early.
If I had to lay out a rough six-month learning path for someone starting today, it would look something like this:
Months 1–2: Focus on thinking, not tools. Read about testing philosophy. Practice exploratory testing on apps you actually use. Write down what you notice. Study HTTP and how REST APIs work.
Months 3–4: Learn SQL basics. Build your first API test collection in Postman or Bruno. Understand what CI/CD is and why it affects your work. Please shadow a developer for a sprint.
Months 5–6: Pick one automation framework (Playwright) and build something small with it. Contribute to an open-source project’s test suite. Start writing up your test investigations — not just the scripts, but your thinking behind them.
After that, dig into performance testing basics, AI-specific testing, and whatever the product you’re working on actually needs.
I’ll close with the thing that matters most, and that nobody can teach you directly:
The best testers I’ve met are people who can’t help asking “but what happens if…”
In code reviews. In design meetings. In conversations about requirements that sound simple but aren’t.
That instinct — comfortable uncertainty, systematic curiosity is what separates good testers from great ones. The tools are learnable. The mindset takes longer. But if you have the instinct, everything else can be built on top of it.
You’re starting at a good time. The field needs people who think carefully about quality. Go be one of them.