A manual testing project on a real application is the best proof of skill for freshers, and OpenCart, a free open-source e-commerce platform with a public demo store, is ideal for it. This guide shows how to run the project end to end and which documents to produce: a requirements summary, test plan, test scenarios, test cases, requirement traceability matrix (RTM), execution report and bug reports, with examples of each that you can extend.
1. Set Up the Application
- Use the public OpenCart demo store, or install OpenCart locally (it runs on PHP and MySQL, for example with XAMPP) so you control the data and can test the admin side safely.
- Create a few test accounts and products. Never test on a real shop you don't own.
2. Understand the Requirements (FRS)
Without an official specification, write a short Functional Requirements Summary from the application itself: one numbered requirement per behaviour. Focus on the customer-facing modules:
| Module | Example requirements |
|---|---|
| Registration | REQ-01 A visitor can register with first name, last name, email, telephone and password. REQ-02 Email must be unique. REQ-03 Password and confirmation must match. REQ-04 The privacy policy must be accepted. |
| Login and account | REQ-05 Registered users can log in with email and password. REQ-06 Forgotten-password emails a reset link. REQ-07 Users can edit account details, address book and password. |
| Search and catalogue | REQ-08 Search by product name, with an option to search descriptions. REQ-09 Results can be sorted and shown as list or grid. |
| Product, cart and wish list | REQ-10 Add to cart with quantity and options. REQ-11 Update and remove cart items. REQ-12 Add products to the wish list (logged-in users). |
| Checkout | REQ-13 Guest and registered checkout. REQ-14 Billing and delivery address, delivery and payment method. REQ-15 Order confirmation and order history. |
| Other | REQ-16 Currency switcher. REQ-17 Product comparison. REQ-18 Newsletter subscription. |
3. Write the Test Plan
| Section | What to write |
|---|---|
| Objective and scope | Functional testing of the customer storefront modules above; admin panel, payment providers and performance out of scope |
| Approach | Requirement-based functional testing, boundary and negative testing, exploratory sessions, cross-browser checks on Chrome, Firefox and Edge |
| Environment | OpenCart version, browsers and OS, test data |
| Entry and exit criteria | Entry: build deployed and smoke test passed. Exit: all planned cases executed, no open critical or high defects, RTM complete |
| Deliverables | Scenarios, test cases, RTM, execution report, bug reports, summary report |
| Risks | Demo data reset by the host, third-party payment not testable, limited time |
See test documentation and planning for each section in detail.
4. Test Scenarios
| ID | Scenario | Req |
|---|---|---|
| TS-01 | Verify registration with valid details | REQ-01 |
| TS-02 | Verify registration is blocked for an already registered email | REQ-02 |
| TS-03 | Verify field validations on the registration form | REQ-01, 03, 04 |
| TS-04 | Verify login with valid and invalid credentials | REQ-05 |
| TS-05 | Verify forgotten-password flow | REQ-06 |
| TS-06 | Verify product search and sorting | REQ-08, 09 |
| TS-07 | Verify add, update and remove in the shopping cart | REQ-10, 11 |
| TS-08 | Verify guest and registered checkout | REQ-13, 14, 15 |
5. Test Cases (Registration Example)
| ID | Title | Steps | Data | Expected result |
|---|---|---|---|---|
| TC-REG-01 | Register with valid details | Open Register; fill all fields; accept privacy policy; click Continue | Unique email, valid phone, password Test@1234 | Account created; success page shown; user logged in |
| TC-REG-02 | Existing email | Register with an email already used | Existing email | Warning that the email is already registered; no account created |
| TC-REG-03 | Mandatory fields empty | Click Continue with all fields empty | None | An error is shown under every mandatory field |
| TC-REG-04 | Invalid email format | Enter asha@ and submit | Invalid email | Email validation error |
| TC-REG-05 | Password mismatch | Enter different password and confirmation | Test@1234 / Test@12345 | Confirmation mismatch error |
| TC-REG-06 | Privacy policy not accepted | Submit without ticking the checkbox | Valid data | Warning to accept the privacy policy |
| TC-REG-07 | Field length boundaries | Enter first name of 1, 32 and 33 characters | Boundary values | 1–32 accepted, 33 rejected (per the form's rule) |
| TC-REG-08 | Leading and trailing spaces | Enter email with spaces around it | " asha@example.com " | Spaces trimmed or a clear validation error, consistently |
Write cases the same way for every scenario, using boundary value analysis and equivalence partitioning.
6. Requirement Traceability Matrix
| Requirement | Scenario | Test cases | Status | Defects |
|---|---|---|---|---|
| REQ-01 | TS-01, TS-03 | TC-REG-01, 03, 04, 07, 08 | Pass | — |
| REQ-02 | TS-02 | TC-REG-02 | Fail | BUG-004 |
| REQ-03 | TS-03 | TC-REG-05 | Pass | — |
7. Execution and Bug Reports
Record each run with date, build, tester, actual result and status (Pass, Fail, Blocked, Not Run). For every failure, log a bug:
| Field | Example |
|---|---|
| ID and title | BUG-004: Registration accepts an existing email when it differs only in letter case |
| Environment | OpenCart demo, Chrome 129, Windows 11 |
| Steps | 1. Register as asha@example.com. 2. Log out. 3. Register again as Asha@Example.com. |
| Expected / actual | Expected: duplicate warning. Actual: second account created (example bug for illustration) |
| Severity / priority | Major / High |
| Evidence | Screenshots of both accounts |
8. Summary Report and Presenting the Project
Finish with a one-page summary: cases planned, executed, passed and failed; defects by severity and status; risks and recommendation. Put all documents in a GitHub repository with a README, and in interviews walk through one scenario from requirement to RTM to bug, which shows you understand the whole testing process. Use the "how would you test" scenarios to extend the project to more modules.
FAQs
Is OpenCart good for a manual testing project?
Yes. It is a free, realistic e-commerce application with registration, search, cart, wish list and checkout, and a public demo, so you can produce every test artifact a real project needs.
What documents should a manual testing project include?
A requirements summary, test plan, test scenarios, test cases, RTM, execution report, bug reports and a test summary report.
