Quick Answer: what test automation is and what ten days of it buys you
Ten working days, about an hour a day, ending in one automated test that runs in your team's pipeline. Test automation means writing a program that drives your application the way a person would, clicking buttons and filling fields, then checking that what appeared on screen is what should have appeared. The skill is not the tool: it is turning a test case you already run by hand into code that runs without you, in the repository your developers commit to, on every change. Playwright is the default choice here because setup takes minutes and its debugging tools tell you why a test failed, not just that it did.
One number from our own database, queried on 2026-09-28. Learners here have built 1,587 learning paths. Searching those topics loosely for "test" or "QA" returns exactly 6, and only one of the 6 is about software quality assurance: four are penetration testing or AI security, which is a different job, and one is an aptitude test. Across 5,743 video slots in all 1,587 paths, 92 have "test" in the video title, and 44 of those 92 are penetration-testing videos. Zero of the 5,743 slots name Playwright, Selenium or Cypress. That is an observation about our own learners, not a claim about the world. It does say something about how this skill arrives: nobody schedules it.
So this is not a channel list. It is ten days with one job each, built from free videos, aimed at one deliverable: a test in your team's repository that runs on every push and that the developer reviewing your pull request can read without asking you what it does.
The decision that shapes the fortnight: an existing regression pass, or coverage from nothing
Answer one question before Day 1. Are you automating a regression pass that already exists on paper, or has someone asked you to invent coverage for an application with no written test cases? The first is a two-week job. The second is not, and pretending otherwise is how these projects die in month two.
If the cases exist, you already own the hard part. Somebody wrote down the steps, the data and the expected result for the flows that matter. Automation is a translation job: take the case that would embarrass everybody if it broke, and turn it into code. Two weeks is enough to translate one case well and to learn how to translate the next twenty.
If they do not exist, you have two projects. Deciding what to cover is test design, and it needs conversations about risk with people who are not you. Automating is engineering. Doing both at once produces a suite that runs beautifully and checks the wrong things. Say that plainly to whoever asked, ask for one written case, then automate that one.
The other thing that may already be decided is the tool. If your team runs Cypress, Selenium, or something built in-house three years ago, follow it. A mediocre test inside the suite your team actually runs beats a better test in a repository nobody opens. For Cypress, start at the official lesson below and read the rest of this plan with Cypress vocabulary substituted, because Days 1, 2, 5, 6, 7, 9 and 10 are about concepts rather than commands.
Best for: Cypress.io (~17K subscribers). The official project channel, and only relevant if your team already runs Cypress. Start with: Cypress.io, "Testing your first application - Lesson 02 - Installing Cypress and writing your first test", https://www.youtube.com/watch?v=x0QuiEJUf6s
Done looks like: one sentence written down. Either "I am automating case X from our regression sheet" or "I need a written case first, and I have asked for one."
Days 1 and 2: your test cases become code, plus just enough TypeScript
Two short days of groundwork. Day 1 is what actually changes when a test becomes code, and the honest news is that your manual test cases are the asset here, not the thing being replaced. Day 2 is one sitting of TypeScript, the language Playwright tests are usually written in, and it is a few hours of specific syntax rather than a language course.
Start Day 1 with the framing, because this is the part people get wrong. An automated test cannot explore. It checks exactly what you told it to check and notices nothing else. That is the trade: you give up judgement and you get repetition. So the cases worth automating are the boring ones you run every release and would rather never run again, not the exploratory sessions where you find the interesting bugs. Those stay yours.
Your written cases already contain what the code needs: preconditions, steps, data, expected result. Where they usually fall short is precision. "Check the order confirms" has to become "the page shows the text Order confirmed and the order number is not empty," because code cannot squint.
Best for: Automation Step by Step (~590K subscribers). Raghav answers this exact career question from manual testers constantly, and practically rather than motivationally. Start with: Automation Step by Step, "#AskRaghav | How to switch from Manual to Automation Testing", https://www.youtube.com/watch?v=KfuRtfj4c9A , then "Playwright Beginner Tutorial 1 | What is Playwright", https://www.youtube.com/watch?v=4_m3HsaNwOE
Best for: The Testing Academy (~210K subscribers). Shows what finished automation work looks like as artifacts, which helps before you install anything. Start with: The Testing Academy, "Want a QA Job? Build These 5 Playwright Projects First", https://www.youtube.com/watch?v=fXEXMnRkNjs
Day 2 is the day people either skip or overdo. You need five things: variables, functions, objects and arrays, async and await, and the nerve to read a stack trace without closing the laptop. Async matters more than the rest combined, because nearly every line of a Playwright test waits for a browser and a forgotten await is the most common beginner bug in the field. You do not need generics or the type system's clever corners.
Take the first hour or so of a full course, then stop on purpose. If TypeScript turns out to be the part you enjoy, our roundup of the best YouTube channels for learning TypeScript is where month two goes, after the test is in the pipeline.
Best for: freeCodeCamp.org (~12 million subscribers). One long, well-sequenced free course, which is what you want when you plan to watch a defined slice and leave. Start with: freeCodeCamp.org, "Learn TypeScript - Full Course for Beginners", https://www.youtube.com/watch?v=SpwzRDUQ1GI
Done looks like: one of your own cases rewritten as numbered steps with exact expected text, and a .ts file on your machine where you wrote a function, called it, and awaited something.
Days 3 and 4: install Playwright, run the examples, then record your first test
By the end of Day 4 there is a test suite in a folder on your machine, it runs, you have read its report, and one test in it describes a flow from your own application because you recorded it and then rewrote it. Install takes minutes. The recording is where the two days get interesting, because what a recorder hands you is a draft.
Day 3 is deliberately mechanical. Run the init command, let it create the example tests, run them, then open the HTML report and read it. Read the config file too, even the lines you do not understand yet: which browsers run, how many retries, where the base URL lives. You will edit that file on Day 10. Run the suite once in headed mode so you can watch a browser do your job faster than you can.
Best for: Playwright (~36K subscribers). The official channel, and the setup videos are the ones that stay current with the tool. Start with: Playwright, "Playwright for Beginners. Install and run tests using the CLI", https://www.youtube.com/watch?v=SLhz2KmBh2Q , then "Get Started with Playwright and VS Code (2025 edition)", https://www.youtube.com/watch?v=WvsLGZnHmzw
Best for: Automation Step by Step (~590K subscribers). Install and running split into two short lessons, if one combined walkthrough moved too fast. Start with: Automation Step by Step, "Playwright Beginner Tutorial 2 | How to install", https://www.youtube.com/watch?v=IB2P1FBXjcQ , then "Playwright Beginner Tutorial 3 | How to run tests", https://www.youtube.com/watch?v=LTwg0kqdK4I
Best for: Software Testing Mentor (~210K subscribers). A first test case walked through in QA language rather than developer language. Start with: Software Testing Mentor, "Playwright Tutorial #5 - Automate First Test Case in Playwright", https://www.youtube.com/watch?v=vH0Lck0wLPs
Day 4 is codegen. You start a recorder, click through your application, and Playwright writes the code for those clicks. It feels like the answer to everything for about ten minutes. Then you read the output: selectors tied to whatever the recorder happened to grab, a step for every stray click, and no real assertions. A recorded test is a first draft written by something that cannot see intent.
So the work of Day 4 is the rewrite. Delete the clicks that were you finding your way. Name the test after the case it checks. Replace the selectors you do not trust, which is what Day 5 is for. Add the assertion the recorder did not know to make. Do that once by hand and codegen becomes a fast way to discover selectors rather than a way to avoid writing code.
Best for: Checkly (~13K subscribers). A short, honest walkthrough of turning browser actions into a test, with the limits stated. Start with: Checkly, "Turn Your Browser Actions into End-to-End Tests with Playwright CodeGen", https://www.youtube.com/watch?v=FdD_z-Bfbh8
Best for: Playwright (~36K subscribers) and Automation Step by Step (~590K subscribers). Generation from inside the editor, or the same thing as a numbered lesson. Start with: Playwright, "Generating Playwright Tests in VS Code", https://www.youtube.com/watch?v=LM4yqrOzmFE , or Automation Step by Step, "Playwright Beginner Tutorial 5 | How To Record Tests", https://www.youtube.com/watch?v=-F0eCZK_vxE
Done looks like: a passing test file named after one of your real cases, shorter than what the recorder produced, with every line something you can explain out loud.
Day 5: locators, the one skill that decides whether your suite survives
A locator is how a test finds an element on the page. This is the single skill that decides whether your suite is still running in six months or has been quietly disabled, because a test that cannot find the button fails in a way that looks exactly like a broken application. Spend the full hour here.
The order of preference is short. Prefer what a user perceives: the accessible role plus the visible name, the label, the placeholder. Prefer a dedicated test attribute if your team adds them, and ask the developers to add them if they do not, because that request is the cheapest win available to you all fortnight. Avoid long CSS chains and avoid XPath that walks the document structure. Both describe where an element sat in today's markup, and markup changes for reasons unrelated to your test.
The tell is readability. A locator built from the role "button" and the name "Place order" says what a human would look for; four nested div classes say what the page looked like the afternoon you wrote it. Only one survives a redesign.
Best for: Automation Step by Step (~590K subscribers). The lesson on finding elements, plus a separate video on building and checking selectors in the browser, which is the practical half. Start with: Automation Step by Step, "Playwright Beginner Tutorial 7 | How To Find Web Objects", https://www.youtube.com/watch?v=wmy1Nu3X8l0 , then "Find Perfect Playwright Locators, XPath & CSS Selectors | SelectorsHub", https://www.youtube.com/watch?v=XA2AEMGdj4Q
Best for: Software Testing Mentor (~210K subscribers). The same ground from a second teacher, which is worth the time on this day and no other. Start with: Software Testing Mentor, "Playwright Tutorial #7 - Locators in Playwright | Playwright Selectors", https://www.youtube.com/watch?v=KsxWkXcRKGI
Done looks like: every locator in yesterday's test replaced with one based on a role, a label or a test attribute, the test still passing, and a short list of elements your developers should add test attributes to.
Day 6: assertions and auto-waiting, and why sleep ruins a suite
Week two starts here, and it is the half where tests become trustworthy rather than merely present. Today covers assertions, the lines that decide pass or fail, and auto-waiting, the reason a good Playwright test does not need you to guess how long a page takes. A test without an assertion is a script that proves nothing.
An assertion states what must be true: the page shows this text, this element is visible, this field holds this value, three rows are listed. Write the assertion your manual case already implies, and write it about what a user would see rather than about internal state you happen to be able to reach.
Auto-waiting is the part that changes your habits. Playwright's assertions retry for a few seconds before failing, and its actions wait for elements to be ready. So the fix for a test that fails intermittently is almost never a fixed pause. Adding sleep or a hard timeout is the habit that ruins suites: it passes today, adds dead seconds to every run forever, and hides the race condition instead of fixing it. When you feel the urge, you are missing an assertion about the state you are really waiting for.
Best for: Automation Step by Step (~590K subscribers). A focused lesson on assertion syntax, which is the page you will look up again in week three. Start with: Automation Step by Step, "Playwright Beginner Tutorial 9 | Assertions", https://www.youtube.com/watch?v=hYNOFle3zic
Best for: Checkly (~13K subscribers). The clearest short explanation of why waiting properly beats waiting longer, aimed at exactly the mistake above. Start with: Checkly, "Your Tests Aren't Flaky Because Playwright Is Too Fast!", https://www.youtube.com/watch?v=P9RcYKKee-A
Done looks like: your test asserting the real expected result from your manual case, at least one assertion about text a user reads, and zero fixed sleeps in the file.
Day 7: the page object model, and when it is overkill
Today is structure. The page object model puts the locators and actions for one screen into one class, so tests read as steps instead of selectors. It is the standard answer to duplication in test suites, and also the thing beginners apply four hours too early and then maintain forever. Learn it today, apply it when it earns its place.
The rule is simple. Write your second and third test first. If you find yourself pasting the same login sequence and the same five locators into each one, extract them. The first extraction is nearly always login, because every test needs it and it changes whenever the auth team touches anything. A class wrapping one button on one screen used by one test is not a page object, it is indirection that makes a short test longer to read.
Playwright has a second mechanism worth meeting today: fixtures, which set up and tear down what a test needs, such as an already logged-in page. Fixtures and page objects solve overlapping problems, and combining them is how mature suites stay short. You will not master that today. You need to know it exists so you stop copying login code.
Best for: LetCode with Koushik (~44K subscribers). Playwright taught as a long numbered series by a working automation engineer, so the lesson sits in real context. Start with: LetCode with Koushik, "Page Object Model | Playwright - Part 16", https://www.youtube.com/watch?v=WSd6-X-n6P8
Best for: Checkly (~13K subscribers) and Playwright (~36K subscribers). The two mechanisms combined, then fixtures on their own from the team that built them. Start with: Checkly, "How to combine POMs (Page Object Models) with Playwright Fixtures for better developer experience", https://www.youtube.com/watch?v=k488kAtT-Pw , or Playwright, "Fun With Fixtures", https://www.youtube.com/watch?v=3i6cJUFO_m4
Done looks like: a second test written, and either one page object extracted because you saw real duplication, or a written note saying why you decided not to yet.
Days 8 and 9: making a failure legible, then facing flakiness
Two days on the difference between a suite people trust and a suite people mute. Day 8 is the two tools that make a failure legible: the trace viewer, which records everything a failed run did, and UI mode, which lets you watch and step through tests as you write them. Day 9 is flaky tests, which is a judgement problem more than a technical one.
The trace viewer is the reason to pick this tool. When a test fails, a trace gives you a timeline of every action, the page at each step, network requests, console output, and screenshots either side. You stop guessing. Turn traces on for retries today, because a trace from the build server beats any amount of local reproduction. UI mode is the other half: it watches your files, reruns on save, and shows you where a locator matched nothing.
Day 9 is the honest day. A flaky test passes and fails on unchanged code. The usual causes are racing the application, depending on data another test created or deleted, and tests that only work in one order. The part nobody says plainly: a flaky test costs your team more than no test. People rerun it, stop reading its failures, then skip it, and after that the suite is decoration. So when yours goes flaky you have three honest options. Fix the race with a proper assertion. Make the test own its own data. Or delete it and say you deleted it. What you do not do is add a retry and call it green.
Best for: Playwright (~36K subscribers). The official walkthroughs of both debugging tools, and the video on reproducing a failure that only happens on the build server. Start with: Playwright, "Exploring Playwright's Trace Viewer for debugging locally and on CI", https://www.youtube.com/watch?v=yP6AnTxC34s , then "Playwright's UI Mode: Watch mode and time travel debugging", https://www.youtube.com/watch?v=d0u6XhXknzU , then on Day 9, "How to trigger flaky Playwright tests locally after they fail on CI", https://www.youtube.com/watch?v=0dHDmSjx55o
Done looks like: a trace you opened and read from a test you broke on purpose, traces enabled on retry in your config, and your test run ten times in a row with the same result every time.
Day 10: run it in your team's pipeline
Today the work stops being yours and becomes the team's. Continuous integration means your tests run automatically when someone pushes code, on a machine that is not your laptop, and report back on the pull request. On GitHub Actions that is one workflow file, and Playwright generates a usable one for you during install.
Three things trip people up. The build server has no browsers, so the workflow has to install them, which the generated file already handles. Your application has to be reachable: either the workflow starts it, or you point the tests at a deployed environment through the base URL in your config, and the second is usually the honest answer for a first test. And nobody reads logs, so upload the HTML report and traces as artifacts. A failing run that hands a reviewer a trace gets fixed; a failing run that hands them 400 lines of terminal output gets rerun until it passes.
Open a pull request with your test and the workflow file, and ask a developer to review it. That review is the moment the fortnight pays off. If the suite is going to live in the developers' repository, it has to read like their code, and they are the only ones who can tell you whether it does.
Best for: Automation Step by Step (~590K subscribers). A step-by-step GitHub Actions demo pitched at people who have never opened a workflow file. Start with: Automation Step by Step, "GitHub Actions Step by Step DEMO for Beginners", https://www.youtube.com/watch?v=ylEy4eLdhFs
Done looks like: a green check on a pull request with your name on the commit, the HTML report downloadable from the run, and a colleague who has read your test and had something to say about it.
What to skip this fortnight
Skip BDD and Cucumber, building a framework from scratch, custom reporting, mobile, performance testing, API testing, Selenium unless your team runs it, and the entire "which tool is best" genre. Every one is real work that real teams do. None of them gets one test into your pipeline by Friday of week two.
BDD and Cucumber. Tests written as plain-English Given/When/Then scenarios, with a layer mapping each sentence to code. It sells well to managers and it doubles the files you maintain. It earns its place when non-technical people genuinely write or read the scenarios, which is rarer than the tooling implies. Learn it if your team already has it, never as your first structure.
Building a framework from scratch. The urge to build a base class, a config loader and a folder hierarchy before writing test number one. Playwright already is the framework. Write ten tests, then extract what repeats. A framework designed before the tests exist is a guess about tests you have not written.
Custom reporting. The built-in HTML report is good, and on Day 10 it lands on your pull request. Richer reporting is for when several people read results daily and want history. If that is you later, Execute Automation has the walkthrough, as an optional extra rather than part of this fortnight.
Best for: Execute Automation (~120K subscribers). Explicitly month two, once the built-in report is not enough for the people reading it. Start with: Execute Automation, "Allure Reporting for Playwright - A comprehensive all-in-one test report", https://www.youtube.com/watch?v=u0KyDdYxALI
Mobile and performance testing. Different tools, different failure modes, different skills. Device emulation in a desktop browser is not mobile testing, and load testing answers a question nobody asked you.
API testing. Valuable and genuinely next. API tests are faster and less flaky than browser tests, and a mature suite has more of them. It is skipped here only because your deliverable is a user journey.
Best for: freeCodeCamp.org (~12 million subscribers). Month two, after the browser test is running. Start with: freeCodeCamp.org, "Postman API Test Automation for Beginners", https://www.youtube.com/watch?v=zp5Jh2FIpF0
Selenium, unless your team runs it. Selenium is the oldest and most widely deployed of these tools, and if your team uses it, that is what you learn. Otherwise it is a slower start with more setup for the same career.
The "which tool is best" genre. Comparison videos are the most engaging and least useful content in this field. The decision takes five minutes and was probably made for you. If you are still weighing whether structured video is enough at all, our piece on whether you need a bootcamp or YouTube is enough is the honest version of that argument.
If you only have one sitting
If you cannot spread this over ten days, take one long course covering testing concepts and Playwright end to end, then do Day 10 separately as soon as you can. One sitting gets you a test that runs on your machine and a real sense of the shape of the work. It does not get you the pipeline, and the pipeline is the part your team sees.
Best for: freeCodeCamp.org (~12 million subscribers). A single free course, published 2026-03-19, covering software testing concepts and end-to-end work in Playwright, with a section on AI agents in testing. Start with: freeCodeCamp.org, "Software Testing Course - Playwright, E2E, and AI Agents", https://www.youtube.com/watch?v=jydYq7oAtD8
Be clear about what one sitting cannot give you: a locator you chose badly and had to fix, a flaky test you watched fail twice and then understood, or a review from a developer on your team. That is where the learning happens, and all three need calendar days.
One disclosure. Several creators named here sell paid courses, on their own sites or on course marketplaces, and some mention them inside the free videos linked above. Every video named in this plan is free on YouTube and nothing here depends on buying anything. Treat any paid product as an optional extra sold separately, not as part of the free channel content recommended above.
Frequently asked questions
Six questions from the gap between being told the team is adding automated tests and having one that runs.
What is test automation, and how is it different from manual testing?
Test automation is a program that drives your application like a user, clicks, types, navigates, then checks that the result matches what you expected. Manual testing is you doing that with your own eyes and judgement. The automated version is faster and repeatable. The manual version notices things nobody wrote down.
Can a manual QA tester learn test automation in two weeks?
Enough for one real test in the pipeline, yes. Ten days at roughly an hour each covers the language basics, install, locators, assertions, structure, debugging and continuous integration. It will not make you an automation engineer. It will end with code a colleague can read and a green run nobody had before.
Should you learn Playwright, Cypress or Selenium in 2026?
If the choice is yours, Playwright, because setup is short and the debugging tools are the best of the three. If your team already runs Cypress or Selenium, learn that one instead, today, because a test in the suite your team uses beats a better test nobody runs. The concepts transfer either way.
Do you need to learn to code to write automated tests?
Yes, but less than you fear. You need variables, functions, async and await, and the ability to read an error message. That is a few hours, not a degree. Day 2 of this plan is deliberately one sitting of TypeScript, because the rest of the fortnight teaches the tool, not the language.
What makes an automated test flaky, and why does it matter?
A flaky test passes and fails on the same code, usually because it races the application or depends on data another test changed. It matters because a suite people stop trusting gets ignored, then skipped, then deleted. One flaky test costs your team more attention than the test was ever worth.
Does LearnPath give a certificate for finishing a test automation learning path?
Yes, on the Pro plan. LearnPath builds a path from free YouTube videos and generates a quiz from each transcript, and Pro learners get a certificate on finishing. Exactly one learner here has ever built a QA path, so treat it as proof you finished your own plan, not as a credential employers know.
Proving you did it
The strongest proof is the test itself: running in your team's pipeline, on a commit with your name on it, reviewed by a developer whose comments you addressed. That is a thing you can point at in a performance review, in an internal application for an automation role, or in an interview elsewhere. Nothing else on this page competes with it.
Say it precisely. Not "I learned Playwright" but "I automated our checkout regression case, it runs on every pull request, and it caught a broken discount field in week three." The second sentence is a contribution; the first is a course you watched. Hiring managers hear the difference immediately, and a working test in a shared repository is checkable in a way a certificate is not.
LearnPath's own certificate is the secondary proof, and it comes with the Pro plan. Frame it honestly: exactly one learner here has ever built a path for software quality assurance, out of 1,587 paths built in total as of 2026-09-28, so it is proof you finished your own plan on a skill almost nobody schedules, not a credential a hiring manager recognises. It is not accredited and no employer has heard of it.
The deadline does more work than any badge. This plan has dated days because a fortnight with a deliverable finishes and an open-ended intention does not, which is the same reason moving from cloud support into cloud engineering works better as a dated plan than as a reading list. Pick the case, book the hours, and build a work-ready test automation path before your next sprint starts.
