TestFolio
Manual test suite for SauceDemo e-commerce app — 48 test cases, 12 bug reports across 5 modules. Covers login, cart, checkout, and search using BVA, EP, and Decision Table techniques in ISTQB format.
The problem
Most QA portfolios show automation scripts. Very few show the thinking that comes before automation — how you plan a test strategy, how you decide what to test, how you write a bug report someone can actually act on.
testfolio is built to show exactly that.
What I tested
SauceDemo is a publicly available demo e-commerce application used widely for QA practice. I chose it because it has real bugs, real edge cases, and behaves like an actual product — not a toy example.
Five modules were in scope: Login and Authentication, User Registration, Product Search and Filter, Shopping Cart, and the Checkout Flow.
How I approached it
I started with a test plan — defining scope, test approach, entry and exit criteria, and risks before writing a single test case. This is how testing works on real teams, and it is something most junior QA portfolios skip.
From there I wrote 48 test cases using three techniques: Boundary Value Analysis for input field limits, Equivalence Partitioning for grouping valid and invalid inputs, and Decision Table Testing for multi-condition logic like login combinations.
What I found
Twelve bugs across all five modules. The most critical one: the checkout flow could be bypassed entirely by navigating directly to the confirmation URL — the system completed an order with no payment details entered. That is a security and business-critical defect.
Severity — Count
- Critical — 2
- High — 4
- Medium — 4
- Low — 2
Every bug report includes a title, severity rating, reproduction steps, expected vs actual result, and environment details — structured so a developer can pick it up and act without asking clarifying questions.
Test execution
48 test cases executed. 36 passed, 10 failed, 2 blocked.
Pass rate: 75%. Release recommendation: not ready — 2 Critical bugs open.
That last line matters. A QA engineer's job is not just to run tests. It is to make a clear call on whether a product is ready to ship. This project practices that judgment.
Tools used
Test management: TestRail structure, Markdown documentation
Bug tracking: Jira format
Browser testing: Chrome, Firefox, Safari — desktop and mobile
Techniques: BVA, Equivalence Partitioning, Decision Table, Exploratory
What I learned
Writing 48 test cases forces you to read requirements carefully. You find gaps — things that are assumed but never specified. That gap-finding is often more valuable than the test execution itself.
The checkout bypass bug (BUG-001) was found during exploratory testing, not scripted testing. That is a good reminder that structured test cases catch known risks, but exploratory sessions catch the things nobody thought to write a test for.