Thinking Visually

Today I finally got around to watching Alan Richardson’s STARonline talk “Thinking Visually In Software Testing” that has recently been published on YouTube for easy access (also embedded at the bottom of this post).

I’m always interested in learning new ways of visualizing information and communicate thoughts in effective ways and so Thinking Visually is a topic that’s right up my alley. Alan’s talk is well worth a watch/listen and if you don’t believe me, I took some quick notes while watching it to help you decide if it’s worth your time or not. (Hint: It is.)

Described in one sentence, the talk is about using models and diagrams to aid test planning and communication of the testing effort. It covers an explanation of what Alan means by “thinking visually” but it also describes the opposite of thinking visually and also contains a very amusing part with examples of how to best “trap” your thinking and how to best document your trapped thinking so that your readers will gain no value from reading your documentation. Hilarious. Also, as you listen to Alan’s examples of trapped thinking being presented in your average test plan or report, you will probably realize that you see this kind of documentation quite often.

I do recommend that you listen from the beginning of the talk, but if you want to hear what I’m talking right away, you can skip ahead to about 16:48 for a good laugh. That is, until you also realize that some of this stuff is something you yourself have been doing or maybe are still doing quite often. At least that’s what I realized. Alan suggests that we go through your own documents and read it with a sense of humor, which will help us spot these things more easily, and maybe also help us stop doing them.

But… going back to the beginning (how’s that for structure), one thing that Alan said early on was something that got me thinking about how I approach documentation and debriefings:

“I would rather see your thinking, than see what you think your thinking should look like.”

In other words, the way you are presenting your test strategy, test ideas or test results, should demonstrate that you’re putting more effort into the thought process than you are into the documentation process. So, focus on showing that you are thinking and that you are thinking about the testing task at hand, rather than presenting something that suggests you were focused on thinking: “How can I fill in this template”?

“If you don’t think in the first place. If you don’t have a model about what you’re going to do, your communication will be unclear, and you won’t convince, regardless of how well you fill in the template.”

I personally like to see more test plans focus on showing me that the tester is thinking, rather than focusing on exactly what they are thinking. Why? Well, test plans are usually born before testing starts, at a time when we know the least we’ll ever know about the thing we’re actually going to test. So if I’m one of your stakeholders and you show me a plan that tells me exactly what you’re going to do and that you have it all figured out… then the only thing I know for sure is what your testing will not be like, because no test plan fully escapes first contact with the product unscathed.

But, if you can show me that you are thinking actively, from many different angles, and that your thinking is open to a changing context, then I will feel more assured that you will do a good job once you get your hands on the product. I don’t want testers who can follow directions. I want testers who can think for themselves.

Ok, back to the presentation. Alan shares a few of his principles for how to approach documentation (somewhat paraphrased):

  • How little can you get away with?
  • Make the templates work for you, not the other way around
  • Put important information first. Make what’s important obvious
  • Summarize for the reader
  • Meet the reader’s needs

I’m running a bit long with this post, but it turns out that this was a very quotable talk, so I’ll leave you with a few “sound bites” that I took away from listening to this talk, that might trigger you to go and watch the whole 25 minutes or so of it yourself.

I learned that communication is not what I give, it’s what people take from what I present. So I have to help them take it in the way that I want […] to focus on what’s important.
– – –
When you create a mind map your default relationship is a parent/child decomposition, but there are other relationships in your model and you may need different visual models to draw that out.
– – –
Different tools support different styles of thinking. You get different value when you model your thought process in different tools.
– – –
Don’t think that you can get away without thinking.

EAST meetup #6

About 6 months ago, a few testing peers in Linköping, Sweden, started  a local competence network group that we named “EAST”. The name itself doesn’t mean anything, but suggests that we reside in the south east parts of Sweden and that we’re welcoming people from all around these parts, not just our little town.

The idea was to get people from different organizations and companies together to talk about test and to help each other learn more about testing by sharing knowledge and experiences with each other.

So this past Monday I attended the 6th meetup with the group. We’ve gone through a couple of meetings in the early stages where we got to know each other and talked about what we all do at our respective companies in terms of testing. By the 3rd or 4th meetup, we were starting to have more prepared themes for each meetup and this time we actually had two separate themes prepared.

First, we got to listen to Hanna Germundsson who presented a software testing thesis she’s working on, geared towards test processes and minimizing testing related risks. We got to ask questions and also had time for some open conversations in the group about the different questions Hanna presented. There will be follow ups to this one for sure. Haven’t seen that many software testing theses before. Very cool.

For the second part of the meetup, a couple of people talked about their experiences from the Let’s Test 2012 conference. While it’s of course fantastic to listen to people talking about this conference that I helped organize as an event in general, it was even more cool to listen to them describing specific take-aways and learnings from the different tutorials and sessions they attended. Check out the Let’s Test 2012 archives page for slides and other material related to the conference.

EAST will take a break over the summer, but we’ll be back in force this fall. If you live nearby and want to participate then I suggest you join the EAST LinkedIn group to stay in touch with news and announcements. Or follow @test_EAST on Twitter. Or both.

The little blog that could…

People sometimes start blogs, write a few posts and then they die away. I’ve taken a slightly different route. I started this blog in June of 2007 and has since then not written a single post. Not one… Until now… So now that I’ve decided to resurrect it 5 years later, I’m curious to see if I can keep it alive. I suspect that before to long I’ll start treating it like I treat my Twitter account. That is, long periods of nothing followed by days of super intense posting every now and then (usually when at workshops, conferences or other gatherings).

Some of you finding your way here already know me as a software tester. That’s good, because that’s what I intend to blog about here, so you don’t have to spend time getting to know me a second time around. If you know me as anything other than a software tester then you probably won’t get much out of following me through this forum. But I’ll still be your friend on Facebook, Twitter, LinkedIn, Entaggle or some other social media if you’d like. Or maybe even in *gasp* real life.

That’s it for now. First post done. There will be more to follow. Soon.

Or will there?