You’ve been testing for four years. You know boundary value analysis better than most developers know their own edge cases. And you keep getting filtered out of automation roles because the screening question is “how many years of Selenium experience do you have,” and the honest answer is zero, because your job never gave you any.
That’s the trap. No automation job without automation experience. No automation experience without an automation job. Practice projects are the only exit from that loop that doesn’t require anyone’s permission.
This article gives you ten of them, each with a named practice site, a stack, a manual half and an automation half, a realistic build time, and a plain statement of what it proves to a hiring panel. It’s the practice work, not the theory: for the full learning sequence from manual to automation, start with our complete software testing roadmap from manual to automation and come back here when you’re ready to build. Every target named in this guide is a sandbox built for automation practice, so nothing you build here breaks the day someone else ships a production release.
Why Practice Projects Are the Only Way Out of the Manual-Only Trap
When a hiring panel asks about your automation experience, they aren’t really checking for a job title. They’re looking for evidence that you’ve made design decisions under real constraints: why you chose one wait strategy over another, why your framework is structured the way it is, what you did when a test passed alone and failed in a suite.
A practice project is weaker evidence than production work. Say that plainly instead of overselling it. But it’s dramatically stronger than a certificate, a course-completion badge, or a résumé line that just says “Selenium.” A panel can inspect a public repository in four minutes. They cannot inspect your last four years.
One piece of anti-advice worth taking seriously: never describe a practice project in language that implies it was client work. Indian interview panels routinely probe with questions about environment, team size, release cadence, and stakeholders, and the fabrication surfaces within two minutes. Label practice work as practice work and let the artefact do the arguing.
In short: software testing projects matter for a QA portfolio because they’re the only evidence a candidate without production automation experience can put in front of a panel. The candidate who opens their own repo in an interview and walks through one flaky test they fixed will always beat the identically qualified candidate reciting the same tool list from memory.
For what panels actually screen for at each experience level, see the QA engineer skills panels actually test for; this article is the evidence layer for that checklist.
Transform Your Career
Choose from our industry-leading programs designed for career success
Modern Software and AI Engineering Program
Master full-stack development with AI integration
+1000 more Modern Data Science and ML with specialisation in AI
Advanced data science techniques with AI specialization
+1000 more Advanced AIML with Specialisation in Agentic AI
Deep dive into AIML with focus on Agentic systems
+1000 more DevOps, Cloud & AI Platform Engineering
Build and manage AI-powered cloud infrastructure
+1000 more AI Engineering Advanced Certification by IIT-Roorkee
Premier AI engineering certification from IIT-Roorkee
Before You Start: Where to Practise Legally
Most project lists tell you to “test an e-commerce website.” Readers then point Selenium at a live retail site, and three things go wrong: the DOM changes under them for reasons unrelated to their code, the site’s bot protection blocks the driver, and if the project scales into a load test, they generate unauthorised traffic against infrastructure they don’t own. None of that teaches testing.
The rule worth internalising: practise on applications built to be practised on. They’re stable, versioned, documented, and often seeded with deliberate bugs, which makes them better practice, not a compromise.
| Practice target | URL | Best for | Why it works |
| The Internet (Herokuapp) | the-internet.herokuapp.com | Selenium/Playwright edge cases | ~44 isolated pages for dynamic loading, alerts, iframes, file upload, drag-and-drop, basic auth |
| Sauce Demo | saucedemo.com | E2E flows, POM framework | Stable login to checkout flow, with deliberately broken accounts that hand you real defects |
| Automation Exercise | automationexercise.com | Full manual suite + API | Publishes its own 26 documented test cases and exposes REST endpoints; serves Projects 1, 2 and 3 |
| OrangeHRM demo | opensource-demo.orangehrmlive.com | Manual test-case suite | Multiple modules and permissions; enough surface for 80+ meaningful test cases |
| Parabank (Parasoft) | parabank.parasoft.com/parabank | Banking-domain testing | Accounts, transfers, bill pay, loan requests, with a resettable database |
| ReqRes | reqres.in | API testing, first Postman run | Predictable REST responses, real status codes, paginated lists |
| Restful Booker | restful-booker.herokuapp.com | API auth, CRUD, negative paths | Token auth, full CRUD, published docs, and known intentional bugs |
| Swagger Petstore | petstore.swagger.io | Schema/contract validation | A published OpenAPI spec, the correct target for contract testing |
| Blazedemo | blazedemo.com | JMeter performance practice | A deliberately simple flight-booking app, built as a load-test target |
| Grafana QuickPizza | Grafana’s official k6 demo app | k6 performance practice | Published by Grafana specifically for k6 practice |
| Sauce Labs Demo App (Android) | official Sauce Labs sample repo | Appium mobile automation | A published sample Android app, no third-party production app involved |
| TodoMVC demo | demo.playwright.dev/todomvc | Visual regression baselines | Deterministic UI, ideal for stable screenshots |
Verify these are live on the day you start. If one has moved, self-host it locally using its public Docker image.
Four rules keep practice projects clean. Never run a load test against a system you don’t own or that hasn’t invited it; in India this can engage the Information Technology Act, 2000. Read the robots.txt and terms of use before automating anything. Never commit credentials or .env files, even demo ones. And pin your target: note the version or date you tested against, and for anything long-lived, self-host it. If containers are new to you, the Docker roadmap is a fast on-ramp.
How to Use This List
The honest answer to “how many projects do I need” is three. One finished, documented project running in CI from each tier beats ten half-built repos; a panel reads depth, not count.
Tier 1 proves you can test: design, judgement, communication. Tier 2 proves you can build: framework structure and maintainability. Tier 3 proves you can specialise, a niche most candidates skip. Build times below assume you already know one programming language; double them if you’re learning the language too.
| Project | Tier | Build time | Primary stack | What it proves | |
|---|---|---|---|---|---|
| 1 | Manual test suite + bug reports | Foundation | 12-18 h | Sheets/Qase/Jira, Xmind | Test design and defect communication |
| 2 | API suite (Postman to REST Assured) | Foundation | 10-15 h | Postman, Newman, REST Assured | Service-layer testing, schema validation |
| 3 | UI framework with Page Object Model | Core | 20-30 h | Selenium/Playwright, TestNG | Framework design, not scripting |
| 4 | Data-driven / keyword-driven framework | Core | 10-15 h | Apache POI, TestNG DataProvider | Separating test logic from test data |
| 5 | BDD suite with Cucumber | Core | 12-18 h | Cucumber, Gherkin, JUnit | Readable specs, collaboration |
| 6 | CI-integrated regression suite | Core | 8-12 h | GitHub Actions, Allure, Docker | Automation that runs on every commit |
| 7 | Mobile automation with Appium | Specialisation | 15-25 h | Appium, Android emulator | A distinct, less crowded niche |
| 8 | Performance testing (JMeter, k6) | Specialisation | 12-18 h | JMeter, k6, Grafana | Reading percentiles, not averages |
| 9 | Visual regression testing suite | Specialisation | 8-12 h | Playwright snapshots | Catching what assertions can’t |
| 10 | Test strategy document | Specialisation | 6-10 h | Document, risk matrix | Judgement about what not to test |
For how much depth counts as “done,” the same principle shows up in how full-stack projects are structured for a job-ready resume.
Tier 1: Foundation Projects
- A Manual Test-Case Suite and Bug Report Portfolio
What it tests: a multi-module app end to end, functional coverage, role-based permissions, and negative paths.
Practice target: OrangeHRM for a multi-role surface, or Automation Exercise, which publishes its own 26 test cases you can benchmark against afterward.
Stack: Qase or a well-structured spreadsheet, Jira’s free tier for defects, Xmind for a coverage mind map.
Manual component: 60 to 100 test cases using named techniques (boundary value analysis, equivalence partitioning, a decision table, state transition testing for a workflow); a requirement traceability matrix; three timeboxed exploratory charters run after the scripted cases; and 10 to 15 bug reports with repro steps, expected vs. actual, and severity/priority reasoning.
Automation component: none yet. Tag the 10 to 12 cases that form your smoke suite; that tagged subset becomes Project 3’s backlog.
Time: Beginner, 12-18 hours. What it proves: you design tests rather than click through screens. Interview question: “Why is this Severity 2 but Priority 4?” Have the answer ready.
If verifying data behind the UI is a gap for you, the SQL learning path covers exactly that.
- An API Test Suite: Postman to Newman to REST Assured
What it tests: the service layer beneath the UI, status codes, schemas, auth, and negative paths the UI hides.
Practice target: ReqRes first, then Restful Booker for auth and CRUD, then Swagger Petstore for schema validation against its published spec.
Manual component: explore the API by hand first and document what should be true (required fields, error shapes, expired vs. missing tokens) before writing a single assertion.
Automation component: a Postman collection with environments and chained variables, the same collection run headlessly via Newman, and a rewrite of the ten most important cases in REST Assured or PyTest with schema validation.
Time: Beginner-Intermediate, 10-15 hours. What it proves: you test below the UI. Level-up: a contract test that fails when the response drifts from the OpenAPI spec.
The point where the REST Assured rewrite happens is where API testing becomes an engineering skill; the sequenced curriculum for that lives in the automation testing roadmap from manual to SDET.
Tier 2: Core Automation Projects
Build at least two. Project 3 is the spine; Projects 4, 5, and 6 extend the same repository rather than starting fresh, so your history shows visible evolution.
- A UI Automation Framework with Page Object Model
What it tests: the smoke suite from Project 1, login, search, cart, checkout, two negative flows.
Practice target: Sauce Demo for the stable flow, plus The Internet (Herokuapp) for dynamic loading, iframes, and alerts.
Stack: pick one and say why in your README. Java + Selenium + TestNG + Maven is still the most-named combination in Indian job listings; Playwright with TypeScript has the steeper demand curve. If Java classes feel shaky, a free beginner Java course is worth the hour first.
Manual component: run the smoke suite by hand once and time it. “A 38-minute manual run became a 4-minute pipeline job” is a number you cannot construct retroactively.
Automation component: one page class per screen with private locators, a base test class, externalised configuration, explicit waits with zero Thread.sleep, screenshot-on-failure, and a README explaining your architecture and trade-offs.
Time: Intermediate, 20-30 hours, the largest investment on this list. What it proves: you can own a framework, not just add tests to one. Common mistakes: one giant test class, absolute XPath, assertions inside page objects.
If the Java vs. Python vs. JavaScript choice is what’s stalling you, which programming language to pick for jobs resolves it.
- A Data-Driven and Keyword-Driven Framework
What it tests: the same flows as Project 3, driven by external data: login combinations, checkout permutations, boundary values.
Practice target: extend the Project 3 repository, using Sauce Demo’s multiple accounts as a data set.
Manual component: design the data set first, using equivalence partitioning, and publish that reasoning next to the file. The value is the selection, not the loop.
Automation component: parameterised tests via TestNG DataProvider or PyTest parametrize, reading from CSV/JSON/Excel, with distinct reporting per row.
Time: Intermediate, 10-15 hours. What it proves: you separate test logic from test data, the most common maintainability failure in real enterprise suites. Keyword-driven frameworks are less fashionable now; build one anyway for services-company roles, and note in your README that you understand the trade-off.
Scaler Placement Report and Statistics
Scaler learners achieved 2.5x salary growth with average post-Scaler CTC reaching ₹23L.
Google Amazon 
Microsoft 
Flipkart 
Adobe 1200+ more - A BDD Suite with Cucumber
What it tests: three or four business-critical journeys written as behaviour, not clicks.
Practice target: the Project 3 repository, or Automation Exercise for a fresh feature set.
Manual component: write feature files before any step definitions, in language a business analyst would recognise.
Automation component: step definitions that delegate to existing page objects and never contain locators, scenario outlines with example tables, and a generated living-documentation report.
Time: Intermediate, 12-18 hours. What it proves: you can bridge business language and test code. Honest nuance: BDD is often reduced to "Gherkin syntax over UI scripts" with no real business involvement; naming that anti-pattern is more credible than evangelising the tool.
- A CI-Integrated Regression Suite with Real Reporting
What it tests: everything you've built so far, on every commit, automatically.
Practice target: your own repository.
Manual component: decide the pipeline tiering (smoke per commit, full regression nightly, cross-browser weekly) and document why.
Automation component: a GitHub Actions workflow that installs dependencies, runs the suite in parallel, publishes an Allure report, fails the build on failure, and a status badge in the README.
Time: Intermediate, 8-12 hours, the best effort-to-signal ratio on this list. What it proves: your automation actually runs, rather than sitting abandoned. Tip: the badge is the highest-leverage pixel in a QA portfolio.
If the pipeline work interests you more than test writing, that overlap is real; see the DevOps roadmap.
Tier 3: Specialisation Projects
Pick one. Most applicants for the same role will have a Selenium repo; almost none will have Appium, a k6 script with percentile analysis, or a test strategy document.
- Mobile Automation with Appium
Practice target: the official Sauce Labs sample Android app on an emulator, never a third-party production APK.
Manual component: exploratory testing on device conditions with no desktop equivalent (rotation, backgrounding, interruption, low storage). Most interesting mobile bugs live here.
Automation component: capability configuration, accessibility-ID-first locators, gestures, and a recorded video of a passing run.
Time: Advanced, 15-25 hours; budget three hours just for environment setup. What it proves: you can work in a genuinely harder, under-supplied niche.
- Performance Testing with JMeter and k6
Practice target: Blazedemo for JMeter, Grafana's QuickPizza for k6, or something self-hosted.
Manual component: define the workload model and explicit thresholds (for example, "p95 under 800ms at 200 virtual users") before running anything. Setting the threshold after seeing results isn't a test.
Automation component: a JMeter plan with thread groups and assertions, and a k6 script with stages and thresholds that fail the run automatically.
Time: Advanced, 12-18 hours. What it proves: you read percentiles, not averages. A 200ms average with a 3-second p99 hides a real problem, and performance interviews probe this immediately.
- A Visual Regression Testing Suite
Practice target: the Playwright TodoMVC demo or Sauce Demo, both deterministic enough for stable baselines.
Manual component: decide what to baseline and what to mask (timestamps, carousels, avatars). Masking decisions are the skill, not the screenshots.
Automation component: baseline capture with Playwright's snapshot feature, a diff run on a deliberate CSS change, and threshold tuning.
Time: Intermediate, 8-12 hours. What it proves: you catch defects functional assertions structurally can't. Honest nuance: it has a real maintenance cost; knowing when it pays off (checkout pages) versus when it doesn't (fast-changing UI) is the signal.
- A Test Strategy Document
What it tests: judgement. Nothing is executed here.
Practice target: a product you understand as a user (a UPI app, a food-delivery app).
Contents: scope and out-of-scope, a risk matrix, test levels mapped to the test pyramid grounded in the ISTQB Foundation Level syllabus, what stays manual versus automated with the cost argument, and entry/exit criteria.
The valuable part: what you would not test, and why. Every candidate can list what to test; deciding what to skip under a deadline is lead-level thinking.
Time: light in effort, heavy in judgement, 6-10 hours. What it proves: system-level thinking, the highest-leverage artefact for a senior or lead application. For the delivery context this document assumes, see the software engineering syllabus.
The Manual + Automation Pairing
Automation doesn't replace manual testing. It replaces repeating a test you've already designed and run. Panels ask "how do you decide what to automate" more than any single tool question, and the strong answer names actual criteria (repetition frequency, stability, maintenance cost, business risk) with a concrete example of something deliberately not automated.
| Do this manually first | Then automate this | |
| 1 | Design all cases; run exploratory charters; write bug reports | Nothing yet, tag the smoke cases |
| 2 | Explore every endpoint; document expected schemas and errors | Status, schema, headers, negative paths |
| 3 | Time the manual smoke run; note ambiguous UI moments | The timed smoke suite, as page objects |
| 4 | Choose the data combinations worth running | Parameterised execution across the set |
| 5 | Write feature files in business language | Step definitions over existing page objects |
| 6 | Decide the pipeline tiering | The pipeline, reporting, scheduling |
| 7 | Explore rotation, backgrounding, interruptions | Stable happy paths and core regression |
| 8 | Define the workload model and thresholds | Load execution and enforcement in CI |
| 9 | Decide what to baseline and mask | Baseline capture, diffing, thresholds |
| 10 | The entire document | Nothing |
The strongest QA candidates aren't the ones who automate the most. They're the ones who can explain, for any given check, why it lives where it lives.
The Framework-Quality Checklist
A reviewer spends about four minutes in your repository: the folder structure, one page object, the CI config, the README. Everything below is visible in those four minutes.
| Practice | Why it signals seniority |
| Page Object Model | Shows separation of what's tested from how the page works |
| Externalised configuration | A hard-coded URL means the suite only ever ran once |
| No hard-coded waits | Thread.sleep signals you don't understand synchronisation |
| Reporting (Allure/ExtentReports) | Turns a console dump into something a manager can read |
| Parallel execution | Proves your tests are independent, no shared state |
| CI integration | Automation that only runs on your laptop isn't automation |
| Test data management | Prevents "passes alone, fails in the suite" |
| Failure artefacts | Cuts debugging time from hours to minutes |
| Deliberate retry policy | Quarantine plus a fix plan shows maturity over blanket retries |
| Secrets handling | A committed token is negative evidence, noticed instantly |
| README with architecture | The one part a non-technical reviewer reads in full |
| Iterative commit history | One "initial commit" dump reads as a tutorial download |
You can add most of these to an existing suite in a weekend, and it changes how the repository reads more than another ten test cases would. The official docs for Selenium, Playwright, Allure, and GitHub Actions cover the exact syntax.
How to Present These Projects
On GitHub: clean folder structure, a README with architecture notes, a one-command run instruction, your stack choice with reasoning, a report screenshot, a CI badge, and a short "what I'd do differently" section, which reads as maturity, not modesty. Pin your two best repos; nothing else gets scrolled to. Never commit credentials, .env files, or IDE folders.
In documents: manual artefacts (test plan, RTM, bug reports, performance summary) belong in a small set of PDFs in a shared Drive folder, linked from both your résumé and README. Two excellent documents beat eight adequate ones.
On your résumé: two lines per project, shaped as outcomes. Weak: "Worked on Selenium framework using Java, TestNG." Strong: "Built a POM framework covering a 12-case smoke suite; cut a 38-minute manual run to 4 minutes; wired into GitHub Actions." Put the repo link in your header. For readers building a first application from scratch, how to get a job in IT covers the rest.
When it wasn't for an employer: label it honestly up front ("this is a practice project against a public sandbox"), talk about decisions rather than features, bring numbers, keep one failure story ready, and be ready to open the repo live. Don't overclaim; a panel will know within two questions about environments and releases.
Which Project Should You Build First
If you're a manual tester with two-plus years, start with Project 3, then backfill Project 1 using cases from your own domain; the automation gap is what's blocking you. If you're a fresher or final-year student, start with Project 1, then Project 2; both make a strong final-year submission and are cheaper to build than a framework. If you haven't entered QA at all, how to become a software tester covers entry requirements first. If you're switching from a non-QA IT role, start with Project 2; your HTTP and JSON knowledge converts fast.
Finish one project before starting the next. A finished, CI-running project beats three abandoned ones.
The 6-week minimum viable QA portfolio
Weeks 1-2: Project 1, sixty test cases on OrangeHRM, three exploratory charters, ten bug reports. Weeks 3-4: Project 3, time your manual smoke run, then build the POM framework against Sauce Demo. Week 5: Project 6, GitHub Actions on every commit, Allure report published. Week 6: Project 2 or Project 10, depending on whether you're targeting automation or lead roles.
At the end: one public repository with a passing badge, one Drive folder of manual artefacts, and one ready sentence for every interview.
Scaler Alumni and Their Success Stories
Also Explore These Projects to Build Your Portfolio
Frequently Asked Questions
What are good software testing projects for beginners?
A manual test-case suite and bug report portfolio on OrangeHRM, then a Postman API suite against ReqRes. Both need no framework setup and take under fifteen hours each.
Where can I practise software testing on a real website legally?
Sandbox apps built for practice: the-internet.herokuapp.com, saucedemo.com, automationexercise.com, Parabank, reqres.in, and restful-booker. They're stable and permit automation, unlike production sites.
Can I put practice projects on my resume if they weren't for a company?
Yes, but label them as practice work explicitly, describe outcomes with numbers, and link the repository. Never imply it was client work.
How many software testing projects do I need in a portfolio?
Three finished ones: a manual suite, a framework running in CI, and one specialisation. Depth beats count.
What should a Selenium sample project contain?
Page Object Model classes with private locators, externalised configuration, explicit waits with no Thread.sleep, a reporting library, parallel execution, a CI workflow, and a README explaining trade-offs.
What are good software testing micro-project topics for final-year students?
A documented manual suite with an RTM, an API suite with schema validation, and a small POM framework, since all three produce assessable documentation.
How long does it take to build an automation testing portfolio?
About six weeks of evening work for three projects, if you already know one language. Double it if you're learning the language too.
How do I get real-time testing projects to practise on?
Automate a repetitive task at your current job, contribute tests to an open-source project, or build against the sandbox applications above. Paid freelance work generally requires a portfolio first.
The automation-experience trap is real, and no certificate solves it. What solves it is producing projects that someone can inspect. Three finished projects, one manual suite, one framework running in CI, and one document will outweigh ten half-built repos in every interview.
The strongest QA candidates aren't the ones who automated the most. They're the ones who can explain why each check lives where it lives. Every project on this list is practice for that conversation. Pick one, and start this week.
