Created software, like any other product, should be subject to quality tests. They allow the authors to find possible errors and correct them, and they give the clients a guarantee of reliability of the tools they pay for. Unfortunately, the testing process is time-consuming and requires additional work, so in many companies it is reduced to the absolute minimum, and sometimes it is not introduced at all. It is often assumed that by hiring people with proper qualifications, you will get a high quality, properly working solution.
Below I will describe a very popular situation, which shows the obvious truth that even if two programmers do their job well, integration of their solutions without testing the final solution may end up with a badly working application.
1 plus 1 does not always make 2
Starting from the end: late in the afternoon my boss calls me and asks if I remember a module that I wrote half a year before, because it doesn’t work for one of my clients, in fact he can’t see it in the system. Since it was quite a big, although not the most important functionality, I remembered a bit, but it had been too long for me to recall all the details.
I started checking and indeed there was nothing of my module in the production version of the system. No trace was left either in the interface or in the code. On the other hand, the database migrations were done. The next step was to look through the git history and here a mistake appeared, because shortly after my changes, a more experienced teammate finished working on his task, and the code that we created in each other’s branches created a conflict. The person responsible for merging the branches to dev and then to production dumped my code, apparently thinking that the changes of the more experienced person are more important.
Six months without functionality
It seems that such a case can occur in almost every team, where several people create different modules in parallel and it wouldn’t be a big problem if this bug was detected quickly. However, in this company the tests were performed once in a while by several people who spent their weekends to manually re-cross the project according to the assumed user scenarios. The non-critical module was probably not analyzed and the fact that it was not in the system for half a year was noticed only by one of the clients.