Your website or your mobile application is full of bugs and you don't know what to do? In this article, we explain the different causes of bugs and what techniques to put in place to prevent them as much as possible.
Once upon a time, there was a bug, and then another one, and it goes on and on, it's only the beginning, right, right. Not a week goes by without you discovering a new bug on your website or mobile application. And honestly, you're not far from tearing your hair out. You don't know what to do to manage them. Let's face it: a website or a mobile application without bugs doesn't exist. It's a myth. Or at least, a rarity. And although it is utopian to totally eradicate bugs on web and mobile platforms, there are currently new techniques to minimize their number. But let's start by understanding where they come from in the first place.
What causes bugs?
A button that doesn't work, a bad display, a 404 error, a connection problem: anomalies on websites or mobile applications can come from a multitude of reasons. Starting with the human factor. Because as long as web or mobile platforms are developed by humans, errors can happen. But here are some common causes that can lead to bugs:
>> Regressions:
Regressions occur when a code change has an impact on the existing code. For example, when a new feature is implemented, if it disrupts the behavior of previously existing features, then there is a regression, because a bug has been introduced.
But what are the reasons for a regression? It can be because the code is poorly architected, there is poor error handling, a poor version control system, poor proofreading before merge, poor development practices (or no practices at all), or teams work too independently so that the modules they work on can impact each other.
>> A lack of testing:
Does testing mean doubting? Some would say yes, but they would be pretentious. Because if the software or application has not been thoroughly tested, from the beginning of its development cycle until it is put into production (and even afterwards), then there is a very, very, very (there is never too much of a very) high probability that bugs will be found in production. And do we really need to remind you once again of the impact a bug can have on an end user?
Attention: testing is good (even very, very, very good), but you still have to test well. And that requires choosing the right tests to run and doing them in the right place. This is one of the main principles of testing: tests show the presence of defects, but they don't show their absence. This is why it is important to test well and in the right place, in order to identify the most critical bugs in an efficient way. Testing is the essential indicator of application quality.
>> Lack of communication:
Is the lack of communication the cause of all the world's ills? It is quite possible and one thing is sure, it causes many bugs. Because as we all know, the lack of communication between teams leads to misunderstandings, assumptions, but also misunderstandings. And in the context of web or mobile development, the whole issue of communication happens from the specification phase .
Specifications are used to describe the vision of the people who create them. For example, the business has a need and the Product Owner will write the specifications. Then the developers will develop the specifications, and then the testers will test the developments of the specifications. And if there are gaps in the communication between these different people, if everyone is not communicating effectively to develop the product and if each layer is siloed, it creates a tunnel effect that can lead to critical anomalies and the end user is the one to pick up the pieces.
But then, how to prevent these bugs?
We have already mentioned some tips to avoid and limit bugs in a previous article, especially by focusing on quality, but there are also development techniques that can prevent them.
>> TDD (Test Driven Development):
Test-Driven Development is a development method that consists of writing tests before writing the code. But what else? Basically, you first write a test, you execute it, and then you validate that the test is failing, since the functionality has not yet been implemented. Then, we develop the functionality and replay the test until it succeeds, etc.
Why does this method work against bugs? Because if tests are created before the feature or product is even developed, the likelihood that the feature or product will reach its end users untested is greatly reduced. What's more, testing on a regular basis means that bugs can be detected earlier and fixed before they go into production.
Be careful, however, TDD is still very focused on unit testing and it requires upstream work to define the tests, which is sometimes complicated to implement in an urgent project.
>> BDD (Behavior-Driven Development):
The Behavior-Driven Development method, which differs from TDD, encourages communication and collaboration between all project stakeholders (developers, quality engineers, business people, testers, etc.). This ensures that the entire team has a common understanding of how the application should behave. And this translates into, among other things, tests written in a language that everyone can understand, before the development of the feature or product begins. Thanks to this BDD method, it is possible to identify bugs early on in the design process and thus prevent them.
>> Continuous integration / Continuous testing :
Let's start at the beginning. The CI approach, aka Continuous integration, is a method that consists of integrating new code written by developers into the source code of an application as soon and as frequently as possible (at least once a day) throughout the development cycle. Automated tests are performed at each modification of the source code (hence continuous testing), to verify that this has not produced any regression and that the new features are implemented correctly.
This ensures continuous monitoring throughout the application lifecycle and in particular ensures that all regressions are detected as soon as they are introduced. This saves a lot of time and effort that would otherwise be spent on finding the changes that caused the regression, for example.
However, this requires a significant investment in the automation of all types of tests (unit, integration, system, end-to-end...).
>> Beware, these development techniques do not necessarily work for everyone. It depends on the structure, the dynamics of your team, the project context, your testing strategy, etc. With all these prevention techniques, you are not immune to letting a bug go by (zero bugs do not exist), but you should not let the most critical ones go by, as they will have the most impact.
Conclusion
In short, in order to better manage bugs, it is first and foremost necessary to be able to detect them and this simply requires the implementation of test-based approaches. However, as we said above, it is not enough to test, you still have to test well and this requires a living documentation through tests, and especially through automated tests. But this will be the subject of a future article ;)
