It’s been a while from my previous blog post. I’ve been busy with my current project which is actually my first as a consultant. This means that I’m learning all the time a lot and my thoughts around testing are evolving. When I activated on studying testing on March, 2012, I had a clear goal of becoming a software testing expert. Since then I’ve been for example on BBST Foundation and Rapid Software Testing courses. My knowledge about testing has increased hugely from what it was one year ago. I have though run into a problem. The problem is the visibility of our work. In other words, to whom and how much should we transfer our knowledge as testers?
Testing provides information
Image via (Marco Bellucci – Flickr)
I like the idea of testing providing information. It sounds natural for my current context that does not have any outside pressure affecting the way we test our system. Reporting bugs is the common way of delivering my knowledge about the system, but I can do more. At least I am trying to come up with different ways of being more valuable as a tester in my project. Basically that means thinking of to whom and how I could give information about the system I test. This can mean informing developers about the condition of the release or providing my opinion about the state of the system to product owner. Both are something that I have done in my current project.
With information comes responsibility
The information itself is rarely valuable to us only so we have to share it. I’ve experienced moments when filing every bug would have damaged a lot my relationship with the developers. James Bach has talked about Sympathetic Testing on his blog and how that is most often a way to start when facing highly unstable product. In other words not putting too much pressure on the product but more like trying to find out what it can do instead of what it can’t do.
Image via (fresh_photo – Flickr)
So we have to consider what information we provide and when. Especially this is highlighted when you are sharing information about your understanding to people that do not necessarily understand testing. These people might be for example from upper management or product owners. I reported some time ago my opinion about the overall status of the system I was testing. So, basically I just had to describe how I see the status of the system from tester’s perspective. I reported my opinion to several people across the project in one email and I had to make an extra note about how my opinion should not be viewed as final truth. That is why I think we should remember the impact that our information sharing can create. We are responsible for our words and should remember this all the time we talk about our opinion about the system under testing.
When we understand our responsibility we can make a change
The information we have about the system is by no means the truth. It is fallible and biased, but still a result of thought process that is often valuable to stakeholders. When we understand these aspects of our testing – and remember our responsibility toward our information sharing – we can share our knowledge in a way that will benefit the project more than solely relying on bug reports could achieve.
Image via (ForestWander – Flickr)
I also believe that in information sharing and visibility of our work lies the answer to changing the public opinion about testing. The better we evolve in explaining what we do, what we have found out or what we are about to do, the more people see the effort we have put to become a skilled tester. This requires though improving our way of explaining problems, clarifying our messages and treating for example every email or document as one that can be forwarded to any stakeholder on a project. I’ve seen the benefit in this when I have put a bit more effort in explaining things as simply and professionally as I can. And when my explanations are bouncing across the project, I can rest assure that it’s piece of my work like any other testing artifact I have produced (e.g. notes, bug reports).
What, Who and How
I do believe – based on my short experience – that the information we reveal via testing can be shared in various useful ways, but the challenge and my original problem is the ‘What, Who and How‘. What do we share (e.g. overall opinion about the system, opinion about a specific feature or functionality)? Who do we share (e.g. all the stakeholders, development team, upper management, product owner)? How do we share (e.g. email, mind map, meeting)? This is also one of those matters that is highly affected by the context, so there is no “One size fits all” -answer for this.
I will continue experimenting with the ‘What, Who and How’ -problem. I also hope I will be able to create conversation around this subject as it’s a lot linked to test reporting itself. Both are my main themes for year 2013 and if everything goes well, at the end of the year I can write “Part 2” post for this one with more wisdom behind it.
Flow of Testing 
Nice post, it is easy just to sit with the app and find bugs and think our job is done…
Your post reminded me of some of Rob Lamberts blogs posts from a while back when he was posting about PACT – Purpose Audience Context and Testing – http://pac-testing.blogspot.com/2009/01/introduction-to-communication.html
Thanks Phil.
I checked out Rob’s blog post and definitely found similarities there. Especially I liked the PACT that summed up the things to consider when communicating. Perhaps I need to have a chat with Rob at some point :)
-Aleksis
Nice post Aleksis, thanks for sharing.
Great to see you grabbing this challenge by the cajones – having to prove our effort / work is a situation most us may have come across.
Did this post come about from you being put into this situation, or your curiosity getting the better of you?
Hey Duncan,
Things led to a situation where we and I had to share the knowledge more across the project and at the same time my curiosity also wakened when I saw positive signs related to information sharing. The context I’m in right now has its own twists so activating on this subject will benefit the project – I think.
But I do think in almost any project we should find ways to inform what we have done (besides finding bugs). And beyond that only imagination is the limit on how we can utilize our knowledge on the project.
This sounds like a good topic to discuss at Let’s Test. :)
-Aleksis
Great Post Aleksis, I look forward to part 2 (and will hold you to it by the end of this year).
Reporting information is something that requires “Fingerspitzengefühl” (finger tips feeling), and the more so the more sensitive/negative/”loaded with feelings on the receiving end” it becomes.
When I find something that can be extra sensitive, I find it a good habit of walking over to the developer/project manager etc. and having a face-to-face communication first, information in written form can so easily be misinterpreted.
But good testers learn a whole array of small trick like that in working with other people over the years.
Be careful when using the term “transfer knowledge” as it implies a mechanistic way of looking at knowledge.
Some knowledge can be packaged and delivered via email/doc/wiki/process-flowchart-from-overpaid-management-consultant, but when it comes to tacit knowledge the picture changes.
If you havn’t take a look at:
http://contextdriven.blogspot.se/2013/01/controlling-informal-through-formal.html
Hey,
It’s good you brought the sensitive aspect of information sharing. You can cause a lot bad blood by spreading information without thinking. Nothing though beats face-to-face interaction.
With transferring knowledge I meant basically projecting our opinion about the status of the system or part of the system. But even then there is a lot of assumptions and biases affecting it. I really liked your blog post and it is certainly linked to parts of what I was writing about. I think I need to read Collins’s book and spend some time figuring out whole tacit knowledge concept.
-Aleksis
Nice one. This is a topic I spend a lot of time contemplating as well.
Regarding the “What, Who and How” I find it useful to start with one of them, e.g. the What, and then figure out Who that’s for and How to transmit to that person(s). Or, if one doesn’t already have the What, then maybe start with Who and think about What that person needs to know and How it would be preferable to deliver that information.
Point being… Some information is best kept within the team. Some information needs to be transmitted to as many people as possible.
Different information is suitable for different people/roles and might need special attention in the delivery method, depending on how available they are for face-to-face conversations, their temperament, their preferences (responds well to qualitative vs. quantitative information), their attention span… etc. :-)
Thanks Johan,
Also really nice thoughts and suggestions about the ‘What, Who and How’ -problem. Really liked the idea of starting with one and moving then toward the other two. Also as you mentioned there is so many factors affecting the way we handle this problem that no wonder it’s a hard one to come up with good solution.
I don’t remember if you were coming to Let’s Test, but if yes, then perhaps we could continue conversation also there.
-Aleksis
I certainly hope to make it to Let’s Test! :-)
Pingback: Five Blogs – 16 January 2013 « 5blogs
Thanks for ur post.
Its good to learn..
Looking forward to read ur writings.
Pingback: What makes a bug, what makes the bug a problem and how do I handle it? - ReQtest
Searching for “testing, visibility, cdt” and I stumbled over this interesting blog post of yours, did you ever get round to doing Part 2? If so, I’d love to read it!
Hi Bolette,
Glad to hear that you found the blog post interesting. When I wrote this, I was on my first project as a consultant. Now I’m at another client.
Initially my idea was that I would write another post when I had more experience from the project. Things took a twist after this post though and in the end my time for actual testing & reporting of that had decreased quite a bit. This was perhaps the main reason for not writing Part 2, yet.
On my current project I’ve been lately dealing with other kind of visibility challenge. How to get visibility to the detailed progress of development and also to testing of other projects (this is one massive program that involves many projects). When we get closer to summer, I will have more ideas and experiences for those challenges (having visibility). Then I can write the Part 2.
Thanks for reminding me about this.
May still ask, why did you googled “testing, visibility, cdt”?
-Aleksis
Hi Aleksis,
I would like to find a way to communicate and visualize my testing and the results to developers and managers. I work in a small place, we’re co-located (except for the dev and test in Russia!) and I have easy access to my colleagues.
It’s more a question of changing the feeling from test being about bug reports (only) to testing being about information sharing, experiments and investigations!
Pingback: Few Words About Bugs | Flow of Testing