Testing starts as soon as we have a build to test. If it’s checked in - it gets tested even before the features are deemed “Feature Complete”
Now - how do we track the bugs found during this stage of development? Up until our most recent proejct we’ve always used the bug tracking system.
Now weve been asked to stop using the bug system because it adds too much overhead. The explanation given is “A developer is working on a feature and you log bugs on it when they know it isn’t working…then at the end they have to go back through the list and re-test everything you logged to make sure it’s fixed. It adds too much to their plate.”
My first reaction to this was one of fear and anger. Fear because our development culture appears to moving towards information hiding. To me, as a tester, not logging bugs is hiding information. One of the main goals of testing at PlateSpin is provide timely information to project stakeholders. Without having the bugs logged in a central place for all to see it becomes more difficult to get the information to everyone. Also, for most testers, not logging bugs is equivalent to developers not checking in their code for several days. I wonder what kind of reaction I would get if I asked development to stop checking code in after code freeze?
Why the sudden aversion from development to the bug system?
In the previous release we started testing a feature that was clearly not ready. By the time we were done we had accumulated about 200 bugs on a particular feature. This added a significant overhead for the developers responsible for that feature. The aversion is understandable to a degree. We made an “amateur” tester mistake. We used a tornado to knock over a straw house.
After being asked to not use the bug system I stated my case that I thought this was a bad idea and gave my reasons why. Other testers did the same. We decided to go the route the developers wanted and not use the bug tracking system. Instead we said we would send out a daily (running) list of issues.
During a pre-release status meeting somone said “It would be good if we could number these bugs so we could just refer to the numbers”.
“I know a system that we can use to do that - and it doesn’t require any effort to use.”
Someone else suggested that the testers could simply use Word instead of notepad to write the list of issues. This would give them access to the handy numbered list. (Notice who had to change their work)
Then someone suggested “It would be really nice if we could have these issues in one central place”
“I have just the system for that” - I replied.
Then it was requested testers put the bugs in a project tracking spreadsheet. This sheet had the exact same headings as the bug tracking system. Hmmm - very curious indeed.
This is where I drew the line. We told the developers that if they wanted the information in the spreadsheet that we didn’t mind. We just weren’t going to do it for them. If they wanted to enter it - they were more than welcome to.
How many issues do you think got copied into the spreadsheet?
We haven’t hit our feature complete date yet so I can’t say how this little experiment will work out. We’ve had some developers complain to us for not logging bugs on their code. When they ask for screenshots and logs we have to say we don’t have them becuase have no place to put them and reference them to a bug.
I’m really curious to see how things go with our experiment. Our backlog is already 100+ bugs. The day of feature complete is going to a fun bug logging day!
I mentioned above that we gave reasons for using the bug system instead of a spreadsheets - here are some of them.
- Multiple people cannot edit the spreadsheet at one time. (Lets not tell them about shared workbooks in excel. It will be our secret - ok?)
- One must continually look the spreadsheet to see changes in priority etc
- No running log of notes and troublshooting steps. The bug database is often helpful when it comes time to write documentation and
- knowledgebase articles
- No automatic notification system when a bug status changes or when a new issue is opened.
- No way to add screenshots, diagnostics, or other attachments. Having some, or all, of these items can significantly speed up the amount of time it takes to fix an issue.
Got any other ones we can use?