Measuring the quality of the software we produce should be one of the most
important things we do as Software QA Managers and Testers. How can we
justify the addition of staff or tools if we cannot backup our claims that the
software does not live up to the customer's expectations?
I
realize it takes more than a quality index to convince management to invest in
our QA department, but if you arm yourself with as much data as possible, you
are stacking the odds in your favor.
Why is it so hard to
implement measurements for the quality of software we create? We all
know what a bad piece of software looks like when we see and use it, so why is it so
hard to measure it?
A
couple of thoughts come to mind. The QA Manager:
-
Does
not have enough time to generate one
-
Thinks
it's too complicated
-
Doesn't think is necessary
Out of all three, the most dangerous is the last one. When the QA
Manager thinks that he should not be accountable for the quality of the
software he delivers, he has lost grasp of the reason why a quality
assurance department should exist.
The very essence of what we do in the Software Quality Assurance industry is
to ensure that the software we deliver is of quality. Therefore as part
of what we do, we must implement ways to measure it.
While the other two reasons why managers don't implement measuring schemes are
understandable, they are nonetheless unjustifiable.
A
lot of work has gone into defining and documenting quality and processes
required to create quality software. Unfortunately, I believe that in an
effort to be thorough the pendulum swung to the other extreme to the point
where it is no longer practical.
QA
Managers do not have time or budget to implement all of the recommendations
made by the engineers. They want a practical solution that will yield
enough information to be useful.
I
will talk about practical aspects of measuring quality and provide you with
ideas on how to create a quality index that will work for your company.