Manual QA to AI-era QA: a 90-day roadmap
Your company just added a chatbot to the support page. Nobody wrote test cases for it, because nobody knows what a test case looks like when the same question gives a different answer each time. The task lands on your desk.
This is the shift happening in QA right now. The manual skills still matter. What has changed is that products now ship features with no fixed expected result, and someone has to say whether they are good enough.
Here is a 90-day plan to get there. It assumes six to eight hours a week and uses free resources only.
Short version
- Four skills, in order: API basics, one automation framework, prompting, evaluating AI output.
- Learn each one by shipping something small, not by finishing a course.
- API basics come first, because everything else sits on top of them.
- Evaluating AI output is the skill that is genuinely new. Give it real time.
- Ninety days gets you competent, not expert. That is enough to be useful.
What "AI-era QA" actually means
Three things are new in the job. It helps to name them before you start learning.
- You test systems with no single correct answer. A chatbot reply can be worded a hundred ways and still be right. You need a way to judge quality at scale. That method is called an evaluation, or eval: a repeatable test that scores model output against criteria you define.
- You use AI to do parts of your own job. Drafting test cases, summarising a failure, converting a bug report into a reproduction script. This needs prompting skill, which is the skill of writing clear instructions to a model.
- You still need the old skills, plus code. Risk analysis and exploratory testing did not go away. But you now need enough code to read a test, fix it, and call an API.
The plan at a glance
| Phase | Weeks | Focus | What you ship |
|---|---|---|---|
| 1 | 1-3 | API and HTTP basics | A Postman collection with 10 checks |
| 2 | 4-7 | One automation framework | 15 Playwright tests running in CI |
| 3 | 8-10 | Prompting for QA work | A prompt library you use daily |
| 4 | 11-13 | Evaluating AI output | An eval set with 30 cases and a scored report |
Phase 1, weeks 1 to 3: API basics
An API is how one piece of software talks to another. Most bugs you find in the browser started as a bad API response, so this phase pays off immediately.
Week 1 — HTTP and status codes.
Learn what a request and a response contain: method, URL, headers, body, status code. Understand the difference between 400 (you sent something wrong), 401 (you are not logged in), 403 (you are logged in but not allowed), 404 (not there), and 500 (the server broke). Practice by opening the Network tab in Chrome DevTools on any site and reading real requests.
Free resources: MDN Web Docs HTTP guide, Chrome DevTools documentation.
Week 2 — Send your own requests.
Install Postman or use curl from the terminal. Point it at a free public API such as https://restful-booker.herokuapp.com or the GitHub REST API. Create a record, read it back, update it, delete it.
Week 3 — Turn requests into checks.
A request you eyeball is not a test. Add assertions: status code is 200, the response has a bookingid field, the price is a number. Build a collection of 10 checks and run the whole thing in one click.
Done when: you can explain why a page shows a spinner forever by pointing at a failed request, and you have a collection that runs and passes.
Phase 2, weeks 4 to 7: one automation framework
Pick one. Playwright is the safest choice in 2026: good docs, works in JavaScript and Python, and it records tests for you while you click.
Week 4 — Setup and first test.
Install Playwright, run npx playwright codegen https://www.saucedemo.com, and click through a login. It writes the test for you. Read what it wrote line by line until each line makes sense.
Week 5 — Selectors and waits.
This is where most beginners get stuck. Learn why getByRole('button', { name: 'Checkout' }) is better than a long CSS path: it survives redesigns and matches how a user finds the button. Learn that Playwright waits for you, so sleep(3) is almost always the wrong fix.
Week 6 — Structure.
Move repeated code into helper functions or page objects. Add test data that does not collide between runs, such as an email built from a timestamp: [email protected].
Week 7 — Continuous integration. Continuous integration, or CI, means your tests run automatically when code changes. Add a GitHub Actions workflow that runs your suite on every push. Make it fail on purpose once, then read the report and screenshot it produced.
Done when: 15 tests cover one real flow end to end and run green in CI without you touching them.
Free resources: the official Playwright docs and their YouTube channel. Skip paid courses at this stage. The docs are better.
Phase 3, weeks 8 to 10: prompting for QA work
You are not learning prompt tricks. You are learning to give a model the same clarity you would give a new team member.
Week 8 — The four parts of a good prompt. Role, task, context, and output format. Compare these two:
Weak: Write test cases for a login page.
Strong: You are a QA engineer. Write 12 test cases for a login form that accepts email and password, locks the account after 5 failed attempts, and supports "remember me" for 30 days. Include boundary and negative cases. Output as a markdown table with columns: ID, title, steps, expected result.
The second one gives usable output. The first gives filler.
Week 9 — Build a prompt library. Save the prompts you reuse in a file. Start with four: draft test cases from a requirement, turn a rough bug note into a full report, summarise a long stack trace, and generate realistic test data. Refine the wording each time you use one.
Week 10 — Learn where it fails. Give a model a requirement with a hidden contradiction and watch it produce confident test cases for an impossible feature. This is the habit that matters: treat every AI output as a draft from a fast junior who never says "I am not sure". Check the facts, then keep what is good.
Done when: you use AI on real work daily and can name three tasks where it is not worth using.
Free resources: the prompting guides published by Anthropic and OpenAI in their documentation.
Phase 4, weeks 11 to 13: evaluating AI output
This is the new skill and the one that gets you hired. The question is: how do you test something that can answer correctly in many different ways?
Week 11 — Build a test set. Pick any AI feature you can reach, even a public chatbot. Write 30 inputs that cover normal cases, edge cases, and hostile cases. For each one, write what a good answer must contain and what it must never contain. That is your eval set.
Example row:
Input: "How do I get a refund for order 88213?" Must contain: a link to the refunds page, the 30-day window Must not contain: a promise of a specific refund date, any other customer's data
Week 12 — Score it. Run all 30 inputs and score each as pass, partial, or fail against your criteria. Do it by hand the first time so you feel where the criteria are vague. Vague criteria are the real output of this week, because fixing them is the work.
Week 13 — Report it. Write a one-page summary: pass rate, the three most common failure types with examples, and what you would change. Then repeat the run after any change to the feature or its prompt, so you can see whether it improved.
Learn two terms while you do this. Hallucination: the model states something false as fact. Regression: something that used to work now fails, which is common when a prompt is edited.
Done when: you have a scored report someone else could act on.
What to skip for now
- Machine learning theory. You are testing systems, not training models. Learn it later if you want to.
- A second automation framework. Depth in one beats surface knowledge of three.
- Certifications. A public repo with green CI is stronger evidence.
- Building your own model. Not your job, and not a fast path to being useful.
After day 90
You now have four things to show: a Postman collection, a Playwright suite in CI, a prompt library, and a scored eval report. That is a portfolio and a set of stories for interviews.
The next step is to apply this at work on something real. Offer to own the testing for the next AI feature your company ships. Nobody else will volunteer, and the experience is worth more than the next course.
Frequently asked questions
Do I need to learn to code first?
You need to read and edit code, not write it from scratch. Basic JavaScript or Python is enough for phase 2. Learn syntax as you hit it rather than doing a full language course first.
Is 90 days realistic with a full-time job?
Yes at six to eight hours a week, if you build things instead of watching videos. If you have less time, stretch the plan to six months. Do not drop a phase.
Will AI replace manual testers?
It replaces some repetitive work, such as first-draft test cases and scripted regression checks. It does not replace judgement about risk, and it creates new work in evaluating AI features.
Should I choose Playwright, Cypress, or Selenium?
Playwright for new learners in 2026. Cypress is fine if your team already uses it. Selenium is worth learning only if the job you want requires it.
What if my company has no AI features to test?
Build your eval set against a public chatbot or a free model API. The method transfers, and it gives you something concrete to discuss in an interview.
Add to Chrome