Release assurance for a Unit4 payroll upgrade: scripts, parallel runs and defect triage

Most upgrade programmes start by writing test scripts. That is already the wrong start, because the scripts are then written to the release rather than to the payroll.

A master script library is written to the payroll. It covers pay and deduction elements, value references, absence, work schedules, learning and expenses, and it is maintained between engagements so a new release starts from a proven baseline rather than a blank page. With a library, the question at scoping is which existing scripts this release puts at risk. Without one, the question is how many scripts the team has time to write, and the answer is always fewer than the payroll has routes through it.

Coverage is then organised by process area, not by screen. The set runs from position administration, applicant, starter, induction and probation, through absence, occupational health, leaver and contractual change, and on to student loans, voluntary deductions, variable transactions, back pay, overpayments, pensions auto-enrolment, payroll reversal, cost distribution and court orders. A release that touches the payroll engine touches most of that list, whether or not the release note says so.

Above the library sits the test strategy, and it is written first: entry and exit criteria, phase structure for integrated system testing and user acceptance testing, and the standard templates that make evidence comparable across phases. One upgrade acceptance programme in local government ran phased execution across sixteen HR and payroll process areas on exactly that structure, with the strategy and the script libraries authored before execution began. Read that engagement in full.

A parallel run is a comparison, and a comparison is only as good as the rules written before it starts.

Those rules are part of the test strategy, not an operational detail settled on the day: the validation rules that define a match, the reconciliation checkpoints at which totals must agree, and the rollback criteria that say in advance what result would stop the release. Settle them before a single record moves. Agreed afterwards, they drift toward whatever the run produced.

Design then turns on three choices. The first is the period. A run over a quiet month proves a quiet month. Choose one that carries the events the release touches: a pay award with back pay, a sickness case crossing from full pay to half pay, a court order, a leaver with a final calculation, an auto-enrolment assessment. The second is the population. Run it pay group by pay group rather than as one merged file, because a merged total can net two errors in opposite directions to zero. The third is the expected answer. Every comparison needs a known-correct value from the legacy calculation, held separately, and compared to the penny rather than to a tolerance somebody invented under time pressure.

The last piece of the design is a written statement of what the run does not cover. Every parallel run has a boundary. If the boundary is not written down it will be read as proven, and that silent inference is what puts a defect into live running.

The lifecycle itself is not the hard part. Identification, triage, severity categorisation, assignment, fix verification, closure, tracked in whatever issue tracker or service desk the programme already runs. Any mainstream tool does this adequately.

Severity is the hard part, because on a payroll release severity is not a measure of how annoyed anyone is. Order it by what the defect touches: a payment to an employee first, then a statutory submission, then a deduction owed to a third party, then a report. A defect that under-pays a small group once a year outranks a defect that irritates a large group every week, and on a queue sorted by age or by volume of complaint it will lose to it every time.

Two disciplines keep the queue honest. Triage in a room, live, with the person who can reproduce the behaviour and the person who can read the configuration looking at the same screen. Tickets exchanged across a service desk turn a half-hour diagnosis into a fortnight. And define the retest scope at the point of fix, not at the point of closure. A payroll fix is a configuration change, and a configuration change on a shared element can move a value on a population nobody was thinking about. Regression validation around each fix is what separates a release with no critical defects outstanding from a release where the critical defects have simply not been found yet.

The release is finished when the evidence pack is finished, not when the last script is marked green.

A usable pack holds five things. The strategy that was agreed, so a reader can see what was promised. The execution record, script by script, with results and dates. The defect register with discovery and fix rates over time, because the trend tells a board more than any single total. The residual position: what is still open, at what severity, and what compensating control covers it for the first live cycles. And a recommendation, stated as go or no-go, with the reasoning attached.

That pack does two jobs. Before the release it gives the board something to decide against. After the release it is the only durable record of why the decision was reasonable, and it is still readable when the people who ran the programme have moved on. A dated cadence of defect status reporting through execution is what makes it credible, because a pack assembled in the final week always reads as assembled in the final week.

At an international organisation, payroll, absence, expenses and timesheets were unproven, and there was no evidence base on which a go-live could be signed.

The assurance work was built in the order set out above. Parallel runs were designed and executed to compare new-system output against the legacy calculation for every pay group. A defect register was maintained with resolution rates reported to the project board, so the trend was visible rather than asserted. A test completion evidence pack carried a quantified residual risk assessment into the decision itself.

The runs proved calculation parity across an estate of over 2,500 employees, and the go-live decision was taken against quantified residual risk rather than an untested assumption. Read the engagement in full on the case studies page.

• Read the Embedded Intelligence Method. How a test strategy, an execution record and a post-change validation are produced as one evidence trail rather than three separate documents.
• See the services. Test strategy authoring, script library build, parallel run design and defect management, taken as a defined piece of work or as embedded support through the release.
• See how a payroll was proven against an estate of over 2,500 employees. The parallel run, the defect register and the evidence pack behind a go-live decision.