In short: End-to-end testing checks a complete customer journey across all the systems behind it, from search to the order in the warehouse. In e-commerce it is the only test that checks what the customer actually does. Keep it to a handful of key journeys, use test data you control, and agree who owns it when several suppliers deliver.

Picture a release where every supplier tested its part. The agency tested the front-end, the platform vendor tested the platform, and IT tested the connection to ERP. All green. Then the first customer orders a product with a discount code, pays, and the order reaches the warehouse without the discount. Nobody’s test failed, because nobody tested the order from start to finish. That is the gap end-to-end testing closes.

What is end-to-end testing?

End-to-end testing checks a complete flow through an application and everything it depends on, the way a real user goes through it. A unit test checks one piece of code and an API test checks one service. An end-to-end test follows the whole journey. In a webshop, a customer searches for a product and adds it to the basket. They apply a promotion, log in, pay and get a confirmation. Behind the scenes the order then reaches ERP, the warehouse and customer service. An end-to-end test checks all of that in one go. It checks the result where it matters: the right product, price and address at the end of the chain. In Dutch this is often called a ketentest, a chain test, which describes it well. The downside is that end-to-end tests are slow and fragile, because they touch every system at once. That is why the test pyramid keeps them few, with most checks lower down.

Why is end-to-end testing harder in e-commerce?

Because the chain is long and nobody owns all of it. A typical webshop runs on a front-end, a commerce platform, a content system, search, login, a payment provider, ERP and a warehouse system. Several of those come from different suppliers, each with its own release rhythm and its own tests. At clients we see the same pattern again and again. Each supplier delivers and validates its own part. The business and QA then spend a lot of time checking separate deliveries, and sprint goals slip. Processes that cross several systems are rarely automated end to end. Nobody owns them, nobody has the full picture and it is never the priority. The result is a lot of automation, and still too many incidents in production.

Which journeys should you test end to end?

Only a handful: the journeys that cost money or customers when they break. Everything else belongs in faster tests lower down. A good starting set for a webshop:

• Search to paid order. Find a product, add it to the basket, check out and pay with your most used payment method.
• Promotion at checkout. A discount or bundle that has to survive all the way to the invoice.
• Returning customer. Log in, see the order history, reorder.
• Order after checkout. The order arrives in ERP and the warehouse with the right products, price and address.
• Return or cancellation. The refund reaches the customer and the stock is updated.

Test the business rules behind these journeys, like discount logic and stock, at API level. That is faster and more stable, as we explain in our article on API testing. The end-to-end test then only has to prove that the pieces work together.

How do you keep end-to-end tests stable?

Most unstable end-to-end tests fail on their surroundings, not on the software. The data changed, a connected system was slow, or another team was testing in the same environment. Four habits help:

1. Use test data you control. Create the customer, products and prices the test needs before it runs, and reset them afterwards.
2. Use stand-ins where a system isn’t the point. If a journey is about checkout, a stand-in for an outside service can keep the test stable. Keep a few tests against the real connections.
3. Wait for states, not seconds. Modern tools such as Playwright wait for the page to be ready instead of using fixed pauses.
4. Run them every night. A test that runs daily gets fixed quickly. A test that runs once a quarter is out of date before it starts.

Our article on flaky tests goes deeper into tests that fail when nothing changed.

Who owns the end-to-end test when you have several suppliers?

Someone has to own the chain, not just the parts. In practice that is the organisation that sells to the customer: you. Suppliers test their own deliveries. One party keeps the end-to-end set, runs it against every combination of releases and reports what breaks, whoever caused it. That also changes how you look at speed. QA often gets called the bottleneck, while the cause usually sits in the whole delivery process. Adding testers then is like widening the A4 without fixing the traffic flows around it: more capacity, hardly more throughput. A small end-to-end set that runs every night does more than a large team checking each delivery by hand.

What this means for your team

Write down your five most important customer journeys. For each one, ask who tests it from start to finish today, and how often. If the answer is “each supplier tests its part” or “we check it by hand before a big release”, you have found the gap.

That is the part we help teams with. We test across suppliers and systems, so a release is checked as one chain, not as separate deliveries. More on that on our e-commerce testing page. With Test Automation as a Service we build and run the end-to-end set and the faster tests underneath it, every night, alongside your team.

Frequently asked questions

What is the difference between end-to-end testing and integration testing?

An integration test checks that two systems work together, for example the webshop and the payment provider. An end-to-end test follows a whole customer journey across all systems. You need both: integration tests find the problem quickly, end-to-end tests prove the journey works.

How many end-to-end tests do you need?

Fewer than most teams think. A handful of key journeys usually covers the biggest risks. Put the variations, like every discount type or payment method, in faster API tests underneath.

Can you automate end-to-end tests?

Yes, and for a webshop that changes every week you should. The condition is stable test data and an owner who fixes a broken test the same day. Without those, automated end-to-end tests turn red so often that nobody looks anymore.

What is a chain test?

A chain test, or ketentest in Dutch, is another name for an end-to-end test across several connected systems and organisations. The term is common in the Netherlands, especially where processes run through systems of different suppliers.