Home Β· A blog about testing Β·
QA portfolio without experience: a complete example and template
A useful QA portfolio lets a reviewer inspect how you understand a product, choose checks, record evidence and communicate risk. Below is one complete training-project example, followed by the decisions behind it. It is not presented as paid experience.
| Artefact | Keep it small | What a reviewer should learn |
|---|---|---|
| Product brief | One page | You understand users, rules and risk |
| Checklist and cases | 10β20 checks, 3β5 cases | You select coverage and expected results |
| Bug reports | 2β3 real reproducible findings | You investigate and communicate precisely |
| API and SQL | One connected workflow | You verify contracts and stored state |
| Automation | 3β8 stable checks | You write maintainable code for a justified scope |
| Test summary | One page | You can report confidence and residual risk |
Complete example: one checkout investigation
This fictional training repository follows one risk from the interface to the API and stored state. The point is not the number of files; it is the traceable chain from a product rule to an observed result.
qa-bookshop-portfolio/ βββ README.md βββ docs/ β βββ scope-and-risks.md β βββ checkout-checklist.md β βββ test-cases.md β βββ bug-reports/BUG-001-empty-cart-order.md βββ api/bookshop.postman_collection.json βββ sql/order-integrity.sql βββ tests/checkout.spec.ts βββ reports/test-summary.md
Product: QA Job Simulator bookshop sandbox Scope: empty-cart checkout and order persistence Risk: an invalid empty order is persisted and enters order processing Permission: owned training environment Evidence: checklist -> API request -> SQL check -> BUG-001 Result: POST /orders returned 201 and stored total=0 Limits: no load, security or third-party production testing
BUG-001 Β· POST /orders creates an order for an empty cart
Environment: training sandbox, build 2026.10.25
Precondition: authenticated buyer; cart is empty
Steps: send POST /orders with the documented test account
Requirement: AC-ORD-04 requires at least one cart item
Steps: POST /qa-lab/api/v1/orders with {}; then GET /orders
Expected: 422; no order is returned or persisted
Actual: 201; order_id=8412; items_count=0; total=0
Reproducibility: 3/3 on build 2026.10.25
Evidence: redacted HTTP, correlation_id=demo-8412, read-only SQL
What this example proves
The requirement defined the oracle, the POST and follow-up GET showed the external behaviour, and an authorised read-only query confirmed the stored row. The downloadable pack contains every referenced file. The conclusion stays narrow: this workflow failed on this build; payment, stock and unrelated behaviour were not tested.
1. Define what the portfolio must prove
A recruiter may scan for role fit, while a QA lead looks for reasoning and communication. Design for both: the opening screen names the target role, product under test, scope and strongest evidence; deeper links show how you arrived at the conclusion. Do not make the reviewer reverse-engineer a drive full of files.
The portfolio should answer four questions quickly: what did you test, which risk did you prioritise, what did you observe and how can another person verify it? Certificates and tool logos may add context, but they do not answer those questions. Evidence needs a product rule, action, expected result and outcome.
- Target role and product context are visible first.
- Every artefact has a one-sentence purpose.
- Links open without requesting access.
- Dates and training context are stated honestly.
2. Choose a legal, bounded product to test
Use a training sandbox, your own application, an open-source project with contributor guidance or a public demo that permits ordinary use. Do not perform load, security or destructive testing on a third-party production service without explicit permission. A portfolio must show judgement, including where testing should stop.
Select one workflow with visible business rules and several layers: registration, catalogue and checkout, booking, subscription or account permissions. Define the environment and version, test accounts, data ownership and exclusions. A narrow scope supports deeper reasoning than a claim that you tested an entire large website.
Portfolio checkpoint
Write a scope statement with product, build, workflow, included layers, excluded testing, data source and permission basis. Keep it to eight lines.
3. Show test design, not a pile of documents
Start with risks and a feature model, then create a concise checklist. Add detailed cases only for critical or easily misunderstood paths. Each case should contain preconditions, exact data, steps, expected result and relevant side effects. Include positive, negative and state-based behaviour rather than repeating field validation twenty times.
Make selection visible: label which technique shaped a group of checks and what you deliberately did not cover. A reviewer learns more from five justified values around a boundary than from fifty random inputs. When requirements are unclear, record the question and competing expectations instead of manufacturing certainty.
4. Include real findings with reproducible evidence
A good portfolio bug report states environment, preconditions, exact steps and data, expected and actual results, frequency and attachments. Use a correlation id, redacted request or short recording when it materially helps. Never include passwords, live tokens, personal data or private company information.
Do not invent defects to make the project look productive. If the product is intentionally stable, document an investigation that confirmed the rule or a requirement ambiguity that you resolved. One subtle state or integration defect with strong evidence is more credible than ten cosmetic observations labelled critical.
Portfolio checkpoint
Review two of your reports against this test: can a stranger reproduce them, identify the broken rule and see the evidence without asking you for secrets or context?
5. Connect UI, API and data evidence
A strong technical example follows one business action across layers. Show the UI input, the HTTP request and response, and the final state obtained through a public GET or approved read-only SQL. Explain which layer each check covers and why one green response does not prove every side effect.
Keep Postman collections, SQL and logs readable. Use environment variables with example values, remove secrets, format queries and include expected results. If the repository cannot run without your private account, it is not reviewable evidence. Provide fixtures or screenshots only when they clarify, not as a substitute for instructions.
6. Add a small automation project only if it is maintainable
Automation is optional for a manual role and valuable when the vacancy asks for it. Choose a handful of stable checks, use clear locators and assertions, isolate data and make one command run the suite. Include setup, tool versions, architecture, test scope and a sample report in the README.
Generated code is a draft, not proof of skill. Remove duplication, explain fixtures and waits, and make failures diagnostic through traces or logs. A reviewer should be able to clone the repository, install dependencies and run the tests without discovering hidden credentials or a machine-specific path.
Portfolio checkpoint
Give your repository to another person with only the README. Record every missing setup step, flaky result and unclear assertion, then fix the guide and suite.
7. Publish a two-minute review path
Use a GitHub repository, a simple site or both. The root README should provide the product context, scope, environment, evidence map, main findings, limitations and how to run any code. Put the strongest artefact first. Deep folder nesting and decorative dashboards slow down a reviewer who has limited time.
Before adding the link to a CV, test it in an incognito window and on a phone. Check permissions, broken links, filenames, language and redaction. Ask a QA practitioner to spend exactly two minutes on it and describe what they believe you can do; revise the path when their answer differs from your intended signal.
- README opens with context and outcome.
- Artefacts use consistent names and dates.
- Secrets and personal data are absent from history.
- Every screenshot has a reason and readable scale.
- The repository runs from documented commands.
QA portfolio: common questions
Do manual QA engineers need a portfolio?
It is not a universal hiring requirement. For a beginner, a concise evidence set can still make practical skills easier to inspect. Tailor the effort to the target market and do not delay real applications indefinitely to perfect a site.
Can I put practice projects under work experience?
Label them as projects, training or independent practice unless they were actual employment or contracted work. Honest context protects trust and still allows you to explain the technical decisions and results.
Should the portfolio include every document I created?
No. Curate the strongest small set and archive weak or repetitive drafts. The goal is fast evaluation of your current work, not proof that you completed every exercise.
Can I use AI to create portfolio artefacts?
AI can help review wording or generate alternatives, but you must verify every rule, result and line of code. Disclose material assistance when relevant and never submit generated evidence for tests you did not execute.
A convincing beginner portfolio is not a claim that you already held the job. It is a short, inspectable record of how you approach the work: context, risk, check, evidence, conclusion and honest limits.