Currently our QA/Software Testing team does not add estimates or track their "Working On" in FogBugz. This is mostly because we have not found a good way to do this. We have tried to add an additional case for every time we need to reproduce an issue (aka narrow down the steps that cause a bug) or verify a fix, but this seems to cause the case list to grow very large and seem to be less usable. How are other development teams handling the time it takes to reproduce issues and verify fixes using FogBugz?
|
6
3
|
|
|||
|
|
2
|
Far from perfect, but what I've seen recommended before was the big blob of "testing time" in a case, as well as other cases for final acceptance testing, etc. In fact, I don't really like that setup very much. What we have done is use the aforementioned blob for the routine bugs or features that come along (either charging time directly or doing it like any other "buffer" estimate). However, along with the implementation cases for larger features (broken down into smaller parts), we include a testing case (typically one for the engineer, one for the tester). This has helped to keep the number of extra cases from testing in check. As well, subcases help make it much cleaner! Now, if Fog Creek had a test plan management product too, I think we'd be much better off. ;) |
||||||||
|
|
0
|
You might want to look into a test management tool that integrates with FogBugz, as it's usually a better solution. There are different tools available, and I recommend looking at our tool TestRail (of course, I'm biased). Here are some details on how to integrate both tools: http://www.gurock.com/testrail/fogbugz-test-management.i.html |
||
|
|
