Whilst I was looking for something else I found an explanation I wrote years ago to try to explain to senior management how testing had changed and become critical in the Agile environment. It’s not the easiest thing to try to get across: the business wants features that it can sell. I don’t think I did a bad job, so here it is.
Having now spent a few months with this project I’m very conscious that, at the moment, we don’t have much of a testing strategy. It looks as if we’re trying to offload all responsibility for testing onto the testing department.
This rather implies that our primary testing strategy is manual system testing.
Failed system tests are expensive – and if they impact promised delivery dates they can be a major problem. It would be better if we could have a good idea before we entered a system test whether or not it’s going to pass and that is a software quality management problem.
(Technical) testing should start in the software design. The questions the developers should be asking are;
- How am I going to achieve this task?
- How am I going to test it?
As an example, user interfaces are notoriously difficult to test, but if one of the MVC style design patterns is used it means that the view (the actual UI) can be separated from the rest of the code. This means you can write a program to test the logic behind the UI without having to try to actually click buttons programmatically.
There are any number of places within the design of software where adding a little thought to how it can be (easily or preferably automatically) tested is of significant advantage.
The more automated testing we can get in the better. If we can get to a position where a substantial portion of the code is automatically built and tested every night that would be great. It means that we, as developers, get continuous feedback about the state of the software.
We can then go into a system testing phase with a much higher level of confidence that it will pass.
This does mean however that we need to start investing in testing, which can be a difficult message to get across. If we don’t however then as the software and the functionality grows and the code-base becomes more difficult to maintain we will be taking ever increasing risks with the future of the product.
It’s a good idea to get this baked in now.
I would suggest that a feature is not finished unless the issue of how it is going to be tested is solved – and that means the automated tests and / or the manual tests written. If there’s no automated testing there needs to be an explanation of why.
The more bodges, work-arounds and spaghetti code there is, the harder it becomes to maintain and the longer it takes to develop each new feature. A product which leads the market can very quickly fall behind because every time someone tries to do something they have to try to unravel all the spaghetti, they then inevitably end up piling on more spaghetti just to make it work and making it worse for the next edit. Technical debt snowballs.
As with all things there’s a balance, I’m conscious we need to get features to market fast, but as the product matures the importance of testing will increase. Automated unit testing ensures that each building block of the project actually does what we think it should do. It’s not a silver bullet for solving all technical debt, but it’s a good starting point. Making code testable enforces certain good behaviours that will increase the longevity of the product.
I do not believe that the current development strategy is sustainable. I am therefore intending to phase in a plan that will, in time, see all new development covered by automated testing and will start to retrofit automated testing into the existing code-base. Inevitably this will slow down the speed we can get features to market, by a known and controllable overhead. Our business model is based on repeat business. If we fail to get a grip of technical debt the competition will overtake us in the mid term and it will invalidate that model.