Testing through the Credit Crunch - Part 1 - Development Environments

The credit crunch has gripped the world and not so long ago Gartner suggested that the investment in technology was going to drop. They have dropped the increase in spending from 5.8% down to 2.3%. This may not seem a lot but when companies spend millions on IT each year it adds up very quickly. Unfortunately past experience has shown that testing departments are the ones who suffer first.

More employers are predicting a rise in redundancies in the UK and the other week a politician predicted a run on British Pound.

This doesn't mean all doom and gloom for IT professionals. Over the next few weeks I am going be writing a series of posts with some best practices that I have found. Lets start this series by discussing the Environments we build and test software.

Environments

This is a very ambiguous term so lets split it into the 2 main things I mean. Development Methodology and Testing Environments.

Development Methodology

When creating products it is starting to become common practise to follow Total Quality Management (TQM). The idea is to make sure that quality is in every process of the organisation. By moving to your company to this principle you will be adding confidence to your product to all stakeholders. More confidence in your stakeholders will mean that your department will get a little more funding and since its the credit crunch it must be good!

A lot of companies actually practise this without realising it. The main thing to take away from TQM is that everyone in the company has a part to play in the quality of the product that is delivered!

Agile or Not!

My first few jobs were at financial institutions and thought it was normal to do testing at the end. I worked as a WinRunner Automated Tester. I then started working on some Open Source projects in Java and was asked "Can we see your unit tests? Did you use JUnit?".
I answered quite sheepishly "I tested it by checking that it did what it needed. I don't have any JUnit tests."

Obviously my code got rejected because it wasn't neat and didn't have proper unit tests. There was a few other issues that they raised and to be honest if I was doing the code review I would have rejected it too!

Now I work for an ASP/ SaaS and we do a little Agile. I have been able to see the value of being agile while developing software. The main thing that I have learnt is that Technical/Design debt is something that is inherently low in an Agile Evironment.

Technical debt is the idea that when you release software you go into debt. If you have cut corners it will affect the level of debt you have. If you leave these items in your code it will start gaining interest on your debt. So if you have any TODO's in there that is interest on your debt. If you have poorly designed interfaces then you have added interest on your debt. Putting testing at the end of a project will definitely add interest to your debt! Doing tests at the beginning of the development process will bring down the "interest" accrued against your debt in the development process.

So to help us get through this credit crunch we need to bring down the debt in our software. The best way to do this in my opinion is to achieve this is to move your development team to a Test Driven Development way of thinking. As I said above if you place your tests earlier in the process you will lessen your technical debt. The simple rule when it comes to testing is the earlier you test the cheaper it is to solve bugs. So putting in automated tests at the beginning of the development process will go far in bring down your actual development costs for that project but also for future developments.


In the next post I will discuss further the value of Test Driven Development.