Visibility of Our Work

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.

Advertisement

Discussions on Twitter (I)

Saturday night (Finnish time) I witnessed interesting discussion about testing between Michael Bolton, Iain McCowatt and Pete Walen on Twitter. They were discussing on how people can’t distinguish good and not so good testing. At one point discussion was dying and I jumped in as I felt there was more to juice from it. I took screenshots of the discussion, but be aware that some tweets are missing as I felt that to make the flow of discussion more balanced, I needed to modify it little bit.

Here we go:

At this point it seemed that the discussion was dying and I wanted to see it continue as I found this subject highly interesting.

After this I tried to forward discussion on different direction. I wanted to think more about the big picture and trying to figure out why and who we are really testing for.

After this I went to sleep and continued next day the discussion with Michael Bolton with few tweets. Here are just few of those that I found most interesting. If you are interested all of them, go to my Twitter profile :)

 

Final words

When I was talking about making money (or profit), I was trying to explain that if the company goes to bankruptcy, there is nothing to test. So the focus should be on how we can by any means available shape the product via testing so that it helps (sell, perform, making profit, whatever you call it) our company.

Actually this is more of a statement: “Anything that distracts or blocks us doing the testing in the way we see it done optimally, is not just hurting our testing, but in the end, our company and its ability to survive. ”

P.S. Thanks for Rosie Sherry for the tip of adding tweets to blog post.

P.P.S If you are wondering the ‘(I)’ after the topic, that’s a Roman numeral referring to that this will not be the last post about discussions on Twitter.