Automated testing for systems that have none
We add automated tests to business systems that were built without them, starting with the workflows the business depends on, so every change can be checked before it reaches users.
What you probably want to know first
- Our system has no tests at all. Is it too late?
- No. Most of the systems we take over have few or none. We do not try to test everything. We start with browser tests of the five to ten workflows that would hurt most if they broke, which can be done without changing the application's code, and add more as each area is changed.
- Will testing slow down development?
- It slows the first changes slightly and speeds up everything after. Without tests, each release needs someone to click through the system by hand, and the problems they miss reach users.
- What do you need from us?
- A test environment with realistic data, or a copy we can make one from, and an hour with the people who know which workflows matter most.
- What have you done with systems like this?
- OpenIRIS has a Playwright suite that runs every night against its test environments, covering the main booking and administration workflows and checking permissions across different user roles, plus integration tests that run against a real SQL Server database. While the system moves to a new API, a further set of tests checks that the old and new code give the same answers.
Who this page is for
This page is for managers responsible for a business system where every release is a worry, because nothing checks that the change has not broken something else.
Why systems end up without tests
Most business software was written under time pressure by a team that tested by hand. As the original developers leave, the knowledge of what to check leaves with them, and each release becomes riskier than the last. People respond by changing the system less often, which makes each change larger and riskier still.
Where to start
Not with unit tests deep in the code. For an existing system, the quickest protection comes from browser tests that use the system the way people do, because they can be written without changing the application and they keep working through a modernisation. Integration tests on the server code follow, area by area, as changes are made.
On OpenIRIS, the nightly browser suite and the comparison tests between the old application and its new API are what allow the system to change every week while research facilities across Europe keep booking on it.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss testing for your system 0800 433 7990What we put in place
- Browser tests of key workflows
- Playwright tests that use the system as a person would: sign in, book, order, approve, invoice.
- Tests for each type of user
- The same workflows checked as an administrator, a manager and an ordinary user, so permission mistakes are caught.
- Integration tests against a real database
- Server code tested against a real SQL Server rather than an in-memory stand-in, so queries behave as they will in production.
- Old and new compared
- During a migration, tests check that the new code returns the same results as the old for the same data.
- Runs on every release and every night
- Tests run automatically in the release pipeline and overnight against the test environment, with failures reported each morning.
- Flaky tests dealt with
- Tests that fail at random are fixed or removed, so a red result always means something.
How we add tests to an existing system
Choose the workflows
With your team, list the workflows whose failure would hurt most.
Prepare test data
A test environment with realistic, anonymised data and accounts for each type of user.
Write the first tests
Browser tests for those workflows, written against the system as it is today.
Wire them in
The tests run in the release pipeline and overnight, and results reach the people who act on them.
Grow as you change
Each later change adds tests for the area it touches.
A good fit when
- Every release is followed by a round of things that broke.
- Releases are tested by someone clicking through the system by hand.
- You are about to modernise a system and need to know the new version behaves like the old.
Probably not for you if
- You need a formal, independent penetration test; that is a specialist service and we can point you to providers.
Questions we are asked
Why Playwright?
It drives real browsers, works with any web front end regardless of the framework it was written in, and is free. Tests written in it keep working while the application underneath is modernised.
Do the tests use our live data?
No. Tests run against a test environment. Where it is built from a copy of production, personal data is anonymised first.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.