Work Samples
Work Samples & QA Case Studies
Anonymised-style examples showing how I test product flows, APIs, localization and release risk.
Honest proof format
Realistic examples, not fake client stories
These are illustrative QA scenarios based on realistic product problems. They show how I test, report and think through release risk without using client names, fake logos or made-up results.
Featured sample cases
Each example targets a different kind of QA support and shows how product context turns into practical testing.
QA Testing
Security setup loses form state after app switch
A user enters a password, opens an authenticator app, returns to the product, and the form state is gone.
Open case
API Testing
API returns the wrong status for invalid data
The UI shows one problem, the API returns another, and developers need the exact request and response.
Open case
QA Testing
Search filters disappear after redirect
A marketplace search sends users to the results page, but selected filters are lost or replaced by defaults.
Open case
API Testing
Duplicate payment request creates a stuck state
A retry creates a conflict, but the user cannot tell whether to wait, retry or contact support.
Open case
Localization QA
Translated flow breaks in real UI context
Translation files exist, but the actual product still shows missing strings, long labels and inconsistent terms.
Open case
Product Quality Review
The flow works, but users are left unsure
A demo path technically works, but weak feedback and unclear states make the product feel risky.
Open case
QA Testing
Security setup loses form state after authenticator app switch
A fintech-style product adds a security step where users enter a payment password and fetch a code from an authenticator app before finishing setup.
Timeline case: the issue appears only after leaving and returning to the product.
Problem
When the user leaves the product to open the authenticator app and then returns, the modal sometimes reloads and clears what was entered.
QA role
I test the full interruption flow, not only the form itself: app switching, browser return, viewport changes, refresh, back navigation and session timing.
Verification
The retest repeats the same app-switching path and checks that the step resumes safely or expires with a clear message.
QA approach
- ✓ Run the setup flow on desktop and mobile browsers.
- ✓ Switch between the product and authenticator app several times.
- ✓ Change viewport size and orientation during the same modal step.
- ✓ Check whether the UI state resets while the session remains valid.
- ✓ Record the exact conditions where the reset is reproducible.
Example findings or risks
- — The password field reset after returning from the authenticator app on mobile.
- — The modal stayed on the same step, so the reset was easy to miss at first.
- — A layout change during the flow increased the chance of the reset.
Final QA output
The report includes reproduction steps, affected devices, likely trigger conditions, video evidence and a retest checklist for the fixed flow.
Copyable sample note
Title: Security setup resets after authenticator app switch Environment: Mobile browser Authenticator app switch Security setup modal Steps: 1. Open security setup 2. Enter payment password 3. Open authenticator app to fetch code 4. Return to the product tab Actual: The modal returns to the same step but clears the entered password. Expected: The step should keep the entered state, or clearly explain that the step expired. Impact: Users can get stuck during a security-sensitive action and may retry unnecessarily.
API Testing
API returns server error for invalid client input
An API-driven booking flow adds a new endpoint for creating and updating reservations.
Request/response case: backend behaviour is tested directly.
QA approach
- ✓ Send malformed, empty and boundary-value payloads.
- ✓ Test missing required fields and null values.
- ✓ Compare direct API responses with the frontend error state.
- ✓ Check whether user role or auth state changes the result.
- ✓ Document the exact request and response for developers.
Example findings or risks
- — Missing required data returned a generic 500 response.
- — The UI displayed a retry message even though the user input was invalid.
- — One role received a permission error while another got the same request accepted.
Final QA output
The report includes request payloads, responses, expected status handling, UI/API mismatch notes and a focused retest set.
Copyable sample note
Request:
POST /api/v1/bookings
{
"date": null,
"slotId": "pm-481",
"customerEmail": "name@example.com"
}
Actual response:
500 Internal Server Error
{
"message": "Unexpected error"
}
Expected response:
422 Unprocessable Content
{
"errors": {
"date": "Date is required"
}
}
Frontend behaviour:
The UI shows a generic retry message, which makes invalid input look like server instability.QA Testing
Marketplace search filters disappear after redirect
A marketplace homepage search sends users into a filtered offers page. The search includes currency, amount, payment method and offer direction.
Flow-state case: the bug is visible only after moving between pages.
Test full and partial filter combinations from the homepage.
Compare user-selected values against platform defaults.
Check URL parameters and visible filter state after redirect.
Repeat with back navigation, refresh and mobile layout.
Separate expected default behaviour from user-selected override.
QA approach
- ✓ Test full and partial filter combinations from the homepage.
- ✓ Compare user-selected values against platform defaults.
- ✓ Check URL parameters and visible filter state after redirect.
- ✓ Repeat with back navigation, refresh and mobile layout.
- ✓ Separate expected default behaviour from user-selected override.
Example findings or risks
- — A selected currency was replaced by the default currency on the results page.
- — Amount persisted, but payment method did not in one partial-filter scenario.
- — Back navigation restored the homepage state but not the same result state.
Final QA output
The report includes a scenario matrix, actual vs expected filter state, affected query parameters and product impact.
Copyable sample note
Scenario: Homepage search to offers page Input on homepage: Currency: EUR Amount: 1500 Payment method: Bank transfer Direction: Buy Actual on results page: Currency resets to default Amount remains 1500 Payment method is missing Expected: All manually selected filters should persist into the results query and visible filter state.
API Testing
Duplicate payment request leaves invoice flow in a stuck state
A payment flow adds a retry path so users can try again after a failed or expired request.
Risk-review case: payment states must be clear even when something fails.
Risk signal
The duplicate request returned a conflict while the UI still showed the original request as pending.
Risk signal
Refreshing before retry changed the visible state but not the underlying conflict.
Risk signal
The user-facing error did not say whether to wait, retry or contact support.
QA approach
- ✓ Trigger retry from the UI and through direct API calls.
- ✓ Check how duplicate invoice or request IDs are handled.
- ✓ Compare backend state with the visible UI state.
- ✓ Test refresh, timeout and double-submit scenarios.
- ✓ Identify whether the behaviour belongs to frontend, backend or a third-party dependency.
Example findings or risks
- — The duplicate request returned a conflict while the UI still showed the original request as pending.
- — Refreshing before retry changed the visible state but not the underlying conflict.
- — The user-facing error did not say whether to wait, retry or contact support.
Final QA output
The report includes the conflict path, affected states, probable ownership, user impact and safer error-handling recommendations.
Copyable sample note
Observed: Second payment request returns a conflict while the original invoice remains visible as pending. User-facing problem: The user cannot tell whether to wait, retry, cancel or contact support. Recommendation: Point the user back to the existing in-progress request, or explain that a duplicate request cannot be created yet.
Localization QA
Translated checkout looks complete in files but breaks in the real flow
A multilingual web app prepares a translated checkout and account flow with updated labels, modals and helper text.
Localization case: the translation has to work inside the real product.
Before QA
The translation files are present, but the live UI still shows missing strings, long labels, broken placeholders and inconsistent terms.
After review
The retest checks the visible translated flow and shared components in every affected place.
QA approach
- ✓ Run the full translated flow from start to finish.
- ✓ Check repeated components, modals, buttons and validation messages.
- ✓ Test mobile layout with longer translated strings.
- ✓ Group shared-component issues so developers do not get duplicate noise.
- ✓ Record current text, expected text and screenshot context.
Example findings or risks
- — One modal still displayed fallback English text.
- — A long translated CTA wrapped on mobile and pushed key information below the fold.
- — The same product term used two different translations across the flow.
Final QA output
The report includes findings grouped by page and component, screenshots, current text, expected text and retest focus.
Copyable sample note
Page: Checkout → Delivery step Current: "Continue with shipping" remains in English inside the Norwegian flow. Expected: Use the approved Norwegian term already used on the confirmation screen. Component note: This looks like a shared button label. Fix once, then retest both checkout and confirmation.
Product Quality Review
The flow works, but the release still feels risky
A SaaS dashboard is preparing for a client demo. The main feature path is built, but the team wants an outside review before showing it to stakeholders.
Product-quality case: working software still needs clear feedback.
Risk signal
A successful save had no visible confirmation.
Risk signal
A loading state looked close to a frozen page during the demo path.
Risk signal
An error message explained the failure but not what the user should do next.
QA approach
- ✓ Walk through the intended demo path end to end.
- ✓ Check success, loading, empty and error states.
- ✓ Look for places where a user might ask: did that work?
- ✓ Separate isolated bugs from wider product-quality risk.
- ✓ Summarise the findings in product language, not only defect language.
Example findings or risks
- — A successful save had no visible confirmation.
- — A loading state looked close to a frozen page during the demo path.
- — An error message explained the failure but not what the user should do next.
Final QA output
The output is a short quality memo with priority findings, recommended wording/state improvements and a focused retest list.
Copyable sample note
Observation: The action succeeds, but the product does not confirm success clearly enough. Why it matters: A quiet success state creates uncertainty and invites repeated clicks or support questions. Recommendation: Add an immediate confirmation state with a clear next action. Keep it visible long enough for the user to notice what changed.
What a useful QA report includes
A useful report is not only a list of defects. It gives developers enough evidence to fix and gives product teams enough context to decide.
Want this kind of QA check for your product?
Send the product context, release goal and what feels risky. I’ll help define a focused testing scope.