QA Portfolio for Freshers: Test Cases, Bug Reports and an API Project

A useful QA portfolio shows how you decide what to test, describe a problem and check a fix. Start with one small application you own or have permission to test. Give another person enough detail to repeat your work. You can build this evidence before your first testing job.

This guide uses a fictional task-tracker application. Its requirements and defect example are teaching material, not findings from a real product. Replace them with your own observations before presenting the work as a completed project.

1. Define a small project and its risks

Use a local task tracker with a title field and a task list. Write a short README with the application version, setup steps, browser or API client version, and how to reset the data. If you use a public practice site, follow its permitted-use rules and avoid sending personal data.

For our fictional version, agree on these requirements before testing:

• A task title is required after trimming spaces and must contain 1–100 characters.
• Creating a task saves it once and displays the trimmed title.
• A saved task can be retrieved by its ID.
• Invalid input shows a useful error and does not save a task.

State what the project does not cover, such as authentication, attachments or performance under load. The main risks here are losing valid tasks, saving invalid tasks and showing a success message when nothing was saved. Those risks explain your test choices.

2. Write test cases that someone else can repeat

Give each test a stable ID. Record the requirement, preconditions, exact input, steps and expected result. Keep the actual result separate. A test can be well designed and still be Not run.

Add checks for an empty title, a one-character title and trimming surrounding spaces. For this boundary exercise, use ASCII letters so character counting is unambiguous. If your application supports emoji or other scripts, document its counting rule and investigate those cases separately.

After execution, record what you observed, the build and environment, and an evidence link. Use Blocked when a prerequisite prevents execution. A failure needs a specific observation, not just “does not work”. Retest on a recorded new build instead of silently replacing the original evidence.

3. Write one complete, reproducible bug report

The following is a fictional worked example of a possible failure of TC-002. It illustrates the reporting format; it is not a defect we observed in TechRasta or another live site.

Title

BUG-001: Create task accepts a title containing only spaces.

Environment

Fictional local Task Tracker build demo-0.1; record your real browser and operating-system versions when testing.

Preconditions

Open the Create task screen with an empty task list.

Steps

1. Enter three spaces in Title. 2. Select Save once. 3. Inspect the task list.

Expected

A required-title error appears and the task count remains zero.

Actual, in this fictional example

The form reports success and a blank-looking task appears in the list.

Impact and suggested severity

Invalid tasks clutter the list and cannot be identified by title. Suggested severity: Medium. Agree on severity definitions with the team.

Priority

To triage. Release urgency depends on context; severity alone does not determine it.

Evidence and retest

Attach your actual screenshot or recording, reproduction frequency and linked test case. Leave fix version and retest results blank until verified.

Useful evidence shows the input and the outcome without exposing passwords, tokens or real customer records. Report only issues you can substantiate. If every test passes, explain that result and the limits of your coverage rather than inventing a defect.

4. Build a small API testing project

Use a local API you build, or a practice API whose documented contract permits the exercise. The endpoints below describe a proposed contract for your local task tracker; they are not public TechRasta endpoints. Implement them before running the checks, or adapt the template to your chosen API’s actual documentation.

For this exercise, POST accepts JSON with a title field. A successful response has the shape {"id":"task-123","title":"Prepare QA portfolio"}. IDs are generated by your implementation; save the returned ID instead of hardcoding this example. Error responses have the shape {"error":"Title is required"}; check a meaningful non-empty message without assuming that exact wording.

1. Set a local base URL, such as http://localhost:3001, and document how to start and reset the API.
2. Send GET /tasks and record the starting count. Create a task with a unique synthetic title and save the returned ID.
3. Retrieve that ID and compare its fields with the creation response.
4. Run the invalid-input checks individually. Compare the list count before and after each rejected request so a 400 response cannot hide a saved invalid record.
5. Choose an ID absent from your local fixture and verify the missing-task response.
6. Export your request collection without credentials. Record the run date, environment, results and any defects. Reset your local data and confirm the collection can be repeated.

For Postman, put assertions in Scripts → Post-response. A starter assertion for a valid creation request is:

pm.test("Task is created with the expected title", function () {
  pm.response.to.have.status(201);
  pm.expect(pm.response.headers.get("Content-Type")).to.include("application/json");
  const task = pm.response.json();
  pm.expect(task.id).to.be.a("string").and.not.empty;
  pm.expect(task.title).to.eql("Prepare QA portfolio");
  pm.collectionVariables.set("taskId", task.id);
});

Send {"title":"Prepare QA portfolio"} for that assertion, and use the saved taskId in your retrieval request. This snippet checks creation only. Add separate retrieval, rejection and persistence checks from the contract. The official Postman testing documentation explains how these assertions run.

5. Automate a few important browser checks

Once the manual cases are stable, automate valid creation, whitespace rejection and one boundary case if automation matches your target role. Keep each test independent with its own data or reset step. Assert visible outcomes and saved data where available. Avoid using a fixed delay as proof of success. Playwright’s assertion guide explains assertions that wait for the expected UI state.

Publish the setup command, selected tests and a real run result. Document any blocked checks or known limitations. A small suite you can explain is enough to start discussing design choices; there is no universal test-count requirement for a fresher portfolio.

6. Package the evidence for an application

A reviewer should be able to find these items from the repository’s README:

• Scope and contract: what the application should do, the risks you chose and what you excluded.
• Test cases: the completed template with actual results and evidence from your execution.
• Defect records: genuine reproducible findings, with retest results where a fix exists.
• API collection: requests, assertions, synthetic fixtures and setup instructions.
• Automation: source and a reproducible command if you included it.
• Reflection: what you missed, what remains uncertain and what you would test next.

Describe the work accurately on your résumé. For example, after completing it: “Designed boundary and validation tests for a local task tracker; documented API checks and reproducible results.” Add tool names and counts only when your repository supports them. Keep fictional teaching examples separate from executed project evidence.

Use our QA jobs in India guide to compare manual testing, automation and SDET responsibilities. If you are choosing your first role, read the fresher IT application plan. To prioritise the next missing skill, work through the skill-gap analysis guide.

Common questions

Can I make a QA portfolio without work experience?

Yes. Use personal projects and permitted practice environments, and label them as such. Explain your own contribution and show evidence you can discuss. Each employer sets its eligibility requirements.

Do I need to find a bug?

No. A portfolio can demonstrate thoughtful coverage and accurate execution even when you find no defect. Never present the fictional bug in this guide as your own discovery.

Do I need both Postman and Playwright?

No. Start with test design and reporting, then choose tools that match your target openings. API and browser testing cover different behaviours. A tool list alone does not show testing judgement.

Can I edit the templates in Excel or Google Sheets?

Yes. Open the workbook in Excel, or import it into Google Sheets. The individual CSV downloads contain plain headers and blank entry rows. Keep an unchanged copy if you want to reuse the template for another project.