Bug Life Cycle
I was in the process of writing (what I thought was) a great article on the topic of this image
But today’s CommitStrip really won
Plus, it gives me a great opportunity to talk about legacy system support, and bridge quickly into the bug life cycle.
That might give too much away, but at least if neither of those sounds interesting then I’ve saved you some time.
Legacy System Support
Every company I’ve ever spoken to has that piece of software they’ve been using since forever and is too afraid to ever make changes to it because it “just works” and one guy once knew how to use it, but he left years ago.
One of the areas I’ve specialised in is looking after these types of solutions, but I just wanted to couch a reminder to pay down your technical debt.
Bug Life Cycle
The main purpose of this post though is to talk about what it takes to receive and resolve bugs, and the process in between. It’s an article we’ve intended to write on several times in the past, and it ties neatly between legacy systems and technical debt.
So, without further stalling for a word count, let’s look at the process.
- Receive
The first thing we do when we receive bugs is to do a quick assessment of the report itself. We’re basically running through a quick checklist:
a) Do we have all the information we need to re-create the bug?
b) Is the bug actually broken functionality or is it just an expectation mismatch?
c) Do we have enough verification of the existence of the bug (screenshot of bug, a copy of the faulty email etc) - Recreate
Before we can fix anything, we need to have a working test case, so the first step is to re-create the bug. Using the information in the bug report, we attempt scenarios until we can reliably cause the bug to occur. If we are unable to do this, we will usually seek further clarification. - Fix
A developer then collects details from the test case established above and refactors code as appropriate to resolve the problems at hand.
