Key testing skill: Thoughts into words

Background
During SWET 4, one thing that really struck me was how amazing the other participants were at quickly and accurately turn their thoughts into words. It was probably the most striking difference I noticed between myself and these experienced testers. Since then I've kept thinking about this skill and how to improve it. This is my thoughts so far...

Why
One of the early slides in the RST material starts with: "Testing is in your head" which I think sums up why this skill is so crucial. You need it if you want anyone to understand anything about your testing. Some examples; you need it to get:

• Programmers to understand your bugs
• Stakeholders to understand why these bugs are important
• Your employer to know why (s)he needs you
• Your colleagues to know what you're doing and how it's going
• Anyone to understand your problems
• Stuff on paper (strategy, results, methodologies etc.)
• You to understand for yourself what you are doing/have done

Notice the list doesn't mainly consists of stuff only some test thinking expert needs to master, it's stuff every tester needs to master!

How can you improve this skill?

Since this skill is fundamental to testing you will practice it to some degree by just doing ordinary work but the ideas I've listed below are ways I've found more efficient either as ways to practice the skill or to get feedback on how well you're doing.

Answer the fundamental questions

For many questions the answer is far less useful than the process of getting to an answer. Some examples in testing:

• What does it mean to test something?
• Why do we need testers?
• Can't programmers test themselves?
• What's the tester's role?
• What is a bug?
• Do testers need education? Why? Why not?
• Can we find all bugs? How? Why not?
• How do you know when you're done testing?
• How can we measure efficiency of testing?
• How do we know what's important?
• Why do we run extreme tests?
• Can we on beforehand figure out what to test? How? Why not?
• If we know the status of a product shouldn't we decide whether or not to ship?

Can you answer them? Is your answer a quote from some famous tester like "a bug is something that bugs somebody who matters"? How do you know who matters? How do you know what these people think? Is it enough if one out of a million of these are bugged? Two? Five? A hundred? If we expect someone to matter later who we expect will be bugged about this, is it a bug? If people who matter don't know about something, e.g. a missing link, but would love it, and be bugged if it was later removed, is the fact that it's missing a bug?

The questions I asked above is exactly the kind of questions I want to you ask and try to answer. It's a kind of mental gymnastics that will not only help you improve your ability to put thoughts into words but it will also help you learn a lot more about testing (which will be a common theme for the rest of this blog post).

Blog

I brought up the importance of blogging way back in my 2012 refelction posts, there you can find a bunch of motivational links and tips on why to blog.

Anyway, I get two things out of blogging relevant to the topic:

1. Feedback on how well I present/explain my thoughts (if people read and react)
2. An efficient way of practicing the act of putting thoughts into words

The second point depends on that I write about my own thoughts and not just reference what other people say.

Talk about test

Talk to colleagues, speak with people on Twitter, go to conferences/meetups, present. All these things force you to practice the art of putting thoughts into words, some of them also force you to do it rapidly to keep the conversations going which adds another dimension (which, for instance, blogging doesn't).

Explain what you do to non-testers

Have you ever tried explaining what you do and why it's important/interesting to someone like, say your mom? Or boss? Or best bud? Or some programmer you know? Or maybe you from before you became a tester ("hey myself, you're going to become a software tester and you'll love it, let me explain to you why!")? Try it, it's a lot harder (at least for me) than you might think. Also it really forces you to look deep into your thoughts to find out what things really mean to someone not familiar with testing (sometimes it helps you figure out what stuff really means in a more general/other context than testing).

Ask for feedback
It's important to practice but it's also important to know if your efforts are paying off. "Am I really better at explaining what I do know?". You can ask pretty much anyone how they interpreted you explanations and/or how easy they though your explanation was to understand. Here are a few quick, general example:

• Was my last bug report clear to you? Did you miss something?
• Was my last debrief useful? What could I've done to improve it?
• Did you understand my explanation or what part was hard to understand?
• Is it clear to you why I think we need to use an exploratory approach?

Question stuff

If you walk around and accept not understanding what others try to communicate to you I believe there's a great risk you do the same about your own explanations/thoughts. Try to get out of this by questioning anything you don't believe in and ask for another explanation whenever you don't understand something. I've found this to really help me question my own believes, assumption and opinions.

Good question to ask yourself after any explanation:

Would my dumbest colleague understand this and why not?

As a recommended reading on this I really love this blog post from Tommy MacWilliam.

Mentor someone

I've just done this briefly but I find it a great way to force myself to explain in detail what I'm doing and why. It also provides me with a great possibility to get feedback, both verbally and as I monitor my pupil's improvements.

Rapid Software Testing

The Rapid Software Testing course is a lot about trying to get you to think like a top notch tester. One of the key aspects practiced during this course is explaining what you do (putting thoughts into words) and build the courage to do so. I highly recommend the class for many reasons, this is definitely one!

Summary

Putting thoughts into words is key when doing any form of testing (planning, executing, bug reporting, following up etc.). Ways I've discovered that works well for me to practice this skill is:

• Question the answers, why is this answer true? Is it really true in this context? When is it not true? Why?
• Try to come up with your own answers and refine them using questions
• Blog, or write about testing in some other way
• Talk testing whenever possible
• Ask for feedback
• Don't accept not understanding neither your own nor others explanations
• Become a mentor to force yourself to communicate your thoughts
• Rapid Software Testing is a great course to help you improve this skill