QA Portfolio Project in Sri Lanka: Test a Booking App

A QA portfolio project should show how you identify risk, design useful checks and communicate defects. For a Sri Lankan candidate applying for a first testing role, one well-documented workflow can demonstrate these skills without requiring a large application.

Use an app you own or have permission to test. A fictional appointment-booking app gives you realistic scenarios without touching a live business system.

Define the feature and its rules

Write down the intended behaviour: a user selects a service, chooses an available time, enters contact details and receives confirmation.

Clarify rules before writing tests. Can a user book in the past? What makes a phone number acceptable? Can a slot be booked twice? If the requirements are missing, record questions instead of silently inventing rules.

State which browser or device you used and the version of the application under test.

Prioritise the important risks

Focus first on behaviour that could prevent or misrepresent a booking. Cosmetic differences can be recorded separately.

A risk-based plan is more useful than a long list of checks with no explanation of priority.

Write reproducible defect reports

Include a short title, environment, preconditions, steps, expected result and actual result. Attach a screenshot or recording when it helps explain the issue.

A fictional report might say that selecting a new service leaves the previous service's time selected. Explain exactly which choices reproduce it and what the app saves.

Avoid labels such as “everything is broken.” Describe the observed behaviour and its impact. Severity should reflect the consequence, while priority is a separate decision about when to address it.

Add a small automated check

Choose a stable, important path rather than automating every screen. Playwright's testing guidance recommends testing user-visible behaviour and using resilient locators.

For the booking example, an automated check could fill the required fields, choose a valid time and verify the confirmation. Keep test data independent so one run does not damage another.

Explain what the automation does not cover. Passing one browser test does not establish that payments, security or simultaneous bookings are correct.

Package the portfolio

Include the feature description, test scope, risk table, selected cases, defect reports and the automated check's run instructions.

Write a short summary of findings: what you tested, what passed, what failed and what remains unknown. Use evidence from your actual exercise rather than inventing a defect count.

If the app has no defects in the tested scope, that is acceptable. You can still demonstrate thoughtful coverage and identify areas not assessed.

Do you need an automation framework first?

Begin with requirements, risks and clear manual checks. Automation becomes more valuable when you know which behaviour needs repeatable verification.

Can you test a public website for your portfolio?

Use your own application, an explicitly permitted practice target or written permission. Public availability is not permission for intrusive testing.

How much documentation is enough?

Enough for another person to reproduce your work and understand its limits. A concise set of useful reports is preferable to many repetitive pages.

What should you explain in an interview?

Choose one risk, one test design decision and one defect or uncertainty. Show how the evidence led to your conclusion.

Related guides

• Data Analyst Portfolio in Sri Lanka: Sales Project Guide
• UI UX Portfolio in Sri Lanka: Write a Clear Case Study
• Career Change into IT in Sri Lanka: A 12-Week Plan

Browse the Sri Lanka work and technology guides for more practical application, AI and workplace projects.