Regardless of whether or not it is the 'right' way of doing things, people expect that every failed test has a corresponding defect. It would sure be nice to create a new defect that is related to the test in some way. That is, with a couple of mouse clicks, a new defect is created that has all of the information needed, and includes a reference back to the test case that spawned it.

Comments

  • I too need something like this, however, I would also like a gui representation of the related defect...such as in the Sprint Tracking list view:

    + Backlog Item
    + Test
    Defect
    + Test
    Defect
    Defect
    Task
    Task
    Task

    Even if the defect is created/listed as it currently is, having the ability to expand a test in the main list view and see and update there all the related defects adds major visibility. We're simply using failed tests as the "defects" for a backlog item. Presumably they all must be fixed before the BL can be marked "done", except the occasional bug that's too low priority to be fixed in time for deploy.

  • This might not be the "right" way during the normal sprint cycle but would be great for running regression tests. In this case, defects might be discovered that aren't related to items in the current sprint.

  • A good test case has good steps. so bringing those steps into the new defect as repro steps would save a lot of time. Most good test management systems do this already.

  • Yes, you should be able to generate a Defect for a Backlog Item Test and it automatically links them together, using a "Blocked By Defect" link. It's going to be a pretty painful process to do it the long way...

  • I agree with Dan Y. - It's cumbersome process of copying out steps from a failed test case to create a defect item. Seems right now the "best" way for me to do this is copy out the various pieces I want to a text editor, then create the item and copy the things back in. A smoother more automatic way of doing this would be appreciated.

    I can see it also helping with our exploratory testing process. QA currently creates a Task of type defect for Dev, then creates a test case to fail (this way testing time can be tracked and the test case can be added to regression easier. If I could create a Task/Defect from a Test Case, then I the process could change to create the test and fail it, then choose the option to create the Task/Defect - which would include the important steps to reproduce (or at least help the QA person get started).

  • IMO you should be able to generate a Defect or Issue

  • This would be especially useful for regression tests. You should be able to create a defect from the test case and copy steps, expected and actual results into the defect.

  • We need to be able to associate Defects with failing Regression Test Sets and/or Tests inside of the Test Set.

  • Yes please. Consider the efficiency gained when a user can generate a defect from a test. The steps, expected result, actual result should all carry over to the defect description...

  • This sounds fantastic! Please add this.

  • We would greatly benefit from the ability to add/create a Defect from a broken Story as well and have them linked.

  • I could have used this again today.

  • I found that defects are most effectively worked with the Test Conversation tool, so I quit creating Defects. Defects are nothing but new Stories so if a new Story is needed I create one. The Defect object seems to create duplicate effort and creates no additional value that I can see.

  • For a Test Set, you can create a Blocking Issue. Then, determine if the Issue should be resolved w/ a Defect or a Story. This is a couple extra steps, but it allows the Team to decide the progress forward, not the Tester.

  • Agreed. It should be easy to create defects from failed tests not resolved in the sprint. The story may not fail because of it but the tech debt needs to be captured.

  • Totally agree. Defects and test cases need to be linked or these is a duplication of effort. Here here!

  • I would love to see this feature added. I managed to create a very cumbersome process to tie a defect to a test, but it was far from ideal, involving a lot of manual effort. Tests fail. A defect tied to a test provides additional clarity about the test and the relevant changes that fixed the defect.