For brief overview what was it all about read:
I threw my creativity at the first task:
* Feature/area vs bugs/severity (how to show you have major and minor bugs in different areas of the product/system under test)
I started by trying to understand why would I need to show the data at all. Am I giving a weekly status report or are we trying to make a decision of some sort?
As can be clearly seen, the main idea is to show how the known problems are distributed between different users types. In my practice this kind of question comes up quite often and gives a good way to discuss the pros and cons of releasing vs fixing.
Visualization-wise it is nothing very new actually. Simple table, rows and columns. And numbers showing how many unique problems would user types encounter in 1 hour/day/week of using the product. The yellow stripes indicate change from last time.
The content is very difficult to fill in objectively, needing clear understanding of user types and a good way to distribute the issues between them.
Again, the idea should be obvious. Which of the features/ares is most “broken”. It could be a good ‘evidence’ to discuss the prioritization, even more so if a history was easily shown. So the fluctuation from left to right would be an indication of the maturity of the feature/area.
Area bubbles sizes could indicate the amount of problems in the area, and the position then the severity of them.
There are some problems with drawing this picture. How to show an area that has 1 big and many small issues? Even when going to triangular look the clustering of areas can easily be unreadable. And overall, would this actually give better overview than a simple table?
Another table, yes. The idea here is to show the known issues in regards to different quality criteria. Functional specifications are one side, but there can be many – usability, charisma, traditions, competitors, security, etc.
My visualization does not get further from different colors, either using number or different sized dots to show the same thing.
The only ‘new’ term here would be the “soft fault” – which, for me, means a tracked issue that is according to business specifications, but most probably something that clients would ask about. For example, not supporting 4G, too small hard disk or changeable battery.
The wonderful idea of showing the areas of the product and their status not by name but with picture and a blob/rectangle of variable size/color regarding known issues.Showing the products in its current form could be major advantage in talking to external client, giving lots of information in one go.
As good idea as it is, the problem is in actually creating this, as many problems are hiding ‘behind the scenes’ and many products don’t have any interface to ‘show’.
No comment on the drawing skills. I did not actually finish it, but the idea was to visually show how many problems we have in the ‘foundation’ of our software compared to some features or quality criteria. So the foundation would have areas like – battery manager or ‘overall basic usage’. Doors could indicate ‘log-in/off’, stairs integration between components and penthouse would be important, but rarely used feature – and so on.
Don’t know if it would actually make sense to use anywhere.
Overall I think it was very good to have the workshop, even if most of the ideas were not readily applicable. It gave me a chance to think through some ideas I’ve been mulling over and discuss them with peers. And to have many new ideas to think through and try out.