At yesterday’s full day workshop “Software Quality Metrics Best Practices” (I would call them just practices as best of one may be not so best for others), we had a very interactive session. I warned the participants that they would have to do just that, ‘participate’. For much of the day, I did a bit of lecture and showed examples, but the attendees had to take that and apply it to their own work. Hopefully they left with some metrics that they could take away and use immediately in their own organizations.

We started off by aligning ourselves with a simple goal of why we want to collect metrics. Many collect measurements and calculate metrics just because they are ‘supposed to’ or can. Without a clear goal, the effort soon becomes a burden and our polls show that most efforts end up being abandoned.

With a clear goal, we embarked on defining software quality using ISO 9126/25010 as a starting point, but then customizing it as the standard allows and encourages, for each particular information need and organization.

Using a definition of software quality, then we discussed how we can break quality down in different pieces within an organization and within a process. Regarding organization, different pieces or departments are responsible for and can be measured for their contribution to quality. For instance, product management can be measured for their ability to create clear requirements for development. And, using today’s very customizable issue tracking tools, we can actually create different types of defects, not just defects we find when testing software, but also defects in requirements. Simply tracking these issues leads to their management and improvement.

From a process point of view, we discussed how we can measure different pieces of the software development process using the assumption that quality in one part of the process upstream will influence those pieces downstream. Therefore, by measuring whitebox testing static items, we can then improve quality downstream in User Acceptance Testing.

Although it was named; “Software Quality Metrics Best Practices”, I can’t profess that it was, but I can say we covered a lot of material whereby the participants could extract information and use as ‘best practice’ customized for their organization.