Testing an e-commerce site is one of the best practice projects for a software testing internship, because cart, payment and search combine business rules, data validation and integrations in one small product. Over 14 days you can write about 60 scenarios, run them against a practice shop, log defects properly and score your own work with a rubric. The plan below gives you all of it, ready to copy.
Why a shop site suits a two-week testing internship
Interviewers for QA roles tend to ask about flows everyone understands: add to cart, pay, search. A project on these flows lets you show test design, not just clicking. It also fits a short internship: the scope is bounded, the outputs are concrete (scenario sheet, defect log, summary) and each can be reviewed by a mentor in minutes.
The free two-week online internship from CareerSwami is a natural place to run this project, since it spans 14 days and offers a free offer letter and a free completion certificate after successful completion. The project works equally well on your own as a portfolio piece.
Choosing a safe target site
Never run security-style or high-volume tests against a live business without written permission. Use a site built for practice, or one you run yourself.
- A public demo shop intended for testers (check its terms of use first).
- An open-source shop installed on your laptop, such as a local sample storefront.
- A small project built by a classmate in the Computer Application or ICT faculty, with their consent.
Record the site name, URL, build or date tested, browser and device in your report header. Without it, a defect cannot be reproduced.
Free 2-Week CareerSwami Internship
Online, 14 days, with a free offer letter and a free completion certificate once you finish the work. Check with your college that it fits your requirement before you enrol.
The 14-day plan for the testing project
| Days | Focus | Output |
|---|---|---|
| 1 | Explore the site, list features, note assumptions | Feature map, test scope note |
| 2 | Test strategy: browsers, devices, data, out-of-scope items | One-page test plan |
| 3-4 | Write search scenarios | Search sheet (about 20 cases) |
| 5-6 | Write cart scenarios | Cart sheet (about 22 cases) |
| 7-8 | Write payment and checkout scenarios | Payment sheet (about 20 cases) |
| 9-11 | Execute all scenarios, log defects as found | Execution results, defect log |
| 12 | Retest fixed or disputed items, exploratory session | Updated log, session notes |
| 13 | Self-score with the rubric, fill gaps | Scored rubric |
| 14 | Summary report and portfolio packaging | Final report |
Scenario set for product search
Each row below is a scenario to expand into steps, test data, expected result and actual result. IDs are illustrative labels for your sheet.
| ID | Scenario | Type |
|---|---|---|
| S01 | Search an exact product name; product appears in results | Positive |
| S02 | Search a partial word (“shoe” for “shoes”) | Positive |
| S03 | Search in uppercase, lowercase and mixed case | Equivalence |
| S04 | Search with leading and trailing spaces | Boundary |
| S05 | Search a term with no matching products; clear “no results” message | Negative |
| S06 | Empty search submitted | Negative |
| S07 | Special characters (&, %, quotes) in the query | Negative |
| S08 | Very long query (200+ characters) | Boundary |
| S09 | Script-like text entered as the query is shown as plain text, not executed | Basic security |
| S10 | Common misspelling; check whether suggestions appear | Usability |
| S11 | Filter results by price range, then by brand, then both | Functional |
| S12 | Sort by price low-high and high-low; verify order | Functional |
| S13 | Pagination: move to page 2 and back; filters persist | Functional |
| S14 | Result count shown matches items listed | Data check |
| S15 | Out-of-stock products displayed or labelled correctly | Business rule |
| S16 | Browser back button after opening a product keeps the results | Navigation |
| S17 | Search on a mobile-width screen | Responsive |
| S18 | Search by Hindi or Gujarati text, if the site claims support | Localisation |
| S19 | Autocomplete suggestions open the right product | Functional |
| S20 | Time to show results on a normal connection (note, do not load test) | Observation |
Scenario set for the shopping cart
| ID | Scenario | Type |
|---|---|---|
| C01 | Add one product; cart count and line item are correct | Positive |
| C02 | Add the same product twice; quantity increases, not a duplicate line (or per site rule) | Business rule |
| C03 | Add different products; subtotal equals the sum of line totals | Calculation |
| C04 | Increase quantity with the plus control | Functional |
| C05 | Set quantity to 0; item removed or blocked | Boundary |
| C06 | Set quantity to a negative number or decimal | Negative |
| C07 | Set quantity above available stock; clear message | Boundary |
| C08 | Enter quantity as letters or symbols | Negative |
| C09 | Remove an item; totals recalculate | Functional |
| C10 | Empty the cart; empty-state message and link back to shopping | Usability |
| C11 | Apply a valid coupon; discount shown correctly | Calculation |
| C12 | Apply an invalid, expired or already used coupon | Negative |
| C13 | Apply the same coupon twice | Negative |
| C14 | Tax and shipping lines appear and add up | Calculation |
| C15 | Price change on the product page is reflected in the cart (observe behaviour) | Business rule |
| C16 | Cart persists after page refresh | Persistence |
| C17 | Cart persists after logout and login | Persistence |
| C18 | Guest cart merges with account cart on login | Business rule |
| C19 | Same account open in two tabs; update quantity in one, check the other | Concurrency |
| C20 | Variant selection (size, colour) is kept in the cart | Functional |
| C21 | Rapid double-click on Add to cart | Robustness |
| C22 | Move item to wishlist or save for later, if offered | Functional |
Scenario set for payment and checkout
Use only test or sandbox payment details provided by the practice site. Never enter real card numbers into a site you are not sure about.
| ID | Scenario | Type |
|---|---|---|
| P01 | Complete checkout with a valid test card; order confirmation appears | Positive |
| P02 | Order total at payment equals cart total | Calculation |
| P03 | Card number with too few or too many digits | Boundary |
| P04 | Expired card date | Negative |
| P05 | Wrong CVV format | Negative |
| P06 | Declined test card; clear error, cart retained | Negative |
| P07 | UPI or wallet option, if the site offers it in sandbox mode | Functional |
| P08 | Cash on delivery selection changes the totals or fees as stated | Business rule |
| P09 | Cancel on the payment page; return to cart without a charge | Flow |
| P10 | Browser back during payment; no duplicate order | Robustness |
| P11 | Double-click on Pay now; one order only | Robustness |
| P12 | Refresh the confirmation page; no second order | Robustness |
| P13 | Required address fields left empty | Negative |
| P14 | PIN code with 5 or 7 digits, or letters | Boundary |
| P15 | Phone number validation (length, letters) | Boundary |
| P16 | Order appears in order history with right items and amount | Data check |
| P17 | Confirmation email or message content and amount | Integration |
| P18 | Stock reduces after purchase of the last unit | Business rule |
| P19 | Page is served over HTTPS and card fields are masked | Basic security |
| P20 | Session timeout during checkout; behaviour on resume | Robustness |
Defect log template for the e-commerce project
A defect log is judged on whether a stranger could reproduce the problem. Use one row per defect with these columns.
| Column | What to write |
|---|---|
| Defect ID | D001, D002 and so on |
| Linked scenario | Such as C07 or P11 |
| Title | One line: what fails and where |
| Environment | Browser and version, device, OS, build or date |
| Steps to reproduce | Numbered, starting from a clean state |
| Expected result | What should happen, and why (spec, rule or common sense) |
| Actual result | What happened |
| Severity | Critical, Major, Minor or Trivial (impact on the user) |
| Priority | High, Medium or Low (how soon to fix) |
| Evidence | Screenshot or short screen recording file name |
| Status | New, Retest, Closed, Rejected |
Worked example: turning one failed cart scenario into a defect entry
This example is illustrative; it describes a hypothetical result, not a run against a real site.
Scenario C07 says to set quantity above available stock. Suppose a product shows “Only 3 left”, and you type 10 in the cart quantity box and press Update. The cart accepts 10 and shows a total for 10 units. Checkout is not blocked until the payment step. That is a defect, because the stock rule is enforced too late.
Defect ID: D004
Linked scenario: C07
Title: Cart accepts quantity 10 when only 3 units are in stock
Environment: Chrome (latest), Windows laptop, test date noted
Steps:
1. Open product page showing "Only 3 left".
2. Click Add to cart.
3. In cart, change quantity to 10 and click Update.
Expected: Message limiting quantity to 3; total unchanged.
Actual: Quantity 10 accepted; total recalculated for 10 units.
Severity: Major (customer can reach payment with unavailable stock)
Priority: High
Evidence: D004-cart-quantity.png
Status: New
Notice what makes it strong: a precise title, a clean starting state, an expected result tied to a visible rule, and a severity reasoned from user impact.
Scoring rubric for completeness of your testing project
Score each row from 0 to 4 (0 missing, 1 weak, 2 adequate, 3 good, 4 strong). The maximum is 40.
| Criterion | What a 4 looks like |
|---|---|
| Scope and plan | Features, environments, data and exclusions clearly stated |
| Search coverage | Positive, negative, boundary, filter, sort and usability cases |
| Cart coverage | Quantity limits, coupons, calculations, persistence and variants |
| Payment coverage | Valid and invalid payments, duplicates, cancellation, confirmation |
| Test case quality | Each case has steps, data, expected result; no vague wording |
| Execution record | Every scenario marked pass, fail or blocked with actual result |
| Defect log quality | Reproducible, evidence attached, severity reasoned |
| Non-functional touches | Browser, mobile width, basic security and response observations |
| Traceability | Every defect links to a scenario; every feature has scenarios |
| Summary report | Counts, top risks, what was not tested, and recommendations |
- 34-40: portfolio-ready.
- 26-33: solid; fill the lowest-scoring rows before sharing.
- Below 26: revisit the scenario sheets and defect quality first.
Monark University students: fitting this testing project to your programme
Monark University’s homepage lists 14 faculties, including Information & Communication Technology, Computer Application, Engineering & Technology and Commerce. That spread suits this project: a Computer Application or ICT student can focus on test design and automation later, while a Commerce or Management student can lead on business rules such as coupons, tax and refunds.
The same page shows a CDC section with sub-pages for the placement cell, recruiters, training programs, guest lectures and industry workshops. The placement cell page exists, but its contents should be read directly. Once your project is done, the cell is a sensible place to ask whether a testing portfolio can be shown in training sessions.
Several things are not publicly confirmed in the material available: whether the university has rules on internships or project work, whether an online internship is accepted, whether any credit applies, and which semester break dates apply. The homepage’s Academic Calendar item did not show dates when checked. Treat this project as practice and portfolio work unless your department tells you otherwise in writing.
Verification steps:
- Ask your department or faculty office whether an internship or project regulation exists for your programme, and request the document by name.
- Email your coordinator asking if an online internship is accepted for any required training, and keep the reply.
- Ask the CDC or placement cell whether it keeps a record of student internships or certificates, and in what format.
- Request the current academic calendar from the office so you can fit the 14 days around exams.
- If you plan to use a classmate’s project as the test target, get their consent in writing and note it in your report.
- Ask your faculty mentor if they will review your defect log and rubric score before you share the project externally.
Packaging the finished project for interviews
- Export the scenario sheets and defect log as a single spreadsheet with one tab each.
- Write a one-page summary: scope, number of scenarios, pass/fail/blocked counts, top three defects and what you did not test.
- Attach evidence files with clear names that match defect IDs.
- Keep the rubric score visible with a short note on your weakest area.
- Be ready to explain one defect end to end, from scenario to severity decision.
Frequently Asked Questions
How many test scenarios are enough for an e-commerce testing project?
About 60 well-written scenarios across search, cart and payment is a good target for 14 days. Quality matters more than count: each should have data, steps and an expected result.
Should I test a real online store for my practice project?
No, not without written permission. Use a demo shop built for testers, an open-source store on your laptop, or a classmate’s project with consent.
What is the difference between severity and priority in a defect log?
Severity is the damage a defect does to the user or business. Priority is how soon it should be fixed. A typo on the home page may be low severity but high priority before a launch.
Can I use automation tools for this project?
Yes, once the manual scenarios are written and run. Automating a few stable flows, such as add to cart and search, can be a bonus, but a manual set with a strong defect log is still a complete project.
How do I handle payment testing safely?
Use only sandbox or test card details given by the practice site, and never enter real card or bank details. Note in your report that payments were simulated.
Will this project count towards credit at Monark University?
That is not confirmed in the material available. Ask your department in writing whether any internship or project can count, and which documents they would need.
How do I show this project on a CV?
List it under projects with one line on scope (search, cart, payment), the number of scenarios and defects, and a link to the spreadsheet or summary. Be accurate about the site tested.
What if I find no defects on a well-built site?
Report that honestly, and show coverage instead: execution results, boundary cases tried and exploratory notes. Then add depth with more devices, data combinations and error conditions.
Related Software Testing guides
- Dev Bhoomi Uttarakhand University Students: Git Basics Every Testing Intern Needs
- Guru Kashi University Students: Preparing for a Practical Test Round in Intern Selection
- Dr. B.R. Ambedkar University Agra: Applying for Testing Internships in Small Local Firms
- All Software Testing internship guides
Ready to put this into practice?
Join the free two-week CareerSwami online internship in Software Testing. The internship, the offer letter and the completion certificate are free.















