How product engineers fix bugs at Inato
In a previous article, we talked about how we develop a feature at Inato. We have a different process for fixing bugs, and we thought it would be a good idea to explain it too.
At Inato, a bug is defined as such: a behavior of the app that does not respect the specifications agreed upon with the product team. Thus, we make the difference between app bugs and product bugs (bugs of which the faulty behavior was not described in the specifications).
A developer generally does not need help to fix an app bug but needs to agree on a certain behavior with the product team before they’re able to fix a product bug.
Bugs will happen
Bugs will happen. So what do you do about them once they appeared in your app?
Who files a bug? Who fixes it? When? All of those steps better be standardized if you want a smooth and fast process.
In this article, we will focus on the actual process that we use at Inato to fix a properly filed bug. A bug is considered properly filed when it:
- Lists steps needed to reproduce the bug.
- Clearly describes the current behavior.
- Clearly describes the expected behavior.
- Includes screenshots if it applies.
Analysis
Just like when we develop a feature, we start with a mandatory analysis of the bug. The goal is to ask the right questions before really diving in.
- Has this bug affected users’ data?
- How many users have been affected?
- Are the product specifications clear or do they need more details?
- What’s the best way of resolving this bug?
Most of these questions may have been at least partially answered already by the person who filed the bug.
Once everything is clear, we describe the different changes to the codebase needed in order to fix the bug.
Then we share our analysis with the rest of the team on Slack and ask for remarks and insights.
Development
The first thing to do during the development step is to write the tests that will ensure the bug is fixed.
If it’s a UI or UX flow problem, we may want to write a new end-to-end test. If it’s a localized error on a business rule, we will rather write simple unit tests.
Naturally, since we do that before actually fixing the bug, they should fail. This follows test-driven development best practices.
Then we can actually fix the bug, and check that our tests are now passing successfully.
We can then create a Pull Request with our edits and ask a teammate to review it.
Demo
A mandatory demo of the fix is made with the product team, to ensure that the bug has been fixed in accordance with the specifications, but also that the new behavior didn’t break anything else. The demo should be our last safety net, in case something was missed during the analysis step.
The member of the product team should follow the demo steps written during the analysis, and then test different edge cases and related behaviors of the app to ensure everything is still working properly.
Release
Once we made a successful demonstration, we can release our bugfix to production and broadcast on slack that the bug has been resolved.
Post mortem
What may be the most important steps of resolving a bug at Inato is writing what we call a detailed “post mortem”. We follow the following template:
# Post-mortem :skull:
## Causes
## How to prevent this type of error in the future?
## How can we catch this kind of error earlier in the future?The goal is first to identify what caused the bug. We try to list general causes (a human mistake, dependency update, programmatic complexity, legacy code, code duplication…).
Then, we try to find creative ways of preventing a whole category of bugs, to continuously improve our testing strategies and to ensure we create the least number of bugs possible.
Finally, we try to think of ways to catch those errors earlier. For instance, by improving our bug tracker setup.
We then share this with the rest of the team and take action on raised issues.
Clean up
The last step is to clean up related issues on Sentry, our bug tracker, and to add a new bug — the first one in the priority-ordered list curated by the product team — to the backlog of tasks developers choose their next task from.
Conclusion
Acknowledging bugs and making them part of your development flow is important and allows for continuous improvement on the speed and process of solving them, but also to set up prevention measures.
Drug discovery is a challenging, intellectually complex, and rewarding endeavor: we help develop effective and safe cures to diseases affecting millions of people. If you’re looking to have a massive impact, join us! https://inato.com/careers/
