Acceptance testing for delivered software stages the difficulty your system exists to handle, then reads the state of the record afterwards. Each scenario comes from a negation the project already carries in its difficulty lines, and a negation names a place the record can be wrong. In AlgoKlima the scenario passes when a technician out of signal and the office change different fields and one record is left holding both.
What a demo cannot produce
Acceptance day tends to look the same everywhere. The vendor shares a screen, walks the menus in order, creates a record, shows it landing in the list, then opens a report. Every click behaves, and the room relaxes. What produces the relief is not that what you saw was correct. It is the shape of what you saw: one screen, one session, one pair of hands.
The difficulty your system was built to handle is not in that room. AlgoKlima, which we run ourselves, exists because of a specific one: a technician out on a job and a colleague back at the office can each touch the same service record without knowing about the other. While the vendor clicks alone, that situation never arises. The fault is not hidden from you; it is never produced. The difference matters, because a hidden fault yields to attention and an unproduced one does not, however carefully you watch.
Diotek shows the same gap from another side. A visitor sends a request from the website and the screen says it was sent. That message is the visitor’s side of the exchange. The system’s actual job is that the request lands on the operations side already separated by type, and a demo rarely opens the operations side at all. As long as the visitor’s screen behaves, everyone assumes the flow behind it does too.
Something else is also tested on delivery day: whether the items handed to you are enough to stand the system up again. That question, which is reproducibility, belongs to the article on the handover list and the check for each item. Whether the software does the job it was bought for sits outside it, and the article on the questions to put to a software company deliberately left it out.
In a job where one person enters the record and no other role ever touches it, a demo and an acceptance genuinely coincide. There the screens opening really is the test, and the scenarios below would only add cost. This article is for systems where the same record passes through more than one pair of hands.
Scenarios come from a project’s difficulty lines
Writing acceptance scenarios sounds like producing a new document. It is not. The list already exists in the project’s own difficulty lines; it has simply not been turned into actions yet.
The mark of a difficulty line is a negation. “Can edit it unaware”, “must never cross the boundary”, “is not the same form” — each says that something ought not to happen. A negation names the place where the record can go wrong. An acceptance scenario is nothing more than turning that named place into something a person does.
The conversion runs like this. “The office and the field can edit the same record unaware” becomes: edit one record from the field and from the panel at the same moment. “A payment must never cross the institution boundary” becomes: post a payment under the neighbouring institution, then pull your own report. “A survey and a service call are not the same form” becomes: open the request types back to back and read the operations side. We are not inventing the mapping. On the project pages, the difficulty line and the place where it is answered sit next to each other; the scenario fills the space between them.
Some lines do not make the list. A difficulty sentence with no negation in it, such as “the administrator should be able to see the monthly report”, is a visual check rather than a scenario. You open the screen, the report arrives, the line closes. Because it names no place where the record can go wrong, it produces no test. That distinction shortens the list, and shortening is the point: only so many scenarios fit into an acceptance day, and filling that space with visual checks eats the testing itself.
If you have no difficulty list, derive one a step further back. The description of the need you wrote at quote stage carries assumptions, and every assumption is a candidate difficulty. The article on why quotes for the same job come out differently puts that assumption list at the point where quotes diverge, and the article on describing what you need builds the same list as business conditions. A scenario can be pulled out of either; which document it came from does not matter, carrying a negation does.
The office and the field edit one record at once: is a single record left
For AlgoKlima, a product we operate while new features keep arriving, the scenario is set up like this. The technician is on site, somewhere the signal has run out, and edits a field of the record from the app in hand. In the same few minutes a colleague at the office edits a different field of the same record from the panel. Then the technician moves back into signal and the connection returns.
Which fields you pick varies by project. Our project page does not name them, so the example here is given as a supposition. Say the technician updates the work note on the record while the office changes the contact person on it. What matters is not the names of the fields but that each belongs to the same record and that neither change knows about the other. Pick the fields yourself, and pick ones the office genuinely touches; a field nobody at the office ever opens turns the scenario into theatre.
The passing condition fits in a sentence. Once the connection returns, a single record is left, and each side’s change sits on it: the work note as the technician wrote it, the contact person as the office wrote it. If copies of the record are sitting side by side, or if one side’s change has vanished, the condition has not been met. Writing the condition as the state of the record is what makes it a measurement. “Sync is working” is an impression; “one record, each field at its new value” is something you can look at.
How the waiting changes come back together once the connection returns is not this article’s subject; the article on an offline-first field app and its sync does that work. On acceptance day you read the outcome, not the mechanism. Reading the mechanism means listening to the vendor’s answer. Reading the record means measuring it yourself.
The scenario has a price, and the price is exactly what makes it impossible at a desk. You need somebody who will go out on the job, and a moment where the connection genuinely drops. A demo the vendor runs alone contains neither, which is why the fault stays unproduced. What the app in the field keeps doing while there is no connection is a decision on the mobile app development side, taken long before acceptance day.
AlgoKlima’s project page states this difficulty in its own words, and you can lift the scenario straight from it. If no role of yours works outside signal, this scenario is never set up at all. Where everyone sits on the same network, the acceptance scenario is taken from a different difficulty line.
A tenant boundary is tested in the report, not on the screen
Under the Vipkurum roof, seven institutions run the same core, and each of them reaches it from its own address under its own brand. In a system like that, the expensive fault is not a screen opening wrongly. It is one institution’s data turning up inside another institution’s numbers.
Administrators usually test the boundary on the list screen. They open their own panel, look at the list, do not see the neighbour’s records, and conclude that the boundary holds. That is where the test starts, not where it ends. A list screen is a moment of reading. The boundary is also tested at the moment records are added together, which is the report, and in a demo the report is almost always opened with one institution’s data in it.
So the scenario is built from the report. The vendor defines a neighbouring institution for acceptance. Under that institution’s own address, a payment is posted for an amount you choose; choose it so that you will recognise it later. Your own institution’s administrator pulls the monthly report before the payment is posted and pulls it again afterwards. The only variable in between is the record entered under the neighbour.
The passing condition is plain: the total in your report has not moved, and the amount posted appears only in the neighbouring institution’s report. If the total moved, the boundary was not written into the layer the report reads, and the list screen would never have told you. The rest of the condition matters as much — the amount really showing up in the neighbour’s report proves the record was not swallowed. A boundary breaks by losing data as well as by leaking it.
Why this happens, meaning which layer the tenant boundary is written into, is a separate subject; the article on how multi-tenant systems are built opens it. On acceptance day your job is the action rather than the diagnosis: post it, pull it, compare.
A system used by a single institution has no neighbour and therefore no scenario. Yet a system that starts with one tenant and plans a neighbouring institution for next year does need it on acceptance day; the vendor defines that neighbouring tenant for the acceptance anyway.
Open the request types back to back and read the operations side
At Diotek, a site survey booking and a service request are built as separate flows. A survey asks about a location: what will be inspected, and what state it is in. A service request asks about a unit already in place: which unit, what the complaint is. They do not pass through the same form, because they do not start the same work on the operations side.
The acceptance scenario pushes on that separation. You open requests from the website back to back and scramble the order on purpose: a survey booking, a service request straight after it, then another survey. Scrambling is how you catch a dependency on arrival order. Requests should be sorted by their own fields rather than by the sequence in which they came in, and consecutive mixed entry is the cheapest way to press on that.
The passing condition is read on the operations side, not on the screen the visitor sees. “Sent” is an acknowledgement given to a visitor, not the output of a test. Open the operations side and look: are the survey bookings in their own flow, are the service requests in theirs, is each one sitting there as a written record. If all of that holds, the scenario passed. A request in the right flow but not in writing, a loose note attached somewhere on the record, will not be found in the middle of a season.
A smaller scenario looks at the hours nobody is watching. Open a request in the evening, when no one is at a desk. If it is sitting on the operations side as a written record the next morning, the flow does not depend on somebody remembering. The addition costs almost nothing on acceptance day and tests the moment closest to how the system will actually be used.
There is an honest limit here and hiding it would be pointless. Part of the difficulty Diotek carries is requests piling on top of each other at the start of a season, and that load cannot be staged on acceptance day. Consecutive, mixed-order entry only shows whether the separation leans on arrival order. Whether real seasonal load breaks it is something you observe when the season comes. An acceptance scenario is therefore an opening rather than a closing: set a review date for after the season on the day you sign.
Why the separation is a design decision in its own right is written in the article on separating appointments and service requests. A business whose site takes a single kind of request has no separation scenario. What gets tested there is whether a request from that one form reaches the right person.
The scenarios side by side
Read together, the scenarios take the form the list has on acceptance day. Every row carries the same order: the action taken, the difficulty the system carries, what a single-sided demo fails to show, and a passing condition written as the state of the record. The last column is why the table exists. A passing condition not written as the state of the record ends up attached to an impression, and impressions on acceptance day are uniformly positive.
| Scenario (the action) | Difficulty the system carries | What a single-sided demo does not show | Passing condition (state of the record) |
|---|---|---|---|
| The technician edits a field of the record out of signal while the office edits a different field from the panel; the connection returns | A technician on site and a colleague at the office can edit the same record with neither aware of the other | Run from one side, the clash never occurs; with nobody on the other side the fault is not produced | A single record; each field at its new value; no duplicate |
| A payment of a known amount is posted under the neighbouring institution; the monthly report is pulled before and after | A student, parent or payment record must never cross the institution boundary | The neighbour’s record staying off your list screen; the figure being added up is never tested on a screen | Your report’s total is unchanged; the amount sits only in the neighbouring institution’s report |
| A survey booking and a service request are opened from the site back to back, in scrambled order | A survey asks about a location, a service call about a unit already in place; they are not the same form; a season opening buries one under the other | The “sent” message; the operations side is not opened during a demo | On the operations side the requests sit in separate flows, in writing; arrival order does not disturb the separation |
The third column records not bad faith on the vendor’s part but the limit of the format. The vendor can read the same row and see what needs preparing before acceptance day.
The person doing the work picks the scenario, and acceptance closes on a scenario record
Who owns the acceptance session is usually settled by looking at the contract. Wrong place. The scenario is picked by the role that knows where the record can go wrong, and that knowledge lives in the work rather than in the contract. Which field of a record entered in the field also changes from the office is known by the technician and the colleague at the office. Which total in the monthly report is watched, and by whom, is known by the institution’s administrator. Who gets phoned when a request lands in the wrong flow is known by the operations desk. None of it can be handed over, because none of it is written down anywhere.
The vendor’s job is to prepare the ground: a neighbouring tenant definition, an extra account, a device that can be taken out of signal. At Vipkurum a further institution is added as a tenant definition rather than a fresh installation, which is why the test environment can be ready by acceptance day and why “we cannot set that up” stops being an acceptable answer. Preparing the ground and picking the scenario are different jobs. Confuse them and the test tours the places the vendor already knows, which is simply a longer demo.
The output of acceptance is a record rather than an impression. For each scenario you write the action taken, the expected state of the record and the observed state. Where expected and observed agree, the scenario is accepted. Where they do not, the scenario is dated separately, outside the acceptance; a line that has not closed does not join the list as though it had.
The vendor may propose a scenario, and the proposal may be a good one. The test is simple. If it maps onto a difficulty line, put it on the list. If it does not, the proposal is showing you something the vendor can show; that may be useful, but it does not close acceptance. The choice stays with you.
If you want the acceptance scenario built from the place the record is actually created, look at how business process tracking binds that record and what is left of it once someone in the field and someone at the office have each touched it.
