Growing as a QA: manual to automation to SDET

You have come a long way: manual testing, web and mobile and API testing, automation across all three layers, CI, and the professional judgement of the last few lessons. This closing lesson of the module steps back to the career — how a QA grows over time, what paths open up, and what makes someone genuinely good at this work. It is the map for what comes after the course, and a reminder of what the whole thing was really teaching.

The arc: manual to automation to SDET

Testing careers commonly grow along a recognisable arc — though it is a spectrum, not fixed rungs, and where you land depends on you and your team:

Manual QA / Tester. Where most people start and where the core skills live: understanding requirements, designing test cases, exploratory testing, writing good bug reports, thinking like a user and an adversary. This is not a "lower" role to escape — it is the foundation everything else rests on, and strong manual testers are valuable at every level. Automation without this thinking just runs bad checks fast.
Automation QA / QA Engineer. You add the ability to automate — Playwright, API tests, Appium, CI — so the repetitive checks run themselves and you spend your judgement where it counts. This is the step this course's second half was preparing you for. You are now writing code, and the software-engineering craft (the practices modules of a language course — naming, structure, DRY) applies to your tests too.
SDET (Software Development Engineer in Test). A role that blends deep testing insight with real engineering: building test frameworks and tooling, tackling hard problems like test infrastructure, performance and reliability at scale, and often contributing to the product code. An SDET is an engineer who specialises in quality — as much developer as tester.

Beyond these lie QA lead / manager (strategy, process, mentoring, owning quality across a team) and specialisms — performance testing, security testing, accessibility, test architecture. The field is wider than "clicks buttons to find bugs", and it rewards people who keep learning.

What actually makes a QA good

Across every level, the same qualities separate the good from the ordinary — and none of them is a tool:

A testing mindset — curiosity, scepticism, thinking about what could go wrong, empathy for the user. This is the irreplaceable core (the qa-mindset lesson); tools change, this does not.
Judgement about risk and priority — knowing what matters most and where to spend limited time (the risk-based lesson). This is what makes testing effective rather than merely busy.
Communication — clear bug reports, honest risk assessments, working with developers not against them (the working-with-developers lesson). Testing that is not communicated well does not improve the product.
Technical depth, growing over time — understanding how the system works (HTTP, the API, the database, the browser, the device) so you can test it deeply and automate it well. You do not need to start deep, but you keep going deeper.
Care about the user — remembering that behind every bug is a real person who would be affected. That is what the whole course has been for.

Notice that most of these are not about a specific tool. Playwright and Appium will change or be replaced; the mindset, the judgement, the communication, the care will still be what makes you good. Learn the tools — they matter — but invest most in the things that last.

Keep learning, deliberately

The field moves, and staying good means staying curious:

Deepen the fundamentals — HTTP, how browsers and devices work, how the systems you test are built. Depth compounds; it makes every kind of testing better.
Learn to code well, not just to automate — the engineering practices from a language course (readable code, good naming, structure, the design sense) apply directly to test code, and are what take you from automation QA toward SDET. Your tests are software; write them as well as you would write the product.
Practise on real systems — the AgentPay reference app, open-source projects, your own side projects. Testing is a craft; you get better by doing it, breaking things, and reading what happened.
Read, and join the community — the testing world (Ministry of Testing, blogs, conferences) is generous with knowledge; the people who grow fastest keep learning from it.

What the course was really teaching

Underneath the techniques and tools, this course had one message, and it is the thing to carry into the work: testing exists to protect the people who use the software. Every skill served that — designing test cases so nothing important is missed, testing the money flow because real money is at stake, waiting for conditions so the suite stays trustworthy, reporting risk honestly so the team decides well. A QA is the person on the team who holds the user's interest steadily in mind and does the careful, sceptical, unglamorous work of making sure the software actually works before it reaches them. Do that well — with the mindset, the judgement, the tools and the care this course has tried to build — and you will be the kind of QA any team is lucky to have, and the kind RizTech Academy set out to train.

Check your work

The arc (a spectrum, not rungs): Manual QA (the foundation — requirements, test design, exploratory, bug reports, the mindset; not a role to escape), Automation QA (add Playwright/API/Appium/CI; now writing code, so engineering craft applies), SDET (test frameworks, infra, scale — an engineer specialising in quality). Beyond: QA lead/manager, and specialisms (performance, security, accessibility, architecture).

What makes a QA good (mostly not tools): testing mindset (curiosity, scepticism, user empathy — the irreplaceable core), risk/priority judgement, communication (reports, honest risk, collaboration), growing technical depth, and care about the user. Tools change; these last — invest most in them.

Keep learning: deepen fundamentals (HTTP, browsers, devices, the systems), learn to code well (test code is software — the path toward SDET), practise on real systems (AgentPay, open source), read and join the community.

The real message: testing exists to protect the people who use the software — every skill served that. Be the person who holds the user's interest in mind and does the careful, sceptical work of making sure the software works before it reaches them.

Practice

Map the manual → automation → SDET arc and say where the skills from this course fit on it.
List the qualities that make a QA good and mark which depend on a specific tool (most do not).
Explain why strong manual testing remains valuable even after you can automate.
Explain how the engineering-practices skills (naming, structure, DRY) apply to your test code.
Write a personal learning plan: three fundamentals to deepen and how you will practise them.
In your own words, state what this course says testing is for, and how one skill you learned serves it.

Official documentation

Ministry of Testing — Career paths in testing — Roles, growth and community for testers.
Google — How Google Tests Software (overview) — The SDET role and engineering-led testing.
Martin Fowler — Testing guide — Deepening the fundamentals of testing and test code.

Next: the capstone — QA the AgentPay app, end to end.