The larger your ecommerce store grows, the more complex the software behind it becomes. Even if you outsource your store development or use a hosted platform, this complexity will affect you.
One symptom of a complex platform is errors and broken features. These could indicate a problem in how your store is built — a software manufacturing problem.
Ideally you and your team could update your store without incident. A new feature could be developed and deployed, and customers would start using it right away.
Instead the following often occurs.
- The need for a new feature is identified.
- Getting it into production takes several people hours of work.
- When it’s finally deployed, customers encounter bugs.
- The deployment also breaks an unrelated feature.
- You must decide whether to throw away that deployment and start over, or fix the live version.
Thus it’s easy to see why some ecommerce stores rarely update anything.
Preventing Software Failures
There’s one simple tool that can prevent this situation from occurring most of the time: automated testing. It could save hours of development time and many operational headaches.
Ecommerce stores do not typically put enough focus on testing software changes before they are deployed to customers. Testing is boring, resource intensive, and you’re never quite sure if you tested everything well enough. But most organizations, sooner or later, have testing programs in place because they became sick and tired of the damages caused without it.
Automated testing is different. It is not merely clicking around your store randomly to see if things are working.
Instead, it is actual code that tests other code. Code testing code. This might sound complex but there’s a simple analogy to clarify.
With a health concern, most folks see a doctor, who will then diagnose of what is wrong. With major incidents, you’ll likely want a second opinion to verify and confirm the original diagnosis.
Automated tests act as this second opinion. The first opinion is the original developer who wrote the code. The automated test then analyzes that code to confirm it will produce the intended result.
Automation Runs Forever
They key point of automated tests is that they are, well, automated. Once created, an automated test can run forever — or until the code needs to be changed.
An automated test that a developer writes today to confirm, say, that the new shipping calculator works will be making sure that it works for as long as your store exists. I’ve seen a test that lasted over eight years before it needed to be touched again.
Here’s an example.
Say your ecommerce store offers a discount when an order is over $50. Here’s how that code could look.
def discount_can_be_applied? if total > 50 return true else return false end end
It’s simple, right? If the order total is more than 50 (dollars), the discount is applied (returns true) otherwise it is not (returns false).
An automated test might look like this.
def test_order_discount order = Order.new(line_items_total: 40, shipping: 10) assert_equal true, order.discount_can_be_applied? end
In this test, a hypothetical order is created with $40 worth of product and $10 of shipping.
Then, assert_equal is used to make sure that a discount can be applied.
Every time the automated test runs, it checks the logic around discount eligibility and confirms that all is good or that something is broken — ideally before a customer encounters the code.
How to Implement
There are drawbacks to creating automated tests.
Since they are code, they have to be created and maintained — like your store’s software.
A much more difficult issue can occur when a developer’s ego gets involved. Automated tests are a fantastic tool, but some developers will perceive them as a way to place blame. Overcoming this misconception is easier if crashes, failures, and outages are frequent.
It’s best to let your development team decide how to use automated tests, as forcing them onto a team won’t necessarily work. The tests are easy to defeat with a straw-man implementation, wherein the team sabotages the initiative.
Two good ways to get your team to buy in to automated tests are to let them use the tests selectively so they see the value, and give them more resources to get started.
Developers know the problem areas in a project. Even new developers learn about these within the first couple of months. These problem areas have the most to gain from automated tests. Encourage your team to start adding tests whenever they work on those sections.
Better still, give them extra time when working in those areas. That will ensure they actually have enough time to make the changes needed, as well as adding tests. Double the estimated development time during this learning phase.
Emphasize the benefit of automated tests to your development team, even though it will be hard to notice the benefit because it won’t be a huge change to the final results. It will be more like the lack of problems. Thus, after a first deployment your developers could go home at 9 p.m. instead of sleeping under their desks.
Automated tests are not magic buttons that solve everything. But they can be a critical tool to prevent software crashes and mistakes — all of which could cost your store orders and customers.