tag:blogger.com,1999:blog-6178209.post113928747594141988..comments2009-11-28T00:44:16.449-06:00Igorhttp://www.blogger.com/profile/12832903167357753682noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-6178209.post-44074664622487328532009-11-28T00:44:16.449-06:002009-11-28T00:44:16.449-06:00In agile development the business analyst, product owner, developers, and qa never spend or have enough time to groom an item down to its most granular details. For the most part an item is granulated down enough where each product backlog item can have a realistic estimate, which is always underestimated due to lack of details and further refinements. The items that get developed during the sprint have conditions of acceptance and requirements tweaked, updated, redefined, clarified, until at the end of the sprint cycle the developers have done their best job in interpreting the requirements of the items and qa takes their best stab at putting together the test cases that can be executed. The test cases never encompass all of the requirements since they are in a constant state of change until something is delivered that needs to be analyzed. Then there are always changes there and both developers and qa struggle with getting something right. This results in lots of bugs at the end.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6178209.post-1160133299949436032006-10-06T06:14:00.000-05:002006-10-06T06:14:00.000-05:00Thoughts are well discribed, good going...Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6178209.post-1139940321367702622006-02-14T12:05:00.000-06:002006-02-14T12:05:00.000-06:00bonevich: Ms Onymous mentioned tests not "properly engaged," she didn't say anything about coverage statistics. Obviously coverage statistics can be misleading. I understand "properly engaged" to mean the tests are well thought out to expose potential errors. No one would claim this can possibly eliminate every potential bug, of course. <BR/><BR/>I also agree that all issues go into the pot, as you say.Davehttp://www.davenicolette.net/agilenoreply@blogger.comtag:blogger.com,1999:blog-6178209.post-1139842111904832782006-02-13T08:48:00.000-06:002006-02-13T08:48:00.000-06:00That is exactly what we do. Throw all issues into the pot and let the business decide which stories they want done each iteration.bonevichhttp://www.blogger.com/profile/04806731953106928541noreply@blogger.comtag:blogger.com,1999:blog-6178209.post-1139798146137019272006-02-12T20:35:00.000-06:002006-02-12T20:35:00.000-06:00<I>“That is a total load. You can have 100% test coverage, and still have missed some edge case that no one anticipated.”</I><BR/><BR/>Completely agree. However, I not saying that a project could be bug free but not to use bug tracking tool for keeping truck of bugs. Instead we can create a story cards for these bugs and prioritize them as the other story cards as soon as possible.Igorhttp://www.blogger.com/profile/12782792313857381015noreply@blogger.comtag:blogger.com,1999:blog-6178209.post-1139776744512182582006-02-12T14:39:00.000-06:002006-02-12T14:39:00.000-06:00That is a total load. You can have 100% test coverage, and still have missed some edge case that no one anticipated. I have seen too many agile projects smugly point to their test modules and coverage charts and assert "We have no bugs" only to point out a number of holes in the app, and not necessarily because the quality of tests was off. It is a false sense of security thing. Get over it, accept that bugs happen, and deal with them as effectively and disruption-free a manner as possible.bonevichhttp://www.blogger.com/profile/04806731953106928541noreply@blogger.comtag:blogger.com,1999:blog-6178209.post-1139607167093821372006-02-10T15:32:00.000-06:002006-02-10T15:32:00.000-06:00Right On!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6178209.post-1139341984368875912006-02-07T13:53:00.000-06:002006-02-07T13:53:00.000-06:00defects exists in many agile projects because tests aren't engaged properly on the team.Anonymousnoreply@blogger.com