通过

When is a bug a bug and when is it an incomplete feature

  • 项目

Had a fascinating conversation with one of our partners today, the meeting was about how they should be integrating all the new test artifacts in VSTS 2010 (Test Cases, Test Plans, Test Configs, Shared Steps, Test Points, Test Results) into their customised process guidance. They already have some Test artifacts in their current guidance and we were discussing how to morph that into the new world.

The conversation quickly turned to what we call the “No More No Repro Scenario”. This is where we file, with a min of mouse clicks, a bug with lots of data from the test case such as; video, historical debug log, steps, action log, screen shots, event log, etc etc etc.

In classic agile a bug that appears before a feature is “done done” in a sprint is just work that needs done to complete the feature and is treated like anything else on the Sprint backlog (it may require discussion but assuming its valid…). If the bug appears outside of a sprint or the bug is found in a area that is not currently being worked on then its a product bug and after review/prioritisation with the customer, it can be added to the Product backlog.

Hence in the case of the partner when they find a sprint related bug, its not filed as a bug as we know it, but a product bug can be a (WIT) bug.

Now the problem, we know how to file a rich bug to support the “No More No Repro” scenario, but if a (WIT) bug  should not be filed but instead something added to the Sprint Backlog, how do we handle that from MTR? Well in reality we are not sure yet and that’s what we were discussing.

Incidentally we have a similar problem in Developer Division that we solved a different way. We work as feature crews in branches, we develop new features and when they are ready we integrate them into the parent branch and they work their way up the branch structure to Main, where we produce CTPs, Betas etc. We track bugs found and fixed before the feature is integrated (ie before it is done) differently than post integration bugs (or bugs found say in VS 2008 that may also apply to VS2010). We do this with an extra field on the bug WIT which dictates whether a given bug is a product bug (post integration/completion) or a feature bug (pre integration/completion). Some teams have a 0 tolerance(or very low “bug hell”) policy for feature bugs whereas product bugs tend to go through a triage/prioritisation process (hence there reason we sometimes are not super fast in responding to connect items as they by their very nature are product bugs).

Clear as mud? Excellent.

Do you have more than one “bug type”? How do you handle them?

Comments

  • Anonymous
    April 20, 2009
    PingBack from http://asp-net-hosting.simplynetdev.com/when-is-a-bug-a-bug-and-when-is-it-an-incomplete-feature/

  • Anonymous
    April 23, 2009
    Shai Raiten on TFS API Part 19: Merge and Visual Studio 2010 MTCF Glossary activity for Hebrew Paul Cornell

  • Anonymous
    April 23, 2009
    We use Scrum and for us a bug is a bug. We don't differentiate between bugs found during the Spring by QA or after the after by tech support, QA or anyone else. Meaning we use the same WIT for a Bug. With the new Hierarchical WI support coming in VS2010, we plan to link all Bugs under the WorkItem it is related to or on its own when found outside the sprint. So I don't think this is an issue for us.