The purpose of testing, how to think about coverage, and writing a bug report worth acting on.
- Why Tests Exist11 min
- The Testing Pyramid12 min
- Test Cases and Bug Reports11 min
- Turning Requirements into Testable Criteria13 min
All coursesQA
Learn to find bugs before users do.
Read the guide: How to become a QA engineer: skills, roadmap, first job
Accredited Curriculum & Certification
Official Syllabus SnapshotDirect Answer: Learn to find bugs before users do, and to write automated tests that stay useful instead of becoming a maintenance burden.
Tuition Fee
100% Free
Duration & Workload
~10 Hours
Curriculum Depth
12 Chapters · 48 Lessons
Credential Awarded
Verified Certificate
12Chapters
Course outline
Writing fast, focused tests — and the assertions and structure that make them readable.
- Arrange, Act, Assert12 min
- Mocking, and When Not To12 min
- Coverage and What It Really Tells You11 min
- Test-Driven Development in Practice13 min
Testing React components the way a user experiences them, not the way they are implemented.
- Testing Library and the Behaviour Principle12 min
- Async UI, Forms, and What Not to Test12 min
- End-to-End Testing12 min
- Visual Regression Testing13 min
API routes, database interaction, and the security cases worth an automated test.
- Integration Testing an API12 min
- Testing Authorisation and Security12 min
- Test Data and Fixtures11 min
- Testing for Race Conditions13 min
Running tests automatically, keeping the suite trustworthy, and knowing when manual testing wins.
- Continuous Integration11 min
- Keeping a Suite Trustworthy11 min
- Manual and Exploratory Testing11 min
- Testing After the Deploy13 min
Measuring how the system behaves under real traffic, finding the bottleneck, and holding a front-end budget.
- Load Testing with k612 min
- Finding the Bottleneck12 min
- Front-End Performance Budgets11 min
- Soak Tests and Memory Leaks13 min
Accessibility you can automate, contracts between services, and proving your tests would actually catch a bug.
- Automated Accessibility Testing12 min
- Contract Testing Between Services12 min
- Proving Your Tests Would Catch a Bug12 min
- Catching Visual Breakage in Shared Components13 min
Asserting on behaviour that finishes long after the response returns: queued jobs, inbound webhooks, and work scheduled for next Tuesday.
- Testing Background Jobs and Queues13 min
- Asserting on Eventual Consistency13 min
- Webhooks, Callbacks, and Third-Party Sandboxes13 min
- Cron Schedules, Time Zones, and Date Boundaries13 min
Keeping a large suite fast, hermetic, and pleasant to work in once dozens of engineers depend on it every single day.
- Real Dependencies in Disposable Containers13 min
- Sharding, Parallelism, and the Runtime Budget13 min
- Running Only the Tests a Change Can Break13 min
- A Test Harness Other People Can Use13 min
Probing a system the way someone hostile would, and turning every finding into a check that runs forever.
- Turning a Threat Model into Test Cases13 min
- Fuzzing and Malformed Input13 min
- Dependency, Secret, and Supply Chain Scanning13 min
- Turning a Pen Test Finding into a Regression Test13 min
Proving a release is safe using real traffic, gradual exposure, and failures you cause on purpose.
- Testing Both Sides of Every Flag13 min
- Shadow Traffic and Response Diffing13 min
- Automated Canary Analysis13 min
- Fault Injection and Chaos Experiments13 min
Deciding what deserves testing at all, bringing an inherited system under cover, moving a suite without losing it, and owning the call on whether a release ships.
- Risk-Based Strategy When You Cannot Test Everything13 min
- Characterization Tests for Code Nobody Understands13 min
- Migrating a Suite Without Losing Cover13 min
- Quality Metrics and the Release Decision13 min
Final exam & certificate
- 01
Topic checks
Each one opens the next topic
- 02
Chapter quizzes
Each one opens the next chapter
- 03
50-question final
50 of 100 marks to pass
- 04
Certificate
Issued instantly, verifiable
One attempt, 60 minutes. If you don't pass, you can retake once after 30 days.
How to become a QA engineer: skills, roadmap, first job
To become a QA engineer, learn to think about risk first and tools second. Start by writing clear test cases and bug reports by hand, then learn enough programming to write unit tests, then move on to API tests, browser automation and running tests in CI. Build a small portfolio that shows real bugs you found and a test suite you wrote for a real app. You do not need a computer science degree, but you do need to be able to read code, because much QA work today involves at least some automation.
This guide gives you that path as a roadmap, explains what the job actually involves day to day, and shows what our free Software Testing & QA course covers chapter by chapter.
What a QA engineer actually does
The job title covers a wide range, but the work is the same: find out where software breaks before users do, and make sure it stays fixed.
On a normal week, that means some mix of:
- Reading a feature's requirements and turning them into checks someone can actually verify
- Exploring a new build by hand, looking for the cases nobody wrote down
- Writing clear bug reports a developer can reproduce in one try
- Writing and maintaining automated tests at the unit, API and browser level
- Keeping the test suite fast and trustworthy, so the team keeps running it
- Helping decide whether a release is safe to ship
Testing cannot prove software works. It buys the team confidence to change things.
Manual tester vs QA automation engineer
Many people start in manual testing and move into automation. Both are real QA work, and good automation engineers never stop doing exploratory testing.
| Manual and exploratory testing | QA automation | |
|---|---|---|
| Main skill | Curiosity, careful observation, clear writing | Programming, test design, debugging |
| Typical output | Test cases, bug reports, exploratory notes | Test code that runs on every change |
| Best at | Finding requirements nobody wrote down, usability problems | Catching regressions quickly and repeatedly |
| Tools | A browser, dev tools, a bug tracker | Jest, Playwright, Supertest, CI pipelines |
| Coding needed | Little to none | Yes, usually JavaScript, Python or Java |
Aim for automation but keep the manual skills.
The skills you need to become a QA engineer
Testing fundamentals
Learn the difference between verification (did we build it right?) and validation (did we build the right thing?). Learn the testing pyramid: many fast unit tests, fewer integration tests, and a small number of end to end tests.
Writing test cases and bug reports
This sounds basic and it is where most beginners are weakest. A good bug report has a short, specific title, exact steps, what you expected, what actually happened, and the environment. "Login broken" wastes everyone's time. "Login with a valid email in uppercase returns 'user not found'" gets fixed.
Enough programming to automate
JavaScript is a sensible choice because the same language covers unit tests, API tests and browser tests. Python and Java are also widely used for testing. Not sure yet? See which programming language to learn first.
Automation at every level
Unit tests with a framework like Jest, API tests that send real HTTP requests, and browser tests with a tool like Playwright. Each catches a different kind of bug, and knowing which level a test belongs at is a large part of the skill.
Judgement
The senior skill is knowing what not to test. Money, logins, permissions, data loss and complicated business rules deserve tests. A getter that returns a field does not. A slow, flaky suite that people ignore is worse than a smaller one they trust.
A 6 week roadmap to become a QA engineer
Plan for an hour or two a day. Pick one small web app, your own or an open source one, and use it as your practice target the whole way through.
| Week | Focus | You are ready to move on when you can |
|---|---|---|
| 1 | Purpose of testing, the pyramid, test cases, bug reports | Write ten test cases and three reproducible bug reports for your practice app |
| 2 | Unit testing with Jest, mocking, coverage | Write readable unit tests and explain what coverage does not tell you |
| 3 | UI and end to end testing | Test a form the way a user uses it, and write one stable browser test |
| 4 | API and back end testing, test data, security cases | Test that one user cannot read another user's data through the API |
| 5 | CI, flaky tests, exploratory testing | Run your suite automatically on every push and fix one flaky test |
| 6 | Performance, accessibility, risk based planning | Run a basic load test and rank what to test when time is short |
Mistakes that slow beginners down
- Learning tools before purpose. Playwright is easy to learn. Knowing what to point it at is the hard part.
- Chasing 100 percent coverage. Coverage shows which lines ran, not whether the tests would notice a bug. A suite can hit every line and assert nothing useful.
- Mocking everything. Mock too much and you are testing your mocks, not your code.
- Testing implementation details. Tests that check internal state break every time someone refactors, even when the behaviour is unchanged. Test what the user or caller sees.
- Tolerating flaky tests. Once a team learns to rerun failures until they pass, real failures get ignored too.
What the free Software Testing & QA course covers
The Software Testing & QA course is a beginner to intermediate course planned for about 6 weeks. It has 12 chapters with 4 lessons each, every lesson an 11 to 13 minute read with a short quiz. The examples use JavaScript, Jest, Testing Library, Supertest, Playwright and k6.
- What Testing Is Actually For: why tests exist, the testing pyramid, test cases and bug reports, turning requirements into testable criteria.
- Unit Testing with Jest: arrange, act, assert; mocking and when not to; what coverage really tells you; test driven development in practice.
- Testing the User Interface: Testing Library and the behaviour principle, async UI and forms, end to end testing, visual regression testing.
- Testing the Back End: integration testing an API, testing authorisation and security, test data and fixtures, race conditions.
- Testing in a Real Workflow: continuous integration, keeping a suite trustworthy, manual and exploratory testing, testing after the deploy.
- Performance and Load Testing: load testing with k6, finding the bottleneck, front end performance budgets, soak tests and memory leaks.
- Testing the Hard Parts: automated accessibility testing, contract testing between services, proving your tests would catch a bug, visual breakage in shared components.
- Testing Work That Happens Later: background jobs and queues, eventual consistency, webhooks and third party sandboxes, cron schedules and time zones.
- The Suite at Scale: real dependencies in disposable containers, sharding and parallelism, running only the tests a change can break, a harness other people can use.
- Testing Like an Attacker: turning a threat model into test cases, fuzzing, dependency and secret scanning, turning a pen test finding into a regression test.
- Verifying a Live System: testing both sides of every feature flag, shadow traffic, automated canary analysis, fault injection and chaos experiments.
- Owning Quality: risk based strategy, characterization tests for code nobody understands, migrating a suite without losing cover, quality metrics and the release decision.
Chapters 1 to 5 are the core a junior QA engineer needs. Chapters 6 onward are what separate someone who writes tests from someone a team trusts to own quality. If the back end chapters feel heavy, our Node.js backend course fills in how the APIs you are testing are built, and the Cybersecurity Fundamentals course goes deeper on the attacker mindset from chapter 10.
Who it is for, how long it takes, and the certificate
It suits fresh graduates looking for a way into a software house, manual testers who want to move into automation, and developers whose tests keep breaking or getting ignored. You should be comfortable reading basic JavaScript; you do not need to be an expert.
Each lesson unlocks its quiz after 90 seconds of reading, and you need 70 percent to pass it. The course ends with a final exam of 50 questions in 60 minutes, and you pass with 50 out of 100 marks. You get one timed attempt; if it goes badly, a single retake opens 30 days later. Pass, and you get a certificate with a verification code anyone can check.
Be honest about what it proves: that you passed our exam. For a QA role, a public repository with a real test suite, a CI badge and a few well written bug reports says much more. Our post on whether free online certificates are worth anything covers this in detail.
How to get your first QA job
Build proof, not just knowledge. Take one open source web app and write a test plan for it, a set of unit and API tests, and two or three browser tests, all running in CI. Find real bugs while exploring, and write them up properly. Put it on GitHub with a short README explaining what you chose to test and why you skipped the rest.
Apply for junior QA, SQA and test automation roles, and for internships at software houses.
Questions, answered
05 questions
Yes. What matters is clear thinking about risk, good bug reports and, for automation roles, working test code. A portfolio shows that better than any certificate.
With steady daily practice, the fundamentals and basic automation take a couple of months. Our course is planned for 6 weeks. Being job ready also depends on building a portfolio project, which usually takes a few more weeks.
For manual testing, very little. For QA automation, which many teams now expect at least some of, yes. You need to read and write code in one language well enough to build and debug tests.
It can be a solid entry point because it teaches you how real systems fail. Pure manual roles have less room to grow, so plan to learn automation.
Start with a bug tracker and your browser's developer tools, then a unit testing framework like Jest, an API testing tool, and one browser automation tool like Playwright. Learn Git alongside, since test code lives in the same repositories as the app. Start chapter one of the free [Software Testing & QA course](/learn/software-testing-qa) today, pick a practice app, and write your first bug report before the week is out. That is the first real step to becoming a QA engineer.