Why a System?
We all hate when someone logs a lot of bugs in your code be it your teammate or QA team.
So it was always an issue for me when there were many bugs on the board, any scrum tool you use, or even plain Google Docs or Sheets.
So I created a simple 3-step method ( it all happened on instinct I didn’t plan to create any system as such)
The System
So basically I use a Google doc, in which all the bugs are logged with their title and little description,
It doesn’t include any images or long logs for those that use your main tool like Azure DevOps or Jira.
After you are done with writing the bugs, Then I just quickly go through them one by one and just for a short burst of time think about each bug and try to figure out what things must be causing this.
This doesn’t have to be accurate or anything just anything that you think is causing this. Do this activity in a very short period of time. And one by one start those thoughts and speculations that you have below that bug.
This might look like useless work but as I go solving these bugs later on I tend to forget things a lot. So it is better to write this like this
Then prioritize these bugs according to their severity and discuss with the team the fixes that they want.
Solve, Fix, and Read the logs man ….
At this point, I go about solving the bugs. I refer to the document and use the points that I have written about the bug. A lot of times, I find the issue because of those points that I wrote earlier, but sometimes, I don't. It all depends on the bug and your level of understanding of the codebase.
Some Stupid Bugs
Some stupid bugs are just a headache to solve and Iam stuck, so in that case I just write an observation note below that bug in the document and hold it for later or communicate with the team.
So in this case, everything is fine locally, so something must be breaking in the deployment or the configuration of the pipeline. So this observation will be useful to communicate with the team to fix this.
(This is just a sample example I took please don’t take it seriously about it working locally)
The Dead Bugs
Some bugs take time to solve some are solved in a breeze, so then I also added a field called Fixed in the document where I mention what fix I did in a short sentence. The benefit of writing this is when a similar bug arises in the future we can refer.
What is the use of a such trivial activity?
Well yeah, this is a really simple method just like note taking. But it has very good returns in the long run. It totally depends on your situation and the tools that you use but for personal use and as a good documenting practice its really beneficial for you. You don’t even have to share this with your team, keep it to yourself, but they can be really useful when you have to refer them again in the future or give KT to someone. Below are a few benefits
Good documentation practice
If you see a similar bug in the future you can refer to this
If the team needs to transfer bugs from you, this doc can be a wonderful reference for them
If your manager or lead needs visibility from you, then you can just share this doc
Once docs like this build-up you will have a great archive of data about the codebase
Giving KTs will be really swift and smooth
You will see a rise in productivity
Giving status in standup will be really easy
This a simple notetaking method that I use, I hope it helps you too.
Thanks for reading.
