QA Analyst tests a user story and finds a defect.
Currently the new defect is added to the Iteration item list as a stand alone item but can not be linked to the user story in question.

As a QA Analyst, I should be able to associate a "new defect" with a user story or a task.
Also I should be able to associate the defect to a test case designed to verify that user story or task under that user story.

This is very critical for a QA Analyst to track how testing is progressing for a given user story.


  • Rather than creating a separate defect in this case, our suggestion would be to mark the test as failed and add a task to the story to fix that failed test. The story in question is not finished since the test is failing, so all work required to finish the story should be included as part of that story rather than as a separate piece of work. Defects are intended for functionality that have already been accepted by the customer that are subsequently found to be no longer working properly.

  • on the surface that's a good solution, however "tasks" do not include all the fields that a "defect" offers.

    Additionally, if you have a defect (entered as a 'task') that the product owner determines does not need to be fixed in order to call the feature done, but they want to keep track of it for future remediation... it would be nice to be able to directly convert that Task to an actual Defect. Currently, in this case, we would have to create a new defect, manually enter/copy the information, and delete the task.

  • The official response, to create a defect as a task to fix a failed test is not a realistic solution because a story is often released with defects that are not deemed critical enough to stop the story. Those defects will be fixed in the next release. You know, like in Agile methodology, in which you release the minimum viable product then continue iterating and improving, even if some of the improvements are fixes to defects.

    For this reason, to support Agile, Version One needs a way to link a defect to a story. Without this, the whole thing is a mess and there is no traceability between stories and defects.

  • Also the importance of traceability is related to keep track where the problems are occurring, where the development team needs to take an extra look. In addition, to have a traceability report would be very useful.

  • I am new to versionOne and am a bit amazed this feature doesn't exist. It seems like a real basic control to know the link between the two. Which defects are blocking which stories. This correlation often helps determine fixing which defects would unblock what tests and therefore is a value measure.