30 days of Ecommerce Testing Day 10

(Ulf) #1

“An ecommerce system has been launched, you have to do a smoke test. Share what you would test”

My opinion: browser-compatibility. Is the website correct displayed, if not: will i get an error Message or a forwarding? Crashes the browser?

(Tomorrow we have bank holiday in Germany, so this post published today )

(Mike) #2

I’ve written about smoke testing and using personas here

(Anthony) #3

For smoke test on a newly launched ecommerce system, I can think of –

  • Purchase items with different quantities from different product/ service categories. All products and quantities chosen should be recorded separately

  • Go to the cart page, change the quantity. Record the quantity change

  • Perform check out

  • Validate if the checkout workflow is correctly performed by –

    • Whether I can make payment with the correct amount shown
    • The product quantities shown is correct
    • The correctness of notification email, including estimated arrival time, shipping address etc.

The goal for this smoke test is to figure out if there is any defect that prevents users from using the page.

Thanks,
Anthony

(Magda) #4

My ideas for smoke tests of an ecommerce platform would be:

Checking if users can access the platform at all:

  • Logging in
  • Registering as a new customer
  • if applicable, adding items to cart and checkout as guest (as part of checking the cart and checkout functionalities)

Checking if users can access product information and put products in their cart:

  • Searching for a product, including checking that the data in the result list is consistent with the product page
  • Browsing for a product
  • Adding a product to cart, checking that data in cart (e.g. price) is consistent with the product page (as stated above, also when not logged in, if applicable)

Checking if users can make changes to their cart:

  • Removing a product from cart
  • Changing the quantity of products in cart

Checking if users can place and manage orders:

  • Checking out with different payment methods (also when not logged in, if applicable)
    – includes: The order being registered properly in the backend
    – includes: The customer receiving appropriate feedback (e.g. e-mail or in-app receipt)
  • Browsing own orders
  • Cancelling an order (also when not logged in, if applicable)
    – includes: The cancellation being registered properly in the backend
    – includes: The customer receiving appropriate feedback (e.g. e-mail or in-app receipt)

Checking delivery:

  • For a digital good/service, the customer being able to access it upon payment (if applicable)

Checking documentation:

  • Help being available (e.g. FAQ on shipping and returns, size table for apparel)
  • Legally required documents being available (e.g. contact data, privacy policy)

Checking product management:

  • Adding a product to the catalogue/inventory
  • Editing a product’s data

Now off to read what fellow challenge participants have blogged!

(David) #5

@maos, @ceedubsnz, @ulfh and @phlai really have it covered!

One thing I didn’t see mentioned explicitly, but which is triggered by Mike’s persona’s, is mobile testing! So let’s take everything on his or Magda’s list, and make sure we test it out not only on multiple browsers, but on some handheld devices as well.

Also, since I work in payments, I want to mention that @maos has some really good points about payment methods. We usually test to make sure all four major card brands are working (Visa, AMEX, Mastercard, Discover) as well as debit (though that doesn’t typically apply to online purchases) and gift cards, which might.

-Dave K

(Divya) #6

Here the area which i would smoke test for an e-commerce system which is launched

Homepage
Categories
All Navigations
Place an order, view cart page, checkout
Mail transactions
Checkout by all modes of payment
Save a card and make payment for rest of the transactions
Deals, discounts and coupons
Try Guest user and signed in user transactions to complete checkout
Sign up a new user and try forgot password, remember me
Filters in all pages
Search and results
Recommendations
Recently viewed items
Login, logout
Leave the items in cart, later delete them, later checkout them
Few items - checkout
Add to wishlist/favorites
Cancel transaction at any point - payment should not be deducted
Browser compatibility
Mobile app testing
Help pages/FAQ’s
contact us/Chat(if available)
Using keyboard and mouse for selection of items and in cart page

(Ulf) #7

Hi dave, that’s what i meant.
There’s no sense to continue testing if the site isn’t accessible from a defined set of browsers/handhelds.
For deeper smoketests i agree with the other suggestions.

Ulf

(Divya) #8

well explained pesonas

(Heather) #9

Our friends joining in on Twitter:

(Dave) #10

Aside from the answers above, a complex piece of functionality that is worth smoke testing is the discounting system. A lot of platforms offer robust discounts depending on certain conditions to be met. I’d set up smoke tests to cover these combinations of scenarios. Here’s a list of some examples:

  • Free shipping when cart is over $50
  • 10% off items in Category A
  • 15% off when using a promo code from a generated list
  • Buy Product A, get Product B at 10% off
  • Discounts that can only be used once per user account
  • Discounts that can or cannot be stacked
  • Discounts that are applied automatically(without a discount code)

Another thing to test is tax calculation. Sometimes the tax rates are imported into the system, sometimes a third party service is used. I’ve experienced these services go down, which either results in the checkout completely breaking, or tax not being added at all.

These two pieces are important to have coverage for, as the business could lose a lot of money/customers if there are bugs present.

(Luke) #11

good summary and it looks like good coverage for smoke test

(Kris) #12

These are good answers, but I most agree with @phlai answers. Smoke Tests need to be quick and to the point; just testing basic functionality to know if a release has been successful or not.

(Chris) #13

In order not to repeat the flow, let’s look as a request/response checklist
My smokes would definitely include CRUD (Create, Read, Update, Delete) operations for:

  • User (andles registration, login, permissions, password change etc.)
  • Basket (along with basket persistance between logged sessions)
  • Order (checkout and checkout-basket switching, order confirmation, order history)
(Quang Le) #14

Day 10: An e-commerce system has been launched, you have to do a smoke test. Share what you would test

My experience in e-commerce project smoke test:

  1. Users information compare with database or admin sites
  2. Access to a product by clicking on categories…
  3. Searching products, access to product details page by searching
  4. Products sort and paging depending on configuration in admin site or not
  5. Checkout process: the process when a client checkout an order (verify UI all pages of process (home page, product details page, basket page, checkout steps, carousel…), functions of this process (promotion, pricing, taxing, shipping cost, shipping function…)
  6. Checkout with guest, checkout with login, checkout with same address in billing and shipping, checkout with some kinds of promotions…
  7. Checkout orders should be created in database or in admin sites or a third-party after client submitted the orders, compare information in receipts online with the database or a third-party after client submitted the orders
  8. Check email confirmation should be send immediately after client submitted the orders (order code, products, tax, ship, price, promotion… and all information in email