System Testing
System testing is the work of proving a feature in the place it will be used — with the people, devices, accounts, and hand-offs it actually needs. It is not a click-through on one machine. Two human beings often have to cooperate: one invites, the other accepts; one sends, the other applies. We take ownership of that trial so your staff do not have to.
Turnkey, from the codebase
You can point us at a codebase and name the feature. We use AI to read that code and draft the system spec: roles, the kit the trial needs, numbered cases, gates that fail the whole piece of work, and what is out of scope. Experienced testers then run that protocol on the equipment it names. You do not have to write the script first. The draft is not the last word — we still argue with coverage before anyone spends the lab days — but the path from repository to a recorded verdict can be turnkey.
01 Point at the code
A repository, a branch, and the feature to prove. A brief helps; it is not required if the code and product already state what the feature is for.
02 AI drafts the system spec
Roles, equipment, one-time setup, numbered cases, and fail-the-trial gates, written from how the code actually behaves — including the awkward joins between people and devices.
03 People run it on named kit
Experienced testers execute the protocol on the devices, accounts, and network the spec defined. Pass, fail, or blocked on every row, with the words on screen when something fails.
01
What we mean by system testing
Unit tests and a single-user walkthrough miss the failures that matter. A product that shares work across phones, logins, or organisations fails at the join: the wrong person sees a button, a copy overwrites live data, a name leaks onto a device that should not hold it. System testing puts those joins on a written protocol. Roles are named. Equipment is listed. Each case has an action, an expected result, and a place to record pass, fail, or blocked. The trial has gates — a handful of failures that fail the whole piece of work, not just a row.
02
Why organisations give this work to a third party
The people who built the feature already know how it is supposed to go. They skip the awkward path, share a login, and call it done. A third party brings time, a second pair of hands, and a lab that is not the developer’s own phone. You get a dated verdict, notes, and a list of what was not run. That is convenient. It is also the point: someone else owns the result, and they are allowed to fail the trial.
03
Why the tester has to understand the product
A spreadsheet followed blindly is not ownership. If the spec is thin, we say so before you spend the lab days. If a case cannot prove what it claims, we rewrite it. If a role, a negative path, or a privacy check is missing, that is coverage feedback — not a surprise at the end. We work in the same technical space as the product: Apple-native software, more than one identity on a device, cloud shares, and the difference between a live book and a copy. You should expect us to argue with the spec, not only to tick it.
A worked example
Inviting a colleague in wellNet
wellNet is our own practice diary. Invite a colleague is the path for a locum or associate on their own iPhone and their own Apple ID — not a clinic handset. There is no live two-way sync for that person. Data moves only when someone taps a button. Two people, two devices, and two Apple IDs have to cooperate. That is system testing. See wellNet and Staff organisation.
Owner (administrator)
Practice Apple ID. Invites, publishes a diary skeleton, applies what the invitee sent, and can remove access.
Invitee
Personal Apple ID. Accepts Apple’s share, force-quits and reopens, books on their copy, then sends. They cannot publish the live book.
Practice-phone staff
Same Apple ID as the owner, live diary. They must not see Send or Apply. That negative case is part of the protocol, not an afterthought.
The hand-off
The owner sends Apple’s invite from Messages or Mail. The invitee accepts, closes the app fully, and signs in as themselves — Apple ID is iCloud; wellNet user ID is who they are in the diary. Later: owner publishes, invitee pulls; invitee sends, owner applies. Neither side can finish the job alone.
What coverage has to include
- Publish and Pull send a diary skeleton (times, treatments, staff, rooms). Practice client names must not appear on the invitee schedule.
- Bookings and payments stay on the invitee’s phone until Send and Apply. The live book does not change in silence.
- A clash on Apply offers Skip or Apply anyway — never a silent overwrite of a slot that is already booked.
- Pull while there is unsent work must ask first. It must not wipe a draft without a choice.
- wellNet must not write a booking into Apple Calendar. Calendar on the phone is a read-only overlay.
- Leave, owner uninvite, and re-invite are in the protocol. So is a second invitee, when you need it.
Gates that fail the trial
The trial fails if Apply writes nothing after a successful Send; if Pull wipes unsent work without asking; if a clash overwrites the live slot with no prompt; if client names leak onto the invitee schedule; or if a booking is written into Apple Calendar.
The full protocol is a numbered lab script: environment, invite, accept, privacy, write-back, clash, dirty Pull, match, calendar, leave, permissions, and re-invite. Testers record pass, fail, or blocked on every row. That document stays with the engagement. This page is the shape of the work, not the script.
The trade calls this system testing, independent software testing, outsourced QA, or third-party test execution. We mean a written test specification, coverage you can argue with, and a lab run on defined equipment by experienced personnel.
What you should expect from an engagement
01
Point at the codebase
A repository and the feature to prove. A written brief is welcome; it is not a prerequisite. We can start from the code.
02
Draft the system spec
AI reads the code and drafts the protocol. A person who knows the space then tightens it: in scope, out of scope, equipment, numbered cases, and the gates that fail the whole trial. If coverage is weak, you hear that before the lab runs.
03
Execute with defined equipment
Experienced testers run the cases on the kit the spec named — the phones, accounts, and network the feature actually uses. Two people where the feature needs two people.
04
A verdict, and a note on coverage
Pass, fail, or blocked, with what was not run and what the spec still misses. Ownership means we will say the test was not good enough, not only that the build was not.