Let’s play a quick game of word association: what comes to your mind when I say “TSB”? If you’ve been reading the news, then chances are your responses might include “expensive,” “disaster,” or perhaps “fine” (but not the good kind). But there’s another phrase that it may surprise you to find is relevant: “personal liability”.
In this article, I’m going to explain how taking a close look at the way software testing is done in your organization could keep you safe from some serious personal consequences.
A quick roundup of the crisis in question:
In case you’ve not been keeping up with your IT news, here’s a recap of the story:
- Back in 2018, TSB cocked up an IT migration in a big way. Customers were locked out of their accounts, and when they got access again, many users found they couldn’t see their information – but they could see other people’s personal financial records and information.
- In December 2022, TSB was fined £48m for “widespread and serious failings”. In total, the scandal has cost TSB over £400m.
What you may not have seen is that, in April this year, the Prudential Regulation Authority (PRA) handed down a fine of £81,620 to the ex-CIO of TSB personally, for his role in the crisis. The implications of this for any C-level executive involved in large IT projects are clear: if the project goes wrong, there’s a chance that you could be held personally responsible. Is it hot in here or what?!
What’s this got to do with testing?
The report from the FCA and PRA concluded that the crisis was caused in part by a lack of software testing, as well as poor governance and control of the process. This was compounded by the fact that the migration was carried out by a third party – who in turn relied on several fourth parties – and the ex-CIO’s personal liability came from poor management of these parties, including taking at face value the assurances from these parties that there were no problems with the software.
With this in mind, I’m making the argument that, for C-level execs looking to ensure they are maintaining the requisite level of oversight and control over the process, software testing is a great place to start.
The role of software testing in keeping control
There are two main reasons to start with software testing if you’re interested in maintaining control of your IT transformation. Firstly, it’s the gatekeeper between your development processes and the outside world. If software passes testing, it’s deemed fit for release – meaning that, if there are problems with the software upon release, it’s going to be very hard to demonstrate that you have control of the process.
Secondly (and unfortunately), software testing is often not as well-organized and managed as the development side of things. In particular, testing whether your business processes will still work with the new software is often run through a mess of spreadsheets, screenshots, and saved emails. Even though it’s one of the most important steps in any IT migration, it’s one of the worst-run – but, on the positive side, that means there’s the most room for improvement!
When done well, software testing in a migration scenario should:
- Document and test every single business process that the new software touches .
- Be automated where possible (primarily regression testing – making sure that new or changed elements don’t break .processes) .
- Be managed from a central system to give a complete overview of testing progress and results .
- Make it easy for business users to conduct manual testing phases such as UAT .
- Connect with your dev environment so that issues flagged during testing can easily be passed to developers and tracked through to resolution (including retesting) .
- Allow third parties to work in the system alongside in-house teams, giving you a view of what everyone on the project is doing, regardless of where they work .
- Give you a complete audit trail of everything that’s happened .
That last point is especially important because not only does it help you monitor your software testing properly, it shows other people that you’ve got control of the process, which can be important if something does go wrong. Though, of course, if you have got control of the process, then nothing should go wrong. But still, you know. Better to be safe than sorry.
How do I implement this in my organization?
An audit trail allows you to review what happened last time you ran your tests – so if there were any issues, you can start to diagnose them and improve your processes for next time. Plus, if your audit trail is comprehensive, you can use it for root cause analysis should any of your tests fail.
Even better, by using Original Software you can:
- Speed up testing cycles, helping you migrate faster without increasing the risk of business-breaking bugs
- Reduce the amount of time business users spend on testing, making their lives better and dramatically reducing the cost of UAT
- Be confident that you’re catching as many bugs and issues as possible, giving your business better quality software to work with
Hopefully this blog has shown you the value in looking at your testing processes, if you have ownership of an IT migration project for your organization. If you’d like to improve your organization’s testing processes and make sure you steer clear of any life-altering fines while you’re at it, we’d love to talk.
