Skip to testing case studies
QAFactory / OUR CLIENT CASE STUDIES

Testing case studies.
See how we contributed to product success.

See what we tested, the defects we investigated, and the value we contributed. Review our previous client work, then explore what we can bring to your product.

EXECUTED REFERENCE PROJECT / NOT A CLIENT ENGAGEMENT

Inspect the cases. Follow every result.

We documented and ran a checkout test suite against a controlled reference application. Open the case records, inspect the captured failure, read the scripts, and review the release decision.

Reference Checkout · Controlled reference project, not client work. The saved-card failure was deliberately seeded to demonstrate defect detection and reporting. These results do not represent your selected industry or a previous client engagement.

12Test cases documented
12Automation scripts
11Passed
1Failed
91.7%Pass rate
1Defects documented

Run REF-RUN-20261021110526439
Environment Chrome Chrome/155.0.8059.85 · Windows_NT 10.0.26200 x64

Executed 12 of 12 cases · Blocked 0 · Not run 0
Pass rate 11 passed ÷ 12 executed × 100 = 91.7%. No retry attempts are counted as extra cases.

EXECUTION WORKBOOK / 12 DOCUMENTED CASES

Test case sheet

Select a row to inspect preconditions, test data, steps, expected results, and the observed result.

Download filled workbook ↗
Recorded results from REF-RUN-20261021110526439
Case IDTest caseResultDefect
Valid new-card checkoutpassed—
Empty-cart lower boundarypassed—
Maximum-stock boundarypassed—
Quantity above available stockpassed—
Required shipping addresspassed—
Postal-code length boundarypassed—
Read-only role cannot orderpassed—
Missing payment cardpassed—
Invalid payment-card checksumpassed—
Saved-card checkout regressionfailedREF-BUG-001
Duplicate request is idempotentpassed—
Mobile keyboard checkoutpassed—
REF-010 / EXECUTED TEST CASE

Saved-card checkout regression

failed
Preconditions
Controlled reference app build reference-checkout-1.0.0 is running locally. Order state is reset; five reference units are available. Only reference product/address/payment fixtures are used.
Test data
{"role":"shopper","quantity":"1","address":"10 Reference Lane","postcode":"10001","payment":"saved","card":"4242424242424242"}
Linked defects
REF-BUG-001
Steps executed
  1. Open the reference checkout with a fresh order state.
  2. Set checkout fields to the documented inputs.
  3. Click Place test order.
  4. Check the HTTP response, visible message, and server order count.
Expected result

A valid saved test card should authorize and create an order. · HTTP 201 · Expected message: Order confirmed · Expected orders: 1

Observed result

HTTP 503 · Saved card authorization failed. The order was not placed. · Observed orders: 0 · Requests: 1

Preview the filled spreadsheet

Rendered directly from the downloadable workbook: calculated execution totals and the first three documented cases. The workbook contains all 12 cases, recorded observations, and the linked defect.

Filled workbook summary showing 12 executed, 11 passed, one failed, and a 91.7 percent pass rate for the controlled reference runWorkbook case-detail cells with preconditions, steps, expected and observed results for REF-001 through REF-003

Metric definitions: executed = passed + failed; pass rate = passed ÷ executed. Test and defect monitoring follows the categories described in ISTQB CTFL §5.3.1. Issue fields follow Atlassian’s bug-report guidance. This is a documentation approach, not a certification.

CLIENT CASE STUDY

What we contributed.

SAAS / CLIENT PROJECT

B2B SaaS Release Confidence Overhaul

B2B SaaS platform

01 / WHAT WE TESTED & DELIVERED

We turned critical workflows into maintained regression coverage.

We mapped core journeys, roles, integrations, and failure paths. We investigated failed checks and gave the team confirmed defects and a release recommendation.

  • Test cases & coverageWe mapped the workflows and failure paths that mattered to the release.
  • Bug reports & evidenceWe reported confirmed defects with reproduction steps, screenshots, and logs.
  • Release recommendationsWe brought execution evidence and confirmed findings to the release decision.
QAFACTORY / PROJECT DELIVERABLESSaaS
PUBLISHED PROJECT SUMMARY

Test cases

Coverage we mapped and maintained

Test coverageWhat we did
Core user workflowsPrioritized by customer impact and release risk.
Roles & permissionsIncluded in release-critical regression coverage.
Integrations & failure pathsMaintained as the product changed.

Summary from the published case study. Original client execution files are not included here.

02 / OUR APPROACH, TECHNOLOGY & TOOLS

We kept the tests current—and investigated the failures.

An embedded QA engineer maintained selectors, test data, and scenarios. Manual and exploratory testing added coverage beyond the automated checks.

We owned the investigation and maintenance, so the client received reviewed findings and a clear next step.

WORKSPACE / TOOL

QAFactory.ai

We shared runs, confirmed defects, and release summaries in one workspace.

AUTOMATION / DELIVERY

CI/CD-gated regression

We maintained selectors, test data, and scenarios as the product changed.

TESTING APPROACH

Manual + exploratory

We investigated automated failures and checked release-critical UI behavior.

03 / THE VALUE WE CONTRIBUTED

We improved the release signal and reduced developer triage.

Our contribution combined maintained coverage, investigated defects, and accountable QA ownership.

Clearer regression signal

Proactive maintenance reduced noisy failures.

Less developer triage

QA ownership took recurring verification off the development team.

Defects caught in staging

Exploratory testing exposed critical UI defects before production.

04 / WHAT WE CAN CONTRIBUTE TO YOUR PRODUCT

Your product. Our next contribution.

Start with a focused review of your critical journeys. We’ll agree the scope, access, and timing with you before work begins.

FOR YOUR SAAS PRODUCT

Keep teams working across roles, workspaces, and frequent releases.

  • Invitation, onboarding, and workspace switching
  • Role changes and cross-tenant record access
  • Shared edits, notifications, and integration recovery

You receive: prioritized defects with reproduction steps and available screenshots or logs, a coverage summary, and recommended next actions.

48-HOUR QA AUDITFrom $299

Pay after you’re satisfied.

Start a 48-hour QA Audit Discuss your product and confirm your audit scope on a call.
Review our test case, bug report & release document formats

These editable working templates show how we organize testing. They are not completed client records.

See how we could contribute to your project.

Book a live walkthrough of our published client projects. We’ll discuss the approaches relevant to your product and where your QA effort could have the most impact.

Book a project walkthrough
YOUR NEXT STEP

Let’s walk through your project.

Choose a date and time below. We’ll discuss your product, review relevant QA approaches, and agree how a focused QA audit could help your team. A call is booked only after you complete the calendar’s confirmation.

30-minute call
Calendar not loading? Open the booking page (opens in a new tab)