What do I believe quality IS and NOT ?

First, what do I believe quality is?.




Quality is a collection of “ilities”:

1. Reliability: the ability to operate error free
2. Modifiability: the ability to have enhancement changes made easily
3. Understandability: the ability to understand the software readily, in order to change/fix it
4. Efficiency: the speed and compactness of the software
5. Usability: the ability to use the software easily
6. Testability: the ability to construct and execute test cases easily
7. Portability: the ability to move the software easily from one environment to another

(Note that in the previous column, I failed to mention “efficiency.” Although it doesn’t end in “ility,” that was a serious omission.)

You’ll probably notice the ordering I’ve put on these “ilities.”

If there were such a thing as a universal ordering, this would be my choice— reliability first (the software has to work), portability last (platform independence doesn’t matter for many software systems). But there’s not such a universal ordering, and there shouldn’t be. For one thing, everyone’s ordering priority might be very different. For another thing (and this is the most important reason of all), the ordering of the “ilities” should be project dependent. If you’re building a system that is to be platform independent, then portability should leap to the top of the list. If you’re building a system that you expect to keep around for a long time, then the two maintainability traits— modifiability and understandability— should move to the top of the list. If you’re working on a hard real-time problem, where nanoseconds and/or memory space count a lot, then efficiency belongs at the top of your list. In fact, ordering the “ilities” at the beginning of a project is a vital, identifiable task—and one in which your customers/users must participate.


Second, What do I believe quality is NOT?

That’s where I presented the following equation:


User satisfaction = Compliant Product + Good Quality + Delivery Within Budget/Schedule

What happens when you accept this equation. Quality stands alone, distinct from all the other entities mentioned in the equation. It’s not the same as “user satisfaction.” That’s a much more complicated entity, for which good quality is only a subset. It’s not the same as “compliant product” (meeting requirements)—that’s clearly different from quality. It’s not the same as “delivery within budget/schedule.” I don’t mean to diminish the importance of user satisfaction, or meeting requirements, or meeting estimation constraints. Those are all really important things. It’s just that they are separable from, and rather importantly different from, quality.



Thanks & Regards ,

Prashant Vadher | QA Engineer


0 Comments:

Post a Comment

 
Design by Prashant Vadher