Ionic-Test
Ionic-Test is test automation for the business that has to prove a supplier's software works. You record a journey in the browser, run it on your own machine and sign off the evidence. It's multi-user and role-based, with signed evidence packs and separate staging and live environments. It took seven days from first commit. This page asks whether you can build a real SaaS product, not a demo, in a week.
A client's front-end regression testing rested on one specialist test engineer, who was leaving in about three months. Regression testing for their next release was due to start a few months after that. Their knowledge needed capturing in something that would outlast them. The test environments sit behind a VPN, which ruled out cloud test runners, so the tests have to run on the tester's own machine and report back to somewhere shared.
The brief I wrote was one line: anyone on the team can record a front-end test, run it and see trustworthy results, with no coding and no reliance on a specialist. It was built as an Ionic product from the start. The client lives in the data, and the code knows nothing about them.
01What it does
Record, don't code
Record a journey in the browser and save it as a named test. Typed values are lifted out into data sets, so a changed test account never means a re-record.
Runs where your VPN is
A local app plays the test back on the tester's machine in Edge, Chrome or Safari, at desktop, tablet or phone size.
A shared Hub
One register holds systems and versions, tests, test sets with pass gates, and every run's history.
Flaky tests are flagged, not trusted
Reruns, flaky-test detection and quarantine stop an unreliable test passing quietly.
Plain-English triage
Each failure is put in one of four buckets: a defect in the system, a fault in our test, the environment, or known and accepted. Defects are raised from there.
Signed evidence packs
Each pack holds per-step results, screenshots, video and traces. It is signed with the instance's key and can be checked offline by anyone. Passwords are masked in every file a run writes.
Accessibility on every page state
WCAG 2.2 AA checks are a step you can add to any test.
AI test design, on a leash
A gateway sets hard token caps and redacts each screen before it reaches a model. The AI proposes, and people decide.
02What makes it SaaS rather than a demo
Demos have one user, one environment and a happy path. This was built to be handed to people who didn't build it:
- Roles that mean something. There are four: viewer, tester, test lead and admin. An admin governs access but has no testing powers unless also given a testing role. Sign-off is one-stage or two-stage per workspace, and in two-stage the person who prepared a pack can't sign it.
- A real tenant boundary. Every record is keyed to a workspace. A record you can't see is indistinguishable from one that doesn't exist.
- Portable by proof, not by promise. The storage layer has a second, non-Cloudflare implementation, and one contract suite runs against both. A workspace can move between them and back intact.
- Staging, and a deploy that checks itself. A deploy backs up, rehearses on a copy of live, applies, then reads back what it did. Merging never deploys.
- Documentation as part of done. The user, admin and maintainer guides were written as the build went, and no step counted as finished until its docs were. Testers never need a terminal.
- Caps and credits designed in. Billing isn't built yet, but the hooks are there.
The method was the one I now use for everything substantial:
- a main session that orchestrates
- separate builder and reviewer agents for each pass
- a stronger model on anything touching security
Every review found real defects. One step had ten, two of them exploitable. On day seven I paused the build for a product and architecture review rather than keep going. Speed is only useful while you're heading the right way.
03So — can you build real SaaS in a week?
The honest version is that a week gets you the product. It doesn't get you adoption. The first real use was my own walkthrough on the live Hub, and it found fourteen things the tests never could:
- a failure shown in green
- jargon in the triage screens
- navigation that hid how tests, sets, runs and packs connect
- the word "store", which everyone read as retail (it's now the Hub)
The first promotion to live was refused by a safety check that was itself wrong: it compared database schemas including their comments. Safety nets need testing too.
The client pilot comes next, and I'm not claiming time saved until there's a baseline to measure against. But the shape of the result is clear. The software is no longer the long pole; attention is. Tokens and attention are both finite, so the work runs one build at a time, and the scarce thing is knowing what to build next.
Want the thinking pointed at your problem?
Ionic-Test is heading into its first client pilot. If your organisation has to prove someone else's software works, and that proof currently lives in one person's head, that's a conversation I enjoy having.
john@ionicconsulting.co.uk