Plain-English guide

What is end-to-end testing?

End-to-end (E2E) testing checks that a whole journey through your website or app works from the first click to the final result, the way a real customer would do it. An automated end-to-end test does this with a robot that opens a real browser, clicks, types and checks what appears on screen, every time your developers change something.

  1. 01 Open the shop ✓ Home page loads
  2. 02 Log in ✓ Account name shows
  3. 03 Add to cart ✓ Cart shows 1 item
  4. 04 Pay with a test card ✓ Payment accepted
  5. 05 Order confirmed ✓ Email arrives
One end-to-end test. If any step fails, the test fails and the change is stopped before customers see it.

A simple example

Picture an online shop. One end-to-end test might open the site, log in as a test customer, add a product to the cart, pay with a test card, and then check that the order confirmation page and email both appear. Each step checks something along the way: the cart shows the right item, the total is correct, the payment goes through.

It is called end-to-end because it tests from one end of the journey (the customer’s screen) all the way through to the other (the server, the database, the payment provider, the email) and back. Nothing is faked or skipped in between.

A person could do the same check by hand, and many teams do before every release. The difference is that an automated test takes seconds, never gets bored or skips a step, and runs on every change, not only before big releases.

End-to-end testing vs unit testing vs manual testing

Most software teams use a mix of three kinds of checks. They do different jobs:

Question Unit tests End-to-end tests Manual testing
What it checks One small piece of code on its own, e.g. “does the VAT calculation add 15%?” A whole customer journey through the real product, e.g. “can someone sign up, pay and get their invoice?” Whatever the person clicking through remembers to check
Who or what runs it Code, automatically A robot in a real browser, automatically A person
How long it takes Milliseconds Seconds per journey Hours per release
Catches parts that don’t fit together No Yes Sometimes
Runs on every change Yes Yes Rarely

You want both kinds of automated test. Unit tests are fast and cheap, so developers write lots of them. End-to-end tests are slower, so you keep them for the journeys that matter most: the ones where a bug costs you money, customers or trust.

What end-to-end tests catch

  • A change in one place breaks something somewhere else. A developer tweaks the account page and, without anyone noticing, the sign-up button stops working.
  • Parts that work alone but not together. The website and the server each pass their own checks, but the website sends the phone number in a format the server rejects.
  • Checkout and payment problems. A promo code no longer applies, or the payment page hangs after the customer taps “Pay”.
  • People seeing things they shouldn’t. A normal customer can open the admin page by typing its address.
  • Bugs in one browser only. Everything works in Chrome, but the “Next” button does nothing on an iPhone.

What they don’t do

End-to-end tests are one important part of quality assurance, not all of it:

  • They don’t replace unit tests. Developers still need fast checks for the small pieces of code.
  • They check that things work, not how many users your servers can handle (that is load testing) or whether someone can break in (that is a security test).
  • They need a little upkeep. When a journey really changes, for example a new step in sign-up, the test has to be updated to match.

Does my product need end-to-end tests?

It probably does if any of these sound familiar:

  • Someone clicks through the whole app by hand before every release.
  • Customers have reported a broken sign-up, login or checkout before you found it.
  • You release often (weekly or more), or several developers work on the same product.
  • You take payments, or have different user roles such as admin and customer.
  • Developers are nervous to change older parts of the code.

A good first step is to cover the three to five journeys where a bug would hurt most. For most products that is sign-up, login and whatever makes you money, such as checkout, booking or subscribing.

Common terms, explained

E2E
Short for end-to-end.
Test automation / automated testing
Tests that a computer runs by itself, instead of a person doing the checks by hand.
QA (quality assurance)
The work of making sure software does what it should before customers use it. E2E testing is one part of QA.
Regression testing
Checking that things which used to work still work after a change. A suite of E2E tests is one of the best regression checks.
CI (continuous integration)
The system that automatically builds and checks your code every time a developer proposes a change. Your E2E tests run here.
Flaky test
A test that sometimes passes and sometimes fails without anything changing. Good E2E suites are built to avoid this.
Playwright and Cypress
Popular free tools for writing E2E tests. Playwright can test Chrome, Firefox and Safari.

How Greenlight E2E can help

We build automated end-to-end tests for software teams across South Africa. We write the tests for your most important journeys using Playwright, put them in your own code repository, and set them to run on every change. Your developers get a video and screenshot of anything that breaks. Fixed prices start at R18 500.

See pricing, what we need to get started, or book a free 30-minute call and we’ll tell you which journeys to test first.

Next step

Not sure where to start?

Book a free 30-minute call. We’ll look at your product together and point out the journeys worth testing first.

Book a free call Email us