Why is software testing taxing? Why do companies get it wrong?

Why does software testing takes a lot of effort? Why do people get it wrong?

Why is software testing taxing? Why do companies get it wrong?

I think we will struggle to find anyone in this world who has not been effected by a software bug either directly or indirectly. The latest company in the news in this regard is HSBC UK. Their personal and business baking platforms went office for more than 24 hours effecting millions of customers.


So what is it about software testing that even the might of companies like HSBC, Natwest, Microsoft, etc. cannot solve? If companies like HSBC can’t get it right, then what chance do the SME and small software development team have with their limited resources when compared to the big boys?


First, let’s understand what a software really is. A software is nothing but a many (tens/hundreds/millions) lines of computer instructions which are dependent on each other and are executed on top of hardware (Desktops, Mobiles, Hardware drive, RAM, Network cables) and other software (browsers, operating system, etc.). If you think about it, even a simple software which adds two numbers, depends upon hundreds of line of code when we take into account the underlying hardware and software it executes upon. To complicate this further, the hardware and the operating system are constantly updated. In summary, lots-n-lots of moving parts which are constantly replaced, changed, enhanced or even removed. If any one part fails to perform its function, it can have a domino effect on any software dependent on it directly or indirectly.


To ensure that software is 100% bug-free, a software development company will not only have to test every single line of code written by them but also test the underlying hardware and software, which in practice, means looking at tens of thousands/million lines of code. It’s not that this cannot be done, it’s just that it won’t be economical and every software will be very expensive.


The best approach here is to have a testing plan like a storyboard which is as close to real-life software use as possible. For example, ‘Create customer->set credit limit-> place order below the credit limit -> place order above the credit limit’ and clearly define what is expected behaviour. Taking this approach ensures that all core business functions are tested before the software can be used in a production environment.


Also, over the years, the software industry has come up with several testing frameworks and coding best practices which ensure that the impact of any software bug is limited and is confined to a section/feature/function of the software.