To keep up with faster turnaround times and shorter software development cycles, it is often easy to fall into the trap of leaving the development team to power through code writing, churning out product for the testing team to check for bugs and defects. Picture the Silicon Valley caricature of developers in their basements writing line after line of code with no window to the outside world.
The truth is, however, that it’s actually more efficient and cost effective to get the developers involved in testing the software as they go, rather than working in a vacuum. Relying on test engineers, who didn’t write the programme in the first place, to wade through thousands of lines of code, find problems as they manifest themselves and fix them not only places a huge burden on their shoulders, but also ends up taking longer. It also costs more and can compromise the quality of the product. If you wait too long to test the software, the best case scenario is an expensive re-coding job. The worst case scenario is a buggy software release resulting in dissatisfied users and a potentially brand-damaging PR nightmare for your business.
Testing early and often means that bugs, hiccups or defects of any size can be highlighted and fixed as part of the development process, improving the quality and security of the software and saving valuable time. I often use the analogy of owning a house when addressing the issue. Once you’ve invested your savings into purchasing a property, you don’t want to wait until it starts falling apart to fix it. Instead, you maintain it as you go, making small fixes as needed: re-painting walls and window frames every few years, oiling hinges as they start to squeak and checking the source of dripping taps or leaks when they appear. This is much easier — and cheaper — than dealing with rising damp, structural damage or burst pipes due to neglect or a lack of maintenance.
Testing the code early and often throughout the development process means that the developers writing the software can identify potential bugs more easily, putting them right as they go. It’s much easier to get your head around a potential defect if you find out about it when you build the software and it’s in your current thinking than someone asking you to delve into some code several months after it was written. Of course if that developer has left the organisation and you have a new developer on staff that just compounds the challenge. The good news is there are tools that can help with this finding potential defects and issues at compile time. You can read our blog on ‘Tooling up’ here to learn about static analysis tools such as CodeSonar that can help you implement code testing into your development process to test early and test often.