Back burner

Another day, another scandal in the wonderful world of UK commerce. This time, it’s “back billing” by energy companies. This is the practice of issuing bills for energy consumption which date back over a year.

The UK energy regulator, Ofgem, outlawed this practice seven years ago. And yet, in recent months there has been a spate of back billing incidents. Customers contact their energy company, only to be told that the bill must be paid within a matter of days, or dire consequences will follow. The Energy Ombudsman apparently now has received some 3000 complaints about this practice in the last two weeks.

The CEO of the industry’s trade body, Energy UK, was interviewed on the radio earlier today. She could not offer any convincing explanation for why this was happening, although she suggested that there might be some yet undisclosed “systemic issue” accounting for the practice. (That call centre staff are doubling down on these bills being legitimate means that any such “systemic issue” extends into human systems too, but that’s beyond our scope here.)

There has to be a testing dimension to this. It is one thing to have a client define a specification for a billing system; but have they remembered to include all the relevant legislation that governs billing situations? And it’s no good going back to the Product Owner, only for them to dismiss the objection; we have yet to see all the fallout from the Post Office Horizon scandal, but I suspect that “the Product Owner told me not to worry about that” won’t be an acceptable defence in a court of law. After all, it didn’t work for “I was only following orders”.

Even if an application has been purchased as a package, standing it up on your network or servers should involve a phase of acceptance testing. That is a good place to remember to review legal compliance, especially if the application has been purchased from outside your jurisdiction. In such instances, it would be sensible to check for compliance with local or national legal requirements.

If your system operates within a legal framework, testers have to know and understand those frameworks, and make certain that systems comply with legal requirements. That may be specific sectorial regulation, or it could be something as basic as contract law or even something set out in primary legislation or a Constitution (for those countries that have them). This may be more of a Business Analyst role rather than a direct software testing function, but it should be part of a test plan, even if the expertise to carry out initial compliance testing isn’t within a test team. Yet making an application legal will ultimately involve coding: “If a bill is more than one year old and no previous bill has been issued, then a bill should not be issued but it should be flagged up” is a coding specification and that code needs to be right.

And remember: the wheels of Law grind exceeding small, but eventually the Law will catch up.