Software bugs are annoying – for users and software manufacturers alike. The latter, however, should use bugs to continually improve the software, preferably from the beginning of development. Nevertheless, there will probably never really be flawless, right? Rather a philosophical question.
The history of software programming has also been shaped by software bugs. Of course software bugs are also a cause for trouble – especially if any bug is harmful, costly or has other unpredictable consequences.
But that does not mean we cannot learn from each bug. Each analyzed and fixed bug gives us the opportunity to learn about what went wrong. This learning process can help us to avoid bugs in the feature. The learning process helps to find other similar undiscovered bugs in other softwares too.
Here are two general ways to find software bugs:
- The first one is to look at the source code of a program, analyze each step and check if we can find source code patterns, that may be problematic. (Either by hand (software review) or to some extend also automatically.) For example we can check if we find any source code patterns in the code that are similar to source code patterns that have proven to be problematic. To some extend finding and analyzing such patterns is already done by the compiler. This is why we should take compiler warnings seriously.
- The other way to find software bugs is to simply execute the program/program-parts and test whether the program (under certain circumstances) crashes or shows an unexpected behavior. Once an unexpected behavior gets noticed, the bug needs to get analyzed and fixed. An observation here is that while fixing a bug it is also possible to introduce new bugs into the code. This wired connection between the debugging/fixing effort and the number of bugs in the code is also represented in the ‘Programmer’s Drinking Song’:
99 little bugs in the code.
99 little bugs in the code.
Take one down, patch it around,
127 little bug in the code…
So we are not only testing in order to find new bugs but also in order to ensure that once fixed bugs stay closed. But this means that – whenever the source code gets changed – every test case/test step needs to get redone. When this is done by hand, this may be a pity, boring and time consuming step. With a specialized software – like QF-Test – we can automatize our test steps.