Monark University Students: Testing an E-Commerce Site as an Internship Practice Project

Monark University Students: Testing an E-Commerce Site as an Internship Practice Project

Facebook
Twitter
LinkedIn
WhatsApp
Email

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.

Apply for the free internship

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:

  1. Ask your department or faculty office whether an internship or project regulation exists for your programme, and request the document by name.
  2. Email your coordinator asking if an online internship is accepted for any required training, and keep the reply.
  3. Ask the CDC or placement cell whether it keeps a record of student internships or certificates, and in what format.
  4. Request the current academic calendar from the office so you can fit the 14 days around exams.
  5. If you plan to use a classmate’s project as the test target, get their consent in writing and note it in your report.
  6. 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

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.

Start your free 2-week internship

Web Stories

Scroll to Top