Hello! 

We're really pushing for OnTime to be at the center of producing in-process metrics (number and type of defects, age and severity, cost etc). So far we're having a good level of success.

However one metric I'm having issues with is the count of defects reworked. I'm measuring this by introducing a new workflow step 'Tested and Not Fixed'.

I've included an example of a path a defect might take through our workflow below:  

Defect Found > Defect Being Fixed > Defect Ready for Testing > Tested and Not Fixed > Defect Being Fixed > Defect Ready for Testing... etc

Is there anyway of identifying how many times a defect has been associated to a particular workflow step? Or is there another way that this may have been implemented by someone?

Moving on from the above, but much the same issue, it would be very useful to report against a typical defect's lifecycle through the Defect Workflow. That is compare the number of defects to the number of instances a defect has been associated to a particular workflow step. Being able to identify these trends will help inform us where to apply more rigorous quality measures, i.e. peer reviews, testing etc

I am currently able to get the above info through exporting the defects and pivoting them. I would if at all possible like to avoid having to create a custom report as this will take me considerable time to produce! However if this is the only way, some gentle prodding in the right direction would be much appreciated!

kind regards

Ben 

*bump*

I guess I'll pop this request via support unless any ideas are submitted in the next day?

Ben

I've forwarded this on to support. Once I have a resolution I'll post the details here.

Support have informed me it's not possible to do this as the system doesn't support this currently.

So instead of relying on the system to make the counts of defects hitting a specific workflow step, we've set up a custom field. Each time the defect is allocated to that step the custom field becomes visible and the user amends the field accordingly, i.e. 1, 2 etc to sum the number of times the workflow step is hit.

It's a pretty simple workaround and so I am a little disappointed this wasn't actually suggested by Support as a workaround to resolve the issue.

Sounds like an interesting thing to measure. My thoughts is that your suggestion as it stands is error prone.

It may be possible to run a process when an item goes into a certain step. You would then need to create a program (using the SDK) to increment the number in this field - this would seem to be much more reliable and remove the need for the user to manually increment the value.

I'm not sure how you are actually doing the reporting of this, but it would be a similar program which reads the value for each item then sums and divides by total number to get average