At the TestBash in Cambridge, Dave Evans held the first session on Visualizing Quality with a walkthrough of some ideas about it.

Dave opened with a hint on systems. He introduced his family as a system. He made same references to the quality of the relationships he recognized recently. Dave reminded us that quality is a relation between people. Too often do we forget this when measuring presumably objective figures from systems. He referred to Jerry Weinberg’s definition of quality as quality being value to some person (at some time, I might add).

Dave proposed some idea on visualizing quality. With a comparison of military budgets, he raised the point of putting data in context. The US budget of $ 607 billion compared to China ($ 61 billion), UK ($ 60 billion), or Japan ($ 47 billion) the US budget seems to be roughly ten times bigger. A different context is the debt in Africa in total, which sums up at $ 254 billion. Taking a look on the percentage of GDP, the US scores at 4%, while Myanmar spends a higher percentage figure on its military budget. Evans reminded us that figures and numbers have a context, and I think we should be aware of that context when providing these figures.

Another idea that Evans provided was based on heat maps. He showed a heat map from Manchester, where the biggest heat was not coming from the center of the city. Instead the suburbs produced more heat than the center. He also had another heat map from one player in a football game. Would if we had a heat map of the locations where a developer spent the most time in the code? Actually, I crossed an approach a few years ago based on a paper called “Don’t program on Fridays”. They correlated data from open source bug trackers and the version control system to indicate change risky areas in an eclipse plugin. I haven’t crossed such an approach in a live project. I am pretty sure that every programmer in a project actually knows where the red areas in such a heat map would be. What if we went over and asked to show us “THE class”?

On Scale Evans showed a scaled representation of the sensory cortex of a Penfield Homonculus. Fingers for example have a much larger area of neurons in this representation. He crossed the gap to quality with this representation by referring to different aspects for visualizing our sensory information regarding our lines of code, but also about our customers.

Evans showed some examples for visualization of software systems and quality. He started with an info graphic of Napoleon’s Russian invasion and retreat in 1812 and 1813. It showed the number of soldiers by the width. Like a burn-up chart the retreat was drawn by a black line. He showed a map from Code City which tries to visualize a city map of your code base.

Dave referred also to James Bach’s Low-tech testing dashboard as a way to visualize software quality. The emphasize there is always on subjective qualities of the testing project. How much effort are you putting in? How much is the coverage? What is your subjective assessment of the quality in that area? You cannot get this kind of information out of most test management systems around.

Dave also showed an example from a project they created at SQS. It reminded me in its nature on Bach’s Low-Tech Testing Dashboards, but was more based on more traditional test planning efforts like amount of tests prepared, and so on.

Evans reminded us on a few thins we might be interested in tracking:

• Profitability & Success
• Customer goals and stakeholder values
• customer needs of our systems
• patterns of satisfaction and dissatisfaction
• product qualities and their current levels
• measures of qualities during development
• progress of the act of measuring qualities

Evans distinguished between people and systems. He referred to Weinberg’s definition (see above), and the one from Phil Crosby: “Quality is conformance to requirements”. The first one subjective, the latter one claims to be objective.

He introduced the user story clause “As a <role> I want <feature> so that <business value>”. Evans explained that he sees a lot of teams in the Agile context who don’t give enough care to these difference stakeholder values for their user stories. I agree with that. On product quality attributes he used the user story format to refer to the quality of the feature in the clause. Referring to Tom Gilb the how is based on quantified values on a defined scale.

Evans showed a pre-historic windshield which was a manual flexible windshield. It does the job, but how well does it do it? Raising the question on how it can be improved, you can come up with things like automating it, and improving on keeping rain from the windshield.

Combining stakeholder values and product qualities leads Evans to value maps. He worked through an example on car parking. He introduced different stakeholders and their particular why – the business value from the stakeholders, like different driver types with their goals. He showed different features for the different stakeholders. The feature itself is not particular interesting to them, but how well we introduce that feature. This consideration finally leads to different acceptance criteria.

Dave closed with some things to remember:

• remembering the humanity of quality
• communicating with stakeholders
• find the right level at the right time
• turn data into information
• engage more of the brain