Dear colleagues,

We are debating what should go into a list in our defect tracking system for specifying "Defect Cause", for example:
- Programming Error
- Missing Requirements
- Test Case Error
Etc.

Since every team has a little or a lot to add, the list is getting a little too complicated to handle and agree upon.

Do you know of a popular, famous, industry-best-practice, or simply common list of defect causes that we can look at for reference?

I am not sure what is going on but it seems like people are just starting to give up on quality.

Users are developing tolerance to more and more glitches and defects in items and services they acquire.

"I am sorry" has become the anti-quality friendly phrase. Every time you hear it think about it:
- Bad services
- Your car is broken
- Somebody forgot to pick you up
- Your doctor is late for your appointment

I just took the CSTE 2005 examination, and for what I've heard from colleagues who took the test before me this year version 2005 sounds more oriented for team leads and managers.

Most of the questions required thinking as someone who is looking at the big picture versus heavily focusing on testing.

I feel comfortable with how I did, so it's now a matter of time to get the actual results.

When working with one of those apps in an iterative methodology, having releases so often can become a Test Plan nightmare, specially when providing the best coverage possible is the top priority in response to valuable end-user feedback.

I have been working with several templates over the years, but this time I have the challenge of creating one that minimizes the details to a minimum, is tota