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, 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 examine the way software testing is done in your organization, and how it could keep you safe from some serious personal consequences.
What happened with TSB Bank?
Back in 2018, TSB Bank mishandled an IT transformation 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. When it came to public attention 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 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?!
How does this relate to testing?
The report from the FCA and PRA concluded that the crisis was caused in part by a lack of software testing, alongside poor governance and control of the processes. 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. This mismanagement unfortunately included taking assurances from these parties that the software had no problems at face value.
With this in mind, I’m making this argument for C-level execs: software testing is the best place to start if you want to ensure you’re maintaining the requisite level of oversight and control over processes.
Software testing and 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, 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. 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. On the positive side, however, that means there’s plenty of room for improvement! When accomplished well, software testing in a migration scenario should be able to document and test every single business process that the new software touches. Worth noting is what exactly will be automated, with most processes being automated where possible. This primarily focuses on regression testing to make sure new or changed elements don’t break any processes.
The whole testing scenario will be managed from a central system to give a complete overview of testing processes and results. From here, it’s easier for business users to conduct manual testing phases, such as UAT. The very nature of the testing system allows it to connect with the dev environment, which makes flagging issues during testing a much easier procedure to deal with; the developers can easily identify the issues and track the problem through to its natural resolution, where additional testing will be conducted.
Third parties will also be allowed 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. Finally, the documentation of the testing system will leave you with a complete audit trail of everything that’s happened during the procedure.
The 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, 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 – 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.
Make sure you choose the right software to implement with your organization. Depending on the program you choose, you could get access to sped-up testing cycles, reduce the time users spend on testing and be confident that bugs and issues will find it hard to make their way through your digital net.
Hopefully, my thoughts have shown you the value in looking at your testing processes if you have ownership of an IT transformation 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.
