Tony wrote a post on issue tracking during software requirements phases of your project a couple years ago. I want to write about it again because I think it’s one of the most valuable things we do on projects to ensure nothing falls through the cracks. Plus, everything he said is still true and we have learned new things!
On a recent project, we tracked issues of a few types of issues and defects that you may not normally see. The specific issue types in our tracking system include:
- Requirements Questions – as Tony mentioned, we start tracking issues much earlier than most projects. Almost all of the defects we log that early in a project on are related to issues in the requirements, such as: asking the business for clarification on a requirement, scope decisions, feasibility questions with development, and simple to-do items on the requirements themselves. We find this to be far more effective than tracking them as notes in the requirements documents themselves. Development actually can log questions right here as they review the requirements, so it’s not uncommon to see a few of this type throughout the project.
- Training – as users start to use the system, be it testers or business users, there will be issues logged in the system that they believe are code defects, but they are in fact just training issues in that they do not how the system is supposed to function. These issues can feed training materials or user experience change requests if they are overly complicated for users to understand intuitively.
- Test Cases – as the system is tested, there will be errors in the test cases themselves. Often they are found when the tester executes the test case and logs a code defect because it failed, only to find later the test case was just wrong. Also, as requirements or design change, you can trigger test cases updates off these issues.
- Development ignored requirements – I would like to think you don’t need this category ever, because doesn’t every developer always read the requirements? Well unfortunately I think it’s more commonly an issue than any of us would like to admit. Either way, we found it useful to track how frequently the developers were not reading the requirements to develop.
See my last post where I wrote more about our metrics analysis on this project!
