T-Minus: testing and the rehearsal
The six test layers and when each runs, testing roles and segregation of duties, designing and running the rehearsal, the go / no-go criteria, and defect triage by severity.
There is no separate test phase. Each layer runs when its object is ready, and the rehearsal is the UAT. Because the platform is standard, testing focuses on the customer’s configuration, data and integrations — never on re-testing the product itself.
| Layer | What it proves | When | Who | Evidence |
|---|---|---|---|---|
| Configuration checks | Each configured setting, verified with sample data in the session | T-17 → T-11 | Key users, Ledger Architect | Test Plan result per Fit Ledger line |
| Migration validation | Counts, hash totals, TB and sub-ledger reconciliation per mock | T-10 → T-3 | Migration Conductor, data owners, finance controller | Object register, reject list, reconciliation sheets |
| Integration tests | Every endpoint with test partners, error paths included | T-10 → T-4 | Ledger Architect, partners | Message logs |
| Role & permission tests | Each role sees and can do exactly what it should; SoD checks | T-9 → T-5 | Key users, Adoption Navigator | Role test results |
| Continuity check | A switchover drill if Live DR is contracted; a backup-restore proof | T-5 → T-3 | Ops Pilot, Migration Conductor | Runbook timings, drill report |
| The Rehearsal = UAT | A real business day by the real users, in parallel with legacy | T-2 → T-1 | Every T+1 user | Rehearsal script, gate record |
Every Fit Ledger Configure-now line has at least one configuration check with its result, so the T-11 gate is a filter, not a meeting.
Roles, permissions and segregation of duties
| Each role can… | Each role cannot… |
|---|---|
| See only its entities, data and menus | Approve what it created — enter and approve the same invoice |
| Perform every step of its rehearsal tasks | Create a vendor and pay it |
| See the right items in its action queue | Change bank details and release payments |
| Use ASK for its own tasks, under its permissions | Post to closed periods or edit posted documents |
Test with each role’s own login, never with an administrator account. A test passed as admin proves nothing about the role.
Designing the rehearsal (illustrative)
One complete real business day: the customer’s own transactions, in their own roles. Build the script from the customer’s busiest normal day, not a textbook flow.
| Time | Process | Role | Real transaction | Compared with legacy |
|---|---|---|---|---|
| 08:00 | Morning queue | All users | Ranked action queue reviewed | — |
| 08:30 | Quote to order | Sales | Today’s quotes and orders, credit check | Order totals |
| 09:30 | Procure | Purchasing | Purchase orders, approvals | PO totals |
| 10:30 | Receive | Warehouse | Goods receipts, put-away | Stock movements |
| 11:30 | Ship & invoice | Warehouse, billing | Shipments and customer invoices | Invoice totals |
| 13:00 | Payables | AP clerk, approver | Vendor invoices, matching, approval | AP ageing |
| 14:30 | Payroll events | HR | Hires, changes, time, allowances | Payroll inputs |
| 15:30 | Cash | Treasury | Payment run, bank file, receipts | Bank balances |
| 16:30 | Day close | Controller | Daily reports, trial balance | TB for the day |
Running the rehearsal
| Prepare (T-2) | Run (T-1) | Close (T-1 evening) |
|---|---|---|
| Rehearsal tenant from the dry-run data | Users enter their real day in TRANXACT | Results compared with legacy |
| Today’s real documents collected | Legacy runs the same day as normal | Fix list executed and re-checked |
| Every user logged in, queue live | ASK and Navigators support in the flow | Gate criteria scored |
| Observers per process | Issues logged with time and role | The Countdown Owner decides GO |
Every person who uses the system on T+1 takes part. Anyone missing gets a scheduled catch-up on T-1 afternoon and is flagged in the adoption register. The rehearsal is also the training: users who have run their real day do not need a classroom, and the business signs off on evidence rather than a document.
The go / no-go gate (proposed default)
| Criterion | Threshold | Evidence | Blocks go-live? |
|---|---|---|---|
| Rehearsal processes passed | 100% of critical, 95% or more of all steps | Rehearsal Script | Yes |
| Rehearsal results match legacy | Totals equal or explained | Comparison sheet | Yes |
| Dry-run reconciliation | Zero TB delta; sub-ledgers tie | Reconciliation sheets | Yes |
| Dry-run duration | Within the cutover window | Runbook timings | Yes |
| Critical defects open | 0 | Test Plan | Yes |
| Users rehearsed in their own role | 95% or more of T+1 users | Adoption register | Review |
| Integrations production-ready | Endpoints and credentials confirmed | Integration log | Scope out if not |
A NO-GO is not a date slip by default. The Countdown Owner can take failed scope out to T-Plus and still go live on T-0 with what passed.
Defect triage (proposed default)
| Severity | Meaning | What happens |
|---|---|---|
| Critical | Stops a core process, a wrong financial result, or data loss | Fix before the gate, or take the process out of scope to T-Plus with a manual interim |
| High | The process works with significant effort or a workaround | Fix the same day during the countdown; retest in the rehearsal |
| Medium | Inconvenient, with a simple workaround | Fix within the first two weeks after go-live |
| Low | Cosmetic or nice to have | A Fit Ledger line tagged T-Plus |
Triage in the standup, not in a ticket queue: every defect gets an owner and a same-day or T-Plus decision in the meeting where it is raised.
Values marked proposed default are the methodology’s recommended starting points. Confirm each one per engagement; the contract, order form and SLA prevail.