End-to-end tests in plain words: what is checked before every release

Before a new version of your software goes live, someone has to make sure that the things people do with it every day still work. An end-to-end test does this automatically: a program uses your software the way a person would, from the first click to the result, and reports whether it worked.

What is an end-to-end test?

An end-to-end test opens your software in a real browser, signs in, clicks, types and checks what appears on the screen. Because it uses the finished software with all its parts together, it tells you whether the whole thing works, not only whether each part does. Tools such as Playwright run these tests in the browser engines behind Chrome, Firefox and Safari, and can imitate a phone.

An example from software for a joinery: one test signs in as an office employee, creates a quote for a kitchen, sends it to the customer and checks that the quote now shows as sent. If any step breaks, the test fails and says where.

That is what such tests catch. A button no longer reacts after an update, a form saves nothing, an email is never sent, a screen only breaks on a phone, or a new feature quietly blocks an older step. Each of these can pass every smaller test and still stop your team from working.

How does it differ from other tests?

It tests the whole software the way a person uses it, while other tests check smaller parts on their own. Testing guides, Google's among them, describe three kinds of automated tests:

• Unit tests check one small piece of code on its own, such as the calculation that adds VAT to an invoice. They are small and quick, and a good set of tests has many of them.
• Integration tests check that two parts work together, such as the software and its database.
• End-to-end tests check a whole journey through the finished software, in a browser.

End-to-end tests give the biggest confidence that the software works. They are also slow, need a lot of upkeep and sometimes fail for reasons that have nothing to do with a real error. That is why testing guides advise keeping them few and focused on what matters most. In 2015, Google's testing blog suggested a split of 70% unit tests, 20% integration tests and 10% end-to-end tests as a first guess, and added that the exact mix differs for each team.

One more test is not automated at all: you, trying the software yourself before it goes live. That is why your software should first run in a test version that you can try, with the same screens your team will use.

What should be tested before a release?

The journeys your business depends on. A useful question for each one: if this stopped working tomorrow, would it cost us money or trust? The list could look like this:

• signing in, and what each role is allowed to see and do
• the main process from start to finish, such as an order, a quote or an approval
• everything that sends something out: emails, invoices, documents
• payments, if the software takes them
• the screens people use most, on a phone as well as on a computer

Ham Vocke's guide "The Practical Test Pyramid", published on Martin Fowler's website, gives the same advice: find the user journeys that carry the core value of your product, and turn their most important steps into end-to-end tests. The edge cases belong in the smaller tests below them.

These tests should run before every release, in a test version and not on the live software. With us, your software first runs in a test version that you can try. We test it thoroughly there, right through from start to finish, and it goes live only when everything works.

Who owns the tests after the handover?

The tests belong with your software. They are written for it, they check how it behaves, and whoever changes it later needs them to know that nothing broke. A proper delivery includes them, together with the documentation.

What you receive at the end, and on what terms, is agreed in the offer, so read that part before you sign. Ask three things: are the automated tests part of the delivery, can someone other than the original builder run them, and do they come with a short note on how? The rights to the code are a question of their own, explained in who owns the code.

Tests also matter long after launch. Every security update changes the software a little, and the OWASP Top 10 of 2025 counts "software developers do not test the compatibility of updated, upgraded, or patched libraries" among the signs that an application is likely vulnerable. Tests that come with the software make each update checkable. More on the time after launch in software maintenance after launch.

Where do tests fall short?

Tests show that the journeys someone thought of still work. They cannot show that nothing else is wrong. The computer scientist Edsger W. Dijkstra put it this way in his Turing Lecture of 1972: "program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence."

A test can also fail when nothing is wrong, because of timing, an animation or an unexpected dialog. Such false alarms have to be fixed, or people stop trusting the tests.

So two things belong next to the tests:

• Your own try-out in the test version, where you notice what no test was written for.
• Monitoring after launch, which checks the live software at set times and raises an alarm when something fails, because some problems only appear in real use.

A failing test before a release is good news: it found the problem before your users did.