When tracking change request statistics, would requests for enhancement be considered a defect?
That is a really interesting question. For me, the reason the “enhancement” is being requested is central to the issue. Is this an enhancement that dawned on someone and might be useful for the users of the software? Is this something that with a little effort could impact the “Oh Wow!” factor of the product? In those instances, no, this is clearly an enhancement that does not cover what would be considered “minimal” or even reasonable functionality, but something truly additional to enhance the overall user experience.
If the “enhancement” is actually a case of “We need this to work this way, even though it was not really discussed until now,” then I don’t consider it an enhancement at all. It may be a design defect, a requirements discovery defect, or, often times I suspect it is a combination of problems. In those cases, the full impact of what was being designed and worked on is not really understood by all participants in the process.
I remember working on a university student records system. We worked really intensely on the student admissions process and rolled it out for the fall admissions cycle -- that is, admitting students who would start at the beginning of the next academic year, that fall. It was astounding how smoothly things ran. It was implemented and ran for a couple of weeks and everyone breathed a big sigh of relief. In the next meeting, the one to schedule the post-mortem/lessons learned, one of the boss types from the Registrar’s office said, “This works great. Everyone is really pleased with how smoothly things are running. Now, how will it work for admitting students in the Spring semester?” That was a requirement that had not been considered and had not been discussed. It had not even been discussed that students could be admitted and start at the beginning of each semester.
In other shops I’ve worked in, some stakeholders insisted that some of the recorded “defects” were actually enhancements. Their reasoning was the “defect” did not really count as a defect and was a change in the design. In these cases, I suspect the real issue was that they had their own reasons for keeping the number of defects lower than it would have been.
To me, neither of those are enhancements at all. They are defects in that there was a failure either in the business needs of the system or in the actual business stakeholders’ (owners and users) reasonable expectations for the software product.
Dig Deeper on Software Test Design and Planning
Related Q&A from Peter Walen
Veteran software quality pro Peter Walen explains what software tester skills are really necessary in today's enterprise organizations. Continue Reading
Software testing veteran Peter Walen explains how software testers can write test scripts that others can follow without having to test by rote. Continue Reading
Crowd sourcing can be a key piece of a test strategy for enterprise mobile apps aimed at customers, not employees. Continue Reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.