What we know: Tfs allows us to manage bugs. We can add bugs and move it through different states.
What we need: We need to have different states in bug, which TFS 2015 doesn't allow out of the box, particularly
- "Not a Bug" (which is after NEW > ACTIVE and then if Developer says, its not a bug)
- "RE-Opened" (where a bug has traversed from NEW > ACTIVE > RESOLVED > CLOSED and then Re-Opened in another Release / Sprint).
Which approach mentioned below we could use ?
A- We are currently on TFS 2015. We do the customization through WITAdmin approach (https://www.visualstudio.com/en-us/docs/work/customize/add-modify-field ) and it's impact on Database, Reporting and going forward, towards migration would be another effort.
B- We migrate our TFS 2015 to TFS 2017 and get the new feature of adding our new states out of the box as per (https://www.visualstudio.com/en-us/docs/work/process/customize-process-field#add-a-custom-field)
C- We need to change our practice of logging bugs, and we need to study proper Agile Implementation through TFS, since AGILE process does have this scenario of What We need mentioned above.
A,B,C are the approaches, I have thought about. I would appreciate if the experts could share their experiences, thoughts and / or new approaches.
Approach B only exists in Visual Studio Team Service, TFS 2017 doesn't have this feature currently.
Approach A will be a good option. But you might need to modify your custom process for the wizard to run, or you might have to update your team project manually after a TFS upgrade.
Check more information of Maintenance and upgrade implications (TFS) on the website below, which tell us what should we avoid during customizations:
https://www.visualstudio.com/en-us/docs/work/customize/customize-work#maintenance-and-upgrade-implications-tfs