Category: QA Bite

Testing E-Commerce websites regularly, I often get asked how to test the purchase flow. This is a delicate topic: It is vital for any shop owner that the purchase and payment flow of the shop runs smoothly. But, it involves real money – something alien to QA testing.

So, these are your options:

1. Create a coupon for 100% discount and use this coupon in your test. 
2. Enable Invoice Payment (e.g. WooCommerce->Settings->Checkout->Cash on delivery).
3. Use a stage environment and set your payment provider to sandbox mode (e.g. Paypal or Stripe).
4. Use a real credit card during purchase flow. Refund after the test. This usually leaves you with remaining fees from the payment provider and can hurt your credit score. Make sure to use a separate card and talk to the payment provider that your refunds are part of tests.

Using the first two options, you can test many important steps of your purchase flow, except the payment itself. This is sufficient in most cases. Note:Make sure that the goods purchased are not sent out 🙂 

If you already have a stage environment, option 3. is best. It tests much of the communication with the payment provider. Then, you can go to the payment provider’s website and check if the communication was correct, too.

The real test is option 4. With real money, you can do real testing of production shops. If you have a shop with low volume and your last payment was a few days ago, test using option 4 manually and verify that it’s not a technical issue.

If the same tests are repeated again and again, eventually, the same test cases will no longer find new bugs. 

To overcome this, the test cases need to be regularly reviewed and revised. New tests need to be added to find more defects.

A test in Testup usually checks much more than a single feature, it tests a complete user flow. Therefore, I structure my tests with Tags. Each feature gets a Tag:

Then, on the Project Page you find the a tab “Tags“ which shows which Test has which Tags.

An excellent way to communicate defects or new user stories in the development process is to write tests first. Testup looks at the software the same way as a user would do. Therefore, it is easy to describe what the user should see and experience. 

Create a test that goes to the screen in question. Then, use Tags to describe what the user should see. This way, the Product Owner can easily define the screen that needs to change and the Developer knows what to do. 

In your Ticket system, simply create a ticket for the issue and link the test case URL (something like https://app.testup.io/testcase/1234567) you find in your Browser.

An additional benefit is that the developer can add the new functionality to the Test and hand back the test to the Product Owner for acceptance testing.

If you are in business for a couple of years, you will know about this issue: You introduce a new software to replace an old system. Now, you need to export the data of the old system and import it to the new one. Easy. But, what if there is no import or export functionality of the data you need? Create a Testup test as a robot which does it for you:

I often have the issue that I need to check the same website with different input values. Last time I wanted to check if different product categories in a web shop are displayed properly in the shopping cart. The solution is to use a Google Spreadsheet which contains the different products.

1. Create a Google Spreadsheet and enter the data you need.
2. Share the sheet with a link such that everybody with a link is a viewer.

In you shop test, insert the action NAVIGATE_URL and Paste the link of the Google Sheet into this action and play:

• Use arrow keys on your keyboard to navigate to the first item of the sheet
• Use <copy> from <Control> group to copy the data to the clipboard
• Use NAVIGATE_NEXT_TAB to get back to your shop
• Paste data into the shop
• Add steps to verify the Shop is ok.

Developers need early feedback if a code change breaks functionality. Running your tests after each deployment is easy. On your Project Page press “Play”:

In teams, this gets more complicated. Therefore, you want to include the tests in your build pipeline. Then, you can pinpoint to the exact commit that broke the test. Either use our REST integration or the Zapier integration to achieve this.