Learn QA · Become a QA engineer
Become a QA Engineer.
You don’t need a computer science degree to do this. I have one, but the people I’m proudest of came from banking, lab science, customer support and classrooms with no degree at all. They took my QA bootcamp, put in the reps, and they’re doing brilliant work in the field today. What it really takes is curiosity, a way of thinking, and a path. Here’s that path. It’s built from the same foundation I teach, and it’s free.
This is part of a 4-part path: Part 1 Become a QA Engineer (you are here),Part 2 Test Design & Strategy,Part 3 How QA Fits Into Any System,Part 4 Test Execution & Defect Management.
Free slide course · taught by me
Software Development & the Role of QA
The foundation every tester needs. It’s an illustrated, bite-sized slide course you can click through at your own pace. Start here, then walk the path below.
The path
From curious to job-ready, in order
Do one module a day or one a week. Just do them in order. Tick each one off as you go, and your progress saves in this browser.
Understand what QA really is
Before any tool, get the mental model: how software gets built, where quality fits, and why a tester is the person who protects the user.
- The SDLC and its models: Waterfall, Iterative, V-model and Agile
- What QA actually does day to day, and how it differs from development
- The seven testing principles and the real cost of a bug
You will understand the job better than some people already doing it.
Learn the language: test types, levels & principles
Functional vs non-functional. Unit, integration, system, acceptance. Verification vs validation. This vocabulary is how QA teams think and talk.
- Test types: functional, non-functional, structural and change-related
- The five CTFL v4.0 test levels and what each one catches
- Verification vs validation, and static vs dynamic testing
Every job description and every standup assumes you know these words.
Design tests that find more with less
You cannot test everything, so you test smart. Test design techniques let a handful of cases cover a huge space of behaviour.
- Equivalence partitioning and boundary value analysis
- Decision tables and state-transition testing
- Exploratory testing: structured curiosity, not random clicking
This is the craft at the heart of testing: a few well-chosen cases that cover a lot of ground.
Find bugs, then report them so they get fixed
A bug nobody can reproduce is a bug nobody fixes. Learn to break software on purpose, then write the report developers thank you for.
- Severity vs priority: impact is not the same as urgency
- Clear repro steps, expected vs actual, and the evidence that matters
- Exploratory charters: how to break an app methodically
Bug reporting is the single most visible thing a tester produces.
Test the layer behind the screen
Most of an app lives behind the UI. Learn HTTP and APIs and you can test where the real logic and the real bugs live.
- HTTP basics: methods, status codes, requests and responses
- Reading and testing JSON, headers and authentication
- Contract, integration and negative API testing
API testing is faster, more stable, and increasingly what teams hire for.
Write your first automated test
Automation begins with locating elements reliably, then driving the browser. Build a real suite from scratch, no prior experience needed.
- Locator strategies and the rules that prevent flaky tests
- Driving the browser with WebdriverIO, Playwright or Cypress
- Assertions, waits, and structuring a maintainable suite
Automation is where QA salaries and the SDET path open up.
Think bigger than one test
Anyone can write a test. The value is choosing the right ones: what to automate, what to leave manual, and how it all runs in CI.
- The test pyramid and risk-based prioritisation
- Where tests run: CI/CD pipelines and continuous testing
- Building a strategy a whole team will actually maintain
Strategy is what turns a tester into a quality leader.
QA in the AI era, and your career
AI changed the job, it did not remove it. Learn to test AI features and use AI to test, then turn all of this into a role.
- Testing AI & LLM features: non-deterministic output, bias, guardrails
- Using AI assistants to write and review tests (and validating what they produce)
- Certifications, portfolio and the move from QA to SDET
The testers who thrive now pair human judgement with AI leverage.
Practice & play
You don’t learn this by reading alone
Active recall beats re-reading every time. Test yourself, because that’s how the concepts actually stick.
Knowledge check
Score 0 / 71Which of these is NOT one of the seven testing principles?
Automation does not make tests infallible. The real principle is that exhaustive testing is impossible, so we prioritise.
2A tiny typo on your homepage. How would you triage it?
It barely breaks anything (low severity) but it is highly visible, so you want it fixed fast (high priority). Severity ≠ priority.
3Which test level checks that components work together correctly?
Component integration testing targets the seams between components, where a lot of real bugs hide.
4Boundary value analysis focuses your tests on which inputs?
Bugs cluster at the edges: 0, 1, the maximum, one past the maximum. Test the boundaries, not the middle.
5As a bug moves further down the SDLC, the cost of fixing it generally does what?
The exact multiplier depends on the product and team, but the pattern is reliable: earlier defects usually require less rework and less customer recovery.
6What is the safest way to think about automation?
Automation is leverage. It repeats valuable checks quickly, but humans still choose what matters and interpret risk.
7Verification answers which question?
Verification = building it right (meets the spec). Validation = building the right thing (meets the need).
Flashcards (tap to flip)
Known 0 / 14Building quality in across the whole process, not just finding bugs at the end.
Are we building the product right? (Did it meet the spec?)
Are we building the right product? (Does it solve the user’s need?)
A difference between the actual and the expected behaviour of the system.
Re-checking existing features to confirm a change did not break them.
Re-testing a specific fix to confirm the defect is actually gone.
Checking what the system does against its requirements.
Checking how well it performs: speed, security, usability, reliability.
Testing behaviour through inputs and outputs, without seeing the code.
Testing driven by the internal structure and code paths.
Running the same tests repeatedly stops finding new bugs, so vary them.
How badly the bug breaks the product (impact).
How urgently it should be fixed (business order).
Simultaneously learning, designing and running tests: structured curiosity.
Match the term to its meaning
0 / 6 matchedClick a term, then click its meaning. Get all six to clear the round.
Fill in the missing word
Go further
Courses to take next
Start with mine. After that, here’s an honest shortlist of the best of everyone else’s.
From me
Trusted elsewhere
When you’ve got the foundation
Track the whole journey on the QA Career Roadmap
Seven stages with saved progress, from your first manual test to AI-augmented automation and team leadership. This learning path gets you started, and the roadmap helps you keep growing.
Stuck or unsure?
Everyone is at module zero once. Reach out on LinkedIn, or send me a message and tell me where you got stuck.
Field Notes
Build better products
by testing what matters.
Get practical notes on testing, automation, AI, mobile apps, and release decisions. I share the workflows, lessons, tools, and mistakes from real product work so you can ship with more confidence and fewer last-minute surprises.