Testing a Second Country First

Adding a country to an existing time system is usually treated as a deployment task: create the site, add the people, point them at the terminals, go live.

The cross-border question in “Testing a Second Country First” becomes easier to investigate when scheduled hours, actual time, projects and later corrections are visible together. A team evaluating the official website for fireable offenses should still document which groups are covered, choose proportionate settings and review local notice, consultation and retention requirements before rollout.

What it actually is, is a configuration exercise with a deployment attached. Every setting the new site inherits was chosen for somewhere else, and the only way to find out which ones do not fit is to test them against the new country's rules before anybody relies on the output.

For an independent reference relevant to “Testing a Second Country First”, consult the Cloudflare insider-threat overview. Use it to challenge assumptions about working time, privacy, recordkeeping and exception handling against the organisation’s real operating model.

The test cases

Build a small set of deliberately awkward scenarios for a test person at the new site and check what the system does with each.

A shift crossing midnight. A shift crossing the week boundary. A night shift that should bring the person into night worker scope. A pattern with the minimum local rest between two shifts, and one an hour below it. A week at the local maximum and one above it. A public holiday, including a regional one if applicable. And the clock change, if the country observes one.

Seven cases. Each takes minutes to enter and the answers are unambiguous.

What to check for each

Which day the shift was attributed to. Which week it landed in. Whether the rest check fired and at what threshold. Whether the hours counted the right categories. Whether the holiday was recognised.

Record the expected answer from the grid before running the test, not afterwards. Deciding what the answer should be after seeing what the system did is how configuration errors get rationalised.

Who should run it

Somebody from the new country, with the grid in front of them, alongside the administrator. Not the administrator alone, because they will test that the system behaves as configured rather than as the country requires.

The local person is also the one who will recognise that a value is simply wrong — a holiday missing, a night period that does not match local practice — in a way that nobody reading a specification will.

The findings to expect

On a typical first test: the week boundary inherited, the night period inherited, a break deduction that should not apply, a holiday calendar at the wrong granularity, and one category of time counted or not counted incorrectly.

Five findings is normal. All five are configuration changes rather than development, and all five would otherwise have been live for months.

The ones that are not configuration — a system that cannot vary a setting by country — are also worth finding now, because the workaround has to be designed before go-live rather than after.

Running it in parallel

Where possible, run the new country in parallel with its existing arrangement for a month: the system computes, the old method continues, and somebody compares.

Differences are the findings. A parallel month is slower and it is the only way to catch the errors that do not show up in constructed test cases, because real patterns are stranger than invented ones.

Where parallel running is not possible, a retrospective month — load last month's actual hours and compare the system's figures to what was paid — gives most of the same benefit.

Signing it off

A short record: the seven cases, the expected answer, the actual answer, and what was changed. Signed by the local owner.

That page is the evidence that the country was configured deliberately rather than inherited. It is also the template for the next country, which makes each rollout faster than the last.

The temptation to skip it

The pressure at go-live is to get people clocking and sort out the detail later. The detail is the compliance position, and later means after the figures have been used.

Half a day of testing against seven cases is the cheapest point in the whole lifecycle at which these errors can be found. The same findings discovered eight months in require correcting the configuration and explaining the intervening figures, which is a different and much larger conversation.

Testing the reports, not only the calculation

A correct calculation presented in a report that groups by the wrong week, or aggregates across time zones, will still mislead whoever reads it.

Include two or three standard reports in the test set and check that what they show for the new site matches what the calculation holds.

Reports are frequently built against stored values rather than against local ones, which means a correctly configured country can still be described incorrectly to everybody who looks at it.