November 21, 2013
When a company launches a website, likely they have a goal in mind. Based on what this goal may be, the site may contain different functionality focused towards that goal. Companies with a goal to sell their product online often commission an area of their website just for this goal called “e-commerce”. Simply put, the e-commerce portion of a website is better known as an online store. Users interface with this system to purchase, ship, and in some cases customize the product they are adding to their cart. Ultimately this is an important part of any company’s website, as monetary transactions will be processed here. If something goes wrong, it can prove catastrophic to the company and the end user. This means that quality assurance is essential whenever an e-commerce system is updated or created. So how does one approach testing something so large?
Step 1: Plan and Strategize
The first, and possibly most crucial step is planning and strategizing. Not all e-commerce systems are built alike; as a matter of fact, most e-commerce systems I have tested vary in a number of ways, including discount processes, promotion code entry, and checkout flows. While one website may require a user to have an account in order to view discounts, another website may allow discounts to anonymous users through promo codes or online savings. It is important to have an understanding of all of the systems integrated into the e-commerce system prior to testing. Will a user need to be logged in to complete purchase? Can they order online as anonymous users? How do these processes differ? A prepared QA resource is aware of all plausible scenarios for a user’s online experience so that no stone goes unturned.
Step 2: Organize
The second step to this process, after gathering all relevant user scenarios and e-commerce information, is organizing this information. A QA Specialist can have all the knowledge that they need, but if this knowledge is disorganized, it will be difficult for them to identify what test cases need to be executed when. This means that the QA Specialist sorts through all the information provided to them and identifies any integration points and how this will effect testing efforts. I have tested e-commerce systems that upon checkout link to an external client page. Because of integration with external systems, full purchasing cannot always be tested locally, and often needs to happen after the code has been pushed to the client’s beta server. It is important to identify these points prior to testing efforts so that testers do not spend unnecessary time trying to test something that cannot be tested; it also helps the project manager know that they need to inform the client of any risk factors early on. An outline of test cases should be written during the organization phase of e-commerce prep. At the end of this phase, the QA specialist should know on a high level what needs to be tested.
Step 3: Expand
Once information is organized, it needs to be expanded on. This is where test cases are flushed out into more than just an outline; when a user clicks “add to cart” on a product, I expect the behavior to be that a product adds to the cart. If these test cases are written referencing the scope, requirements, and design documents, and the QA specialist has both strategized and organized, these test cases should be close to concrete and will need minimal updating later in the project. These test cases can be presented to the client, and any holes noticed can be addressed. This stage is also where the QA Specialist should identify all different account scenarios needed for testing purposes, so that those scenarios can be passed along to the development team and created prior to testing. If planned out far enough in advance, this gives the team time to ensure that all test accounts are set up prior to alpha testing, so that the QA resource does not have to wait.
Step 4: Execute
Finally, test execution begins. If the QA resource has strategized, organized, and expanded, the execution should be simple. The QA Specialist already has user scenarios outlined, test cases written, accounts created. Although the actual testing may seem time-consuming, it would be much more time-consuming as well as sloppy without taking these prior steps of preparation. Altogether, the time spent strategizing, organizing, expanding, and then testing still comes out to less than if a QA Specialist were to jump into e-commerce testing with no plan at all.
At the end of all these steps, the e-commerce system should be sound enough that a user can easily make a purchase without interruption or errors. The end user should have no idea of the complexity involved in the system, and the client company should see purchases being made in their new system without complications. Although it may be close to impossible to outline all possible user scenarios, the amount of user scenarios that do not work should be encountered on a minimal basis. The end result of strategizing, organizing, expanding, and testing thoroughly should be a happy client and happy user base. After all, a thoroughly tested system is a happy system!
Do you think you can tell the difference between a poorly tested and thoroughly tested e-commerce system?
comments powered by