28 May 2013

Exploring what I know to learn something new

After reading an article tweeted by Tobbe Ryber I made an interesting connection...

Wouldn't a profile similar to what was described in the article be possible to create using Louise Perold's Test Planner from Let's Test?

So I quickly tried it ending up with the following columns:

Problem: What problems would I be able to solve for a company?
How: How do I act/what do I do to solve the problems I say I can solve?
Success: How would my work benefit the company? What will come of it?
Failure: How do I usually screw up / fail to meet expectations (incl my own)?
Data: What usually varies between companies I've worked for (how has that changed my success/usefulness)
Issues: What do I typically need from the company to function well?

When doing this I suddenly thought: Maybe the same approach could be useful when planning my CAST presentation? Or maybe when talking about the way forward with the product I test? Or maybe my travel to Madison? Or...

Well, I've just spent a moment thinking about this so it might be crap but I still find it interesting that something I learned specifically for testing seems to be useful in so many other contexts.

Thank you Louise for providing me with an interesting tool that seems to be useful in very many cases! (give me a day and the number of ways to use it will have grown substantially... I think .)

So how can I apply what Ilari, Huib, Jean-Paul, James, Johanna, Leo, Griffin, John, Steve, Zeger and Scott talked about in something else but testing? I'm inspired to figure that out next...

And how can you use what you learned in other ways than described/intended by the presenters? And what can you learn from doing that?

... Even more interesting: What, currently not test related, have you learned that could help you improve your testing?

Good luck exploring what you already know to learn something new!

23 May 2013

Let's Test - a summary


