In Part 1 of this blog post, I explored what Legacy Software is and how to recognise the signs that it's going to start costing your business a lot of money.

In this part, I'll discuss safety using tests.

Where do I start?

This is often a massive hurdle, to the point where the effort involved is enough to put management off. This has to be done though - you need to be able to prove that the last time you used this piece of functionality, it actually worked!

Utopia would be a set of automated tests that you could run in a couple of minutes that would prove everything still works in a dev instance and then just reset the content back to a known state. I will be completely honest, I have never in my 20-year career seen this happen. That's not to say it can't however!

Types of tests

There are several types of test that can be used to prove that a piece of software works.

• Unit Tests - quick, automated and written by the developer when they are creating the code
• Integration Tests - automated tests that confirm the functionality of the combination of the code and dependencies (like the database)
• Manual Tests - a set of steps that someone can take to confirm the functionality of the software.

Depending on your resources, you should probably have all of these in place. However, in my experience, resources are limited and we need to start to see some progress quickly, so we should make a start on some Manual Tests. Unit and Integration tests are important too but these require some kind of continuous delivery mechanism to really make the most of them, so we will discuss these later.

What do I need to get started?

Before you get started, you'll need a few things

• An instance of the software to test. If you can create a copy of your environment somewhere else, then that's the ideal scenario - if not, you will be testing against live. It's not advised, but you have to start somewhere!
• A bug database - we use JIRA to record issues, and the steps to replicate them. This means we can find them again if they recur and it also allows us to communicate the issues to the people fixing them. If you don't have a budget for JIRA, why not use Trello?
• Testing Software - we use X-Ray integrated into JIRA, but if you are limited, then by all means, start recording tests in Excel.
• A high-level matrix of the parts of the system that you need to test. This gives you some idea of the coverage of the tests you've created.

There are many other options out there for tooling - see if your organisation has something in place already.

I'll explore the first three of these things in future blog posts.

Let's Start Testing!

How you approach testing will be different depending on the software under test. It might be worth speaking to your users a little to see which bits they think they've seen bugs in.

Your goal here is to find the high priority parts of the system that you think might be weaknesses and get some tests around them to ensure that there is some coverage. Mark these in your high-level matrix to prioritise where to focus your testing.

Once you've got some manual tests together, start to record your issues in your bug reporting software.

Once you have a decent suite of tests together, then you can feel a little happier about making changes to improve the software - you finally have some safety

Next Steps

Next, I'll explore the need for continuous delivery as early as possible, and how we can get these Unit and Integration tests included in your workflow.