10 Tests For Building A Robust eCommerce Platform

A plethora of software tests exist and can appear quite a conundrum for brands initially. While each test has unique efficacy, not all are applicable for everyone. Comprehensive knowledge and insights will help in understanding the appropriate tests for the success of your brand. In this blog we will elaborate on the types of eCommerce tests.

Read on!

The sheer range of software test types often leave us wondering about the differences between them. Same is true in the case of eCommerce testing. The smart thing is to figure which test types apply to YOUR eCommerce application. Moreover,  it is highly dependent on the customer’s expectations and business rules. 

Following are the basic conditions that decide the test types for an eCommerce application -

• - Commerce Type  - B2B, B2C, C2C
• - Product Categories - Hardware, Apparel, Food 
• - Geographical Region - India, USA, UK, UAE, etc
• - Application Types - Web, Mobile, Desktop, Kiosk 
• - Systems architecture - like, how inventory is connected to storefront
• - Functional & Non-functional benchmarks
  

From the collective experiences of Mozanta’s quality department that has tested more than a thousand eCommerce project sprints, here is a recommended list of test types to consider during the planning phase of an eCommerce project.

1. Unit Testing

Get the unit tests done to find issues, if any, in the implementation of development units. This refers to individual developers testing the individual units (testable) of code. It helps in the early detection of bugs. The idea is not to uncover all system or integration-level issues but to lower their count by identifying unit-level issues.

2. Dev Box Testing

High deliverables, duration of sprint and strength of the team are beneficial for dev box testing. The testers will test the boundary cases and conduct the detailed tests, as much feasible, in the developer’s machine. It improves the Dev-QA connection and understanding of stories, helps to get stable builds in the QA environment, and practically reduces testing cycles.

3. Smoke Testing

Now, for each build that comes to testing, we can perform a smoke test to discover the possibility of issues that make the build non-testable. The smoke test cases will be high-level, looking at the critical functionalities. These cases are to be derived from the business expectations of the build and defined at a functional level. The smoke test suites could vary from project to project, client to client, with a large set of common cases across them. Depending on your quality gatekeeping practices, there could be a smaller set of smoke cases for developers to check the test readiness of deployed builds. Testers could have a superset of the same for their validation.

4. Sanity Testing 

Sanity testing is to validate if the feature you plan to test is present in the application. It would be a subset of cases from the total functional test cases of the feature under test.

5. User Story Testing

The whole set of identified cases derived from the user stories of the implemented/modified feature is tested here. Story testing would be any of the below based on the user stories capture model.

• - UI Testing - The UI elements are tested against their specifications (eg: color, dimensions, fonts, etc)
• - UX Testing - Testing the Usability of the UI elements, and the user experience while interacting with them (e.g. showing progress bars, giving notifications)
• - Functionality Testing - Testing the functionality, i.e. the system’s behavior and/or outputs for a set of inputs. Edge cases included. 
• - Load Testing - Testing the behavior of the system under different load levels and also determining the max load capacity of the system. 
• - Volume Testing - Testing the system with volumes of data to identify the count and size of files or data that the system can process.  (e.g. 100 catalog files per minute)
• - Files Testing - Validating the content of files and feeds to ensure that the system accepts and produces files in the expected format. (e.g. Google shopping feed content)
• - Responsiveness Testing - Testing across multiple devices, browsers, etc.
• - ETL Testing - Testing the data to ensure its authenticity, completeness, and integrity. Tests for new data warehouses, testing migrated data, etc would be the key sub types
• - Analytics Testing - Testing the analytics part of your application, commonly Google Analytics
• - System Integration Testing - Testing the integrations of the system under test. Verifying the flow of data and control between the integrated systems.
  
  

6. SEO Testing

Testing the SEO capabilities of your website. The basic tests can start with checking for proper tags - meta, headers, etc. We can use tools as well for doing SEO checkups on the website

7. Regression Testing

Testing to uncover any disturbances caused by the new development activity to the existing system(s). The regression tests are planned based on the technical and functional impacts identified. A final regression test is mandatory and the cycles of regression tests could be planned and executed as required.

8. User Acceptance Testing

Different steps of UAT are used to validate if the system meets the end-user’s business perspective. The application can be provided in a production-similar UAT environment for the end-user testers to validate. The alpha (internal testers verifying in a protected production environment), and beta (end users testing in a limited access production environment) testing types can also be planned as required.

9. Security Testing

Security is a significant term in eCommerce. It becomes further critical if there is payment info associated as well.  Vulnerability Analysis, Penetration Tests and InfoSec Audits need to be done to discover possible vulnerabilities in the system and to rectify them.

10. Automation of Tests 

Test automation helps a lot in reducing the schedule and test execution efforts. This, however, requires an effort of automation script preparation and maintenance. In order to find out which tests are to be automated, we have to find out which ones - tests and cases - are to be repeatedly executed over time. The savings from test automation is directly proportional to the test cycles run using automation. 

Finding the proper automation tool is equally important here. The application type, the project duration, the cost, the tester’s skills, and the test type are the contributing factors. 

Final words

There are numerous test types based on What, When, Why, and How you test something. The types mentioned here are some of the core ones and do not provide a comprehensive and all-inclusive list. 

Some test cases are shared across many of these test types and some are not. Some cases might be run just once in the whole SDLC, while others might be endlessly executed from day 1 till the website is scrapped. The key, as we discussed initially, is to find the right ones for your brand.

Also, the test level-test type correlation depends on the defined processes of the project. We have people who do System Integration Testing per story once that story is available for testing. Some prefer to do the SIT after the whole functionality testing is complete for the sprint. It is always better to plan as per the deliverables promised and stakeholder agreements.

In today’s agile way of software development, everything, including the test plan, evolves constantly. So adaptability is the buzzword here. 

Happy testing!