Sunday evening
  • You are never alone (if you don't want to)! Just sit down at a random table or start talking to someone you've never met before. If you don't dare doing that, just stand still and someone will approach you. The amount of people I got to meet in three days blew my mind! Thank you everyone!
  • The energy also struck me. Every discussion had a wonderful flow; people cared, people was thinking and people was curios.
  • Putting personalities and, sometimes, faces on people from Twitter was a cool thing. 
Keynote: James Bach, How do I know I'm Context-Driven?
  • We need to identify and clear shallow agreements. Questions are a great tool for this.
  • Context-Driven can mean a Paradigm, a Community and an Approach. Don't confuse the three, for instance, if your paradigm is Context-Driven you can't just jump in and out, you are Context-Driven (by choice) on the other hand, the community is something where you to some degree be part of while still being part of another community or having another paradigm.
  • Greeters and Guides are the people that introduce new people to Context-Driven Testing and help them and others grow inside the community. These people are key to making the community thrive.
Tutorial: Ilari Henrik Aegerter, The Challenges of Brilliant Observations...
  • People take their decisions based on what they observe, or rather perceive they observe. This makes observational skills a key in most aspects of life. In testing they are our bread and butter in finding/providing important information.
  • There are so many things biasing our observations (old models, language, instructions/provided information, distractions and a whole lot of other things) and we can't do much about many of them per se. However, knowledge and critical thinking can help us be aware and chose different approaches to help work around them.
  • When communicating observations it's important to avoid ambiguity when possible: this is (what is "this"?), preferred (by who?), few (in comparison to what? how many?).
Comments:
I love how Ilari approaches questions. He has an amazing ability to just suck up the question, think, ask for additional information and form a well constructed answer in seconds, through all this he always keeps his calm. I have a lot to learn from this guy! (especially as someone opening my mouth before even starting to think ,)

I also like how Ilari left us with a lot of tools but not much instructions on how to use them. I've already taken on the challenge of finding ways to incorporate this new knowledge in my daily work.

Tutorial: Huib Schoots and Jean-Paul Varwijk, Thinking and Working Visually
  • Give visualization a chance! You don't have to be an artist to sketch, make mind maps or add illustrations, but you do have to actually try!
  • Cover your walls with sketches, diagrams, illustrations and other visual representations of you work.
  • Get a magic marker (Edding 345, grey marker, edding.com, EAN: 4 004764 841592) and even your bad images will start to look cool. 
This is what you should aim for in a tutorial. Left is before, right is after, can we agree that this is a significant improvement? (even without the magic marker by the way). With better light and some quick editing these visualizations could also be used in future blog posts, cool bonus!

Monday evening: Takeaways from discussions
  • Every time I do even the slightest attempt to use the Socratic method I and, as it seems, others learn something. Driving a discussion using questions is a rewarding and useful skill!
  • A role is not the same as responsibilities or skills.
  • If everything is considered priority one, nothing becomes priority one.
Keynote: Johanna Rothman, Kick-Ass Manager
  • Where do you want to go, what career paths matters to you?
  • To the business, bugs are not an interesting problem, but the complications of them are!
  • What is relevant changes over time, you might one day wake up and realize perceived quality is suddenly a much more important issue than functionality and rapid shipping (or in any other order).
Comments:
For most summaries I've tried mixing what the presenter seemed to focus on and what I took away. For this keynote it's only what mattered to me cause I had three things that really did matter. I urge you to check out this keynote yourself when/if it becomes available! (in case you weren't there)
Session: Huib Schoots, Future Roles and Trends in Testing
I could list the things discussed (or well, actually I couldn't since I didn't write much of it down) but the list, as Huib said, is not what's relevant. Instead, start thinking about what might happen, how that affects your work and prepare yourself for what's relevant to you. It's a huge topic and there are obviously no known answers but you better be ready cause the future will happen no matter what you want.

Session: Leo Hepis, Linguistics, How to Keep a Dialog Constructive
  • Volunteer! You might feel uncomfortable being put in the spotlight but look at it as an amplifier for learning. Also, if you're one of those who want to build a brand I image this is a good thing to do cause I've not lowered my respect for any of the volunteers in any of the sessions I've attended but I've sure found a couple of people who've earned my respect by doing it (and sometimes you get away with cool stuff, right Kristoffer? .)
  • Keeping a discussion cooperative is key if you want to effectively transfer information.
  • At least for me, it's easy to provide an answer before I'm sure of what answer I really should provide.
Session: Griffin Jones, What is Good Evidence?
  • Griffin had a lovely list of attributes to check for in a piece of evidence, check out his slides!
  • There's a difference between what we actually did and what we intended to do (hello "passed" test case, I have no idea what actually made you "pass").
  • Discouraging feedback, like leaving out confusing/unexplained/contradictory details/data/observations or other things that might conflict with your verdict, hinders the possibility to critically analyze a piece of evidence, which hurts the validity of your evidence.
Session: Louise Perrold, The Test Planner
  • Start with Problems: Which are the business problems we try to solve with our product?
  • Make additional columns for each of the things below and populate them as well with items:
    Success, what represents good
    Failure, in what ways can the product fail, what consequences may occur
    How, how can we test this product (logistics and techniques)
    Data, what variables do we have
    Issues, what do we need, to be able to test
  • Use the items from each column to inspire/spawn new items in the same or other columns. Repeat until satisfied.
Comments:
Probably the most "loosen up" (laughing, smiling, chatting, casual) session I went to, which was a great thing. Don't know if it's a coincidence / wishful thought but I feel like I remember more from this one than most others.

Bug hunters will notice "Data" seems a bit out of place... answer is quick and dirty graphics editing on a really not professional level.

Tuesday evening: Test Lab
  • A great test leader can really make a difference! Less control more empowerment (e.g. coaching, empathy, support, freedom) is one of the keys to that for me.
  • It's really fun to sit in a tight group and just work together focused to find relevant product information (feel free to call it bugs in this specific case). By the way, I'm at a company where we already do that and it's just as fun "at home"!
  • It's hard to explain a bug in purely text, images and/or videos are often great compliments.
Session: John Stevenson, Information Overload and Bad Decisions
  • S L O W   D O W N !
  • For instance requirement documents can prime/anchor you to certain solutions limiting your ability to see important options. Be aware of this.
  • We often make quick judgements instead of think. We need to be aware of this and apply critical thinking to avoid missing key observations.
Session: Steve Smith, Debugging Human Interactions
  • There is a relationship between low self esteem and very active defense reactions.
  • We don't receive sensory input (like seeing, hearing etc.) in an objective way. Reactions to certain sensory input can for instance make us shut down/forget/ignore other sensory input.
  • Being aware of how sensory input is "used" (forming one or more meanings of the input, feelings, feelings about having these feelings, prepare defense mechanisms and setting rules for commenting) can help understanding your or someone else's reaction.

Session: Zeger Van Hese, Testing In The Age of Distraction - The Importance of (de)Focus
  • Y O U   D O N ' T   N E E D   T O   R E S P O N D !
  • Receptive distractions reloads/refreshes us. Examples: taking a walk or having a coffee
    Deceptive distraction drains us. Examples: meetings or emails
  • Observe when you start to procrastinate and see if you can find certain patters/scenarios.
Comments:
Zeger commented that flow, in the original description, "suspends critical abilities", which might be a bad thing for testers. My interpretation is that it rather inhibits what may distract you from proceeding and in a regular creative activity that thing is criticism but in testing, criticism is more or less the "creative activity" itself. I would instead interpret flow, in the context of for instance exploratory testing, to inhibit the risk of you rejecting a critical observation. But that's just a thought that popped up as I reread my notes. Feel free to comment or question (directed to anyone, not specifically to Zeger).

Keynote: Scott Barber, Business Value in Testing
  • Testing as an isolated activity has no value... but the resulting information is worth something.
  • Sometimes the needs of the Business overrides the needs of the Users (e.g. a product must get out on the market to not miss a marketing window).
  • It's important for testers to learn basic business lingo to improve our ability to communicate information. Hopefully that can also motivate business people to learn basic testing lingo as well.

Reoccurring themes throughout many of the conversations and presentations I attended
  • We need to stop multitasking!
  • Beware of various kinds of bias that limits what/how we observe.
  • People, people, people! Like it or not, our business is all about people!
  • Keep things simple! E.g. leave out redundant/irrelevant information.
  • We need to understand the business implications of what we do.
Some comments I liked
Notice! None of these are exact quotes (I suck at noting down exact quotes), I hope I haven't messed up the original meaning due to this, please correct me if that's the case!

Great enough instead of good enough or perfect
/who said this, Martin? Leo? Maria? Was after Steve Smith's session.

Jerry Weinberg is Yoda
/James Bach, keynote, completely taken out of context by the way

It's all about following your energy
/Huib Schoots, lunch

There's no reason not everyone can become awesome
Johanna Rothman, keynote

A few people that really made an impression on me
I started making this list but soon realized I had at least 20 people I wanted to add and it just became silly. But, stubborn as I am, I want to highlight three:

Richard Robinson
For a Miago Do belt Rich got the challenge to form and lead a test team with the mission to test XBMC for roughly an hour and a half and finally debrief the results. I was fortunate enough to be part of this team cause the experience itself was awesome and I think Rich did a kick ass job! Whenever I'm doing something test leader:ish he'll be my role model! (read the first item in the Test Lab summary further up for some reasons).

Huib Schoots
Pure energy on two feet and with a well earned Buccaneer cap on his head. Interesting, helpful and intelligent. His (and Jean-Paul's) visualization tutorial also had an instant effect on my notes which was awesome! Next mission, inspired by the mentioned tutorial and other discussions, is to cover the office with various visualizations of our product.

Johanna Rothman
Apart from delivering a keynote that helped me realize/explain certain things (see summary further up) I really enjoyed just speaking to her. Apart from curiosity, a willingness (or even urge) and ability to help, she seems to deeply care about everyone she's speaks to. Amazing person, I truly value what she taught me during meals and through her keynote! Yeah, and it's hard not to mention how she stands up for what she believes (I think everyone attending Let's Test knows what I mean)

A lot of other people deserves more than a short mention, like Helena, Steve, Jari, Ilari, Jesper, Martin, Kristoffer... but the line has to be drawn somewhere. But let me just say: Thanks to all of you for the amazing discussions, exercises and lectures I've had during my last three days! I deeply appreciate every single one of them!

Wrap up: The Taxi Driver
In the taxi back to the train station I spoke to the taxi driver. I think his story well summarizes what people on Let's Test was all about.

Short version is he had been a hairdresser for 15 years but lost his energy. So he changed career and started driving a cab. What he loved about it was feeling free and the human interactions, he also liked how his taxi company's ethics resonated with his own. When listening to him my impression was he loved his job and that he truly cared about being the best taxi driver he could ever be. Even though leaving Let's Test I was smiling the whole way, that guy would had fitted perfectly at Let's Test.

14 May 2013

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