Technology
Table of Contents
Marketing strategies work as long as they have a base of a properly working online store. Quality Assurance specialists make sure customers can shop with ease, and then comes everything else. Testing in Magento is a topic that is not getting widely covered by Magento сommunity. And we, as a part of it, have a lot to say about quality assurance. To get a full picture of what testing in ecommerce and in Magento, in particular, is like, we turned to our colleague who knows the subject inside out. Anna is QA Lead at NEKLO with experience of 3,5 years in software testing. We asked her to tell us more about her work, challenges, and specifics of testing with Magento-based products.
In fact, it is more or less the same. The only specification that makes it any different from testing other software products is that we deal with ecommerce. The functioning online store implies selling stuff online. The end customer of any online store on any platform is an average person who wants to buy products online as effortlessly as possible. Our job is to make sure everything works the way the customer expects it, the store is convenient to use, and easy to learn its functions.
First of all, with a ready-made and stable platform like Magento, you don’t need to pay special attention to its UI testing. Most of it is already done and implemented in the core of the platform. Secondly, you definitely need to pay attention to our performance tests. Magento system requires quality hosting. You can’t have sustainable performance results without powerful servers.
Testing is all about finding bottlenecks, I will mention the ones that have no fixed solutions.
The project begins when the planning for it has started. The right choice of an approach doesn’t slow down the working process and should be flexible when the project demands so. In my opinion, Kanban methodology is the most suitable option for testing ecommerce projects. A project like an online store never stops changing, developing and working at its full capacity, and Kanban is flexible enough to handle it. When the task is completed, it goes straight to production, and another one takes its place. This way, the changes come in rather fast, and there is no need to wait for another sprint to get something done. Everything happens quickly, no matter if the task scope for the sprint is completed or not. Sprint can grow and change in the process.
Compatibility issues are inevitable when the project starts growing and standard installation gains custom solutions. There is no need to test the standard edition, This is where testing actually begins. The developers create extensions and implement them. The more extensions you add, the more possibilities for compatibility problems appear. And here comes the third issue.
When the project is moving forward and more extensions are added, you obviously need to test compatibility with the basic Magento installation. There is another tricky part: with each and every extension added, you get a few more “blind spots” of compatibility of extensions with each other. Ideally, you cover all of them. In reality, the schedule is very tight to find time for overall regression tests after every new feature added. But if you underestimate regression tests, you will inevitably face bugs and errors where you least expect them.
If there is no time for in-depth regression tests, there is also often not enough human resources. Magento has vast basic functionality, and all customizations should work properly in different environments: browsers, platforms, devices. Another significant example for ecommerce is payment methods testing. They are numerous and for that reason challenging to cover. And that is only part of the scope. Besides implementing the features the client requires for his project, developers install Magento patches which also require another round of regression tests. The thing is, the customizations and extensions are created and implemented by some people and tested by others. Errors go unnoticed during the exchange. There is no one-fits-all solution, this can be cured with correct management and prioritizing.
For many teams and projects, maintaining documentation is a cornerstone. Updated as and when necessary, documentation affects the quality of the teamwork. Documentation plays the role of the source you can always refer to if you are having a moment of controversy in your work with no or poor documentation, you are stuck.
I have to say it again: time management! There is always too much to be done, and you are not able to focus on everything to the same extent. What I mean by that is requirements evaluation and workflow management of the QA department at every step. Proper management excludes miscommunication between developers, QA and project managers. It also helps to create appropriate conditions to shift QA specialists from one project to another and to help new people to get into work faster.
Definitely adaptive design. Cross-browser testing is a must and you can cover about 80% of possible browser and platform combinations, but it is more complicated for mobile versions. There are too many devices and software versions to test at once. But customers choose to use the mobile versions, and cross-browser testing is not enough anymore. Web applications and mobile versions are completely different things. For example, the same banner can be displayed as a picture on the website and as a widget on mobile, and ignoring such occasions harms the project and can confuse and scare away the end customer.
Testing is not a final touch to the project, it is an entire unit of work, essential for a functioning ecommerce website. It never ends, and it requires more and more resources as the project grows. Сarefully planed, tests can make project development a stable process.
Ann Vershigora – QA LeadNeklo LLC
US-based and operating globally, NEKLO spearheads digital transformation initiatives for businesses worldwide. We deliver software solutions complying with your market and legislation.
.png)
.svg)
.svg)
