| || |
- 1 Post By dlai
- 1 Post By thomasdfg
- 1 Post By meridian_05
Bug tracking software Vs Incident reports
Hi, newly certified but very little experience.
My company have tasked me with designing Test Docs for a new dept. and they want to utilise Bugzilla bug tracking software.
My questions are:
(1) As the bug tracker can carry all the info that an incident report does, do I still need an incident report?
(2) If I don`t need a separate incident report will my documentation still comply with IEEE 829?
Any help would be greatly appreciated, I`m a little out of my depth as I`m the only qualified tester and as such all I`ve got is theory.
I can talk the talk, but the walk is a little wobbly!
Are you required to comply with IEEE 829? Why?
I was internally LOL when I read that. Old timers know this form by another name, the infamous TPS report.
Originally Posted by meridian_05
Incidents can be defined in simple words as an event encountered during testing that requires review.While testing if the actual result varies from expected result it is referred to as bug, defect, error, problem, fault or an incident. Most often, all of these terms are synonymous.Incidents however are a special category of issue that might occur due to misconfiguration, corrupted data or server crash etc. Examples are: Disk spaces full, error in execution (Runtime Error), service unavailable etc.Incidents can also occur due to some issues in software development, hardware usage or service request errors.
What I know is that Bugzilla is simply a bug tracker or defect tracker. If there are other incidents like User access issues, Disk space issues, Interface or middleware issues, etc., or other environment related issues - these are not tracked by Defect Tracker. Companies usually have a support team to handle such incidents with some separate tool to track it.
Hi evileyesteve, to attempt to answer your two questions directly:
Originally Posted by evileyesteve
1. Isn't an incident report also a defect report? In other words, are you complicating and confusing things by calling the same thing by two different terms?
2. What do you mean by "comply", when you've already established in item 1 that the bug tracker can carry all the info that an incident report can?
Don't get hung up on "compliance" with IEEE 829. It's a reference standard, so take as much or as little from it as you need to be able to effectively document your testing with the following two goals:
- spend more time testing than documenting
- where you do need to document (strategy, plans, test cases, defects, etc) then focus on ensuring they are clear and understandable to the target audience. If you happen to agree with the format of the IEEE templates then that's great, but don't let that standard restrict your imagination! Maybe you want less documentation and template information than the standard, maybe you want more, maybe you want a different approach altogether.
Personally, I think Kualitee is best bug management tool. I am using it for my QA team.