“Everything that informs us of something useful that we didn’t already know is a potential signal. If it matters and deserves a response, its potential is actualized.”
― Stephen Few
This is the introduction to a series of posts about a favourite subject of mine; reporting. These posts were inspired by a mindmap I created which looks at questions testers can ask to assist them in providing information. The series runs alongside a set of pages which address the branches of that mindmap in detail. The first of these pages is an introduction to the mindmap.
I use the term reporting as a broad term, referring to the act of conveying information. I should make it clear that I do not limit the term to documented reports. We convey information in many ways, whether written, modelled or verbal and this series of posts is not intended to address any one approach above another.
I understand that the idea of reporting has negative connotations for some in software development. I have been the recipient of (and undoubtedly contributed to) some mind-numbing test report documents filled with bar charts, pie charts, scatter graphs and clustered bars yet somehow lacking in useful information.
I’m confident that I have seen reporting at its worst; reporting which clouds information (sometimes willfully) and which fails in its most fundamental need – connecting with the human being receiving the information. Yet I have also seen some wonderfully creative ways to share information. There will be more on this in subsequent posts. For now, I will simply say that I believe the means of delivery is an important factor in getting a message across.
“If a tree falls in a forest and no one is around to hear it, does it make a sound?”
― George Berkeley
My experiences in software development projects have led me to some conclusions:
- the most useful information about software is often discovered whilst testing
- the most important function of testing is to provide information
- testing is only as effective as the communication of information resulting from it
This last point is crucial. From bug reports to conversations with senior stakeholders, testers have an important task in effectively communicating their findings. Too little information might lead to misunderstandings, too much might lead to important points being lost. Learning and applying skills to test effectively and discovering valuable information is of no use if that information is not communicated to the people who need it, when they need it.
In the course of a project or development activity, there are likely to be numerous actions and decisions taken which might be affected in some way by the information uncovered through testing. Testers cannot hope to understand all of those actions and decisions. They can however ask questions which will give them a better chance of providing useful information. Those questions are covered in detail in the mindmap and the associated pages you can find on this site.
I believe that many of the problems we encounter in the development of software and technology can be overcome through access to useful information. By asking the right questions at the right time, testers can play a significant role in getting the information that is needed to the people who need it.
Quick links to the posts and pages in this series:
Assisting with inquiries – blog posts
- Introduction to the series
- Part 1 – your audience
- Part 2 – the mechanics
- Part 3 – filtering information
- Part 4 – how was it for you?
7 thoughts on “Assisting with inquiries: Introduction”