My CAST presentation

Slides
Handout (used during the exercise)
Skill Development List and Personal Manifesto

* The links are currently broken, unfortunately I cannot fix this until I'm back at work since I don't have the files on my home computer anymore. Stay tuned...
And credit to Srinivas for pointing this out!, thank you!

Feedback
One cool thing about presenting at a conference like CAST was all the feedback I got. First Ilari, Bernie Schroeder and Martin Hynie gave me some great things to think about/improve in the way I was presenting (avoid looking back at my slides, tweaks to my body language, tweaks to tempo and pauses). Simon Schrijver, Erik Davis, Phil Kirkham and a whole bunch of other people really boosted my confidence with their encouraging comments afterwards. Peter Walen, Brett Hinton, Jonathan together with several others asked brilliant questions and/or added valuable content during open season that helped me understand my topic even better and finally a handful of people from the audience shared stories related to my talk. All of you who attended: You really helped making my first ever conference presentation better both for me and, I'm sure, for the other attendees! Thank you!

Another kind of feedback was the recording. Listening to that helped me realize:

• It took me a while to get the energy going
• I had some annoying "ehh" and "and" early on
• My flow was really nice
• I should not interrupt the facilitator
• I've always been a bit annoyed with how my voice sounds but listening to the recording has helped me appreciate it instead.
• I felt several pauses was just a fraction too short (for me)
• Well rehearsed parts did not sound "flat" or "boring", rather the opposite, so I'm very much questioning if I can "rehears too much" which some people warned me about before.
• 26:13 (masochist "joke")... WTF! Still hurts to hear myself say... whatever I tried to say .)
• I felt my energy raised every time I made some kind of imitation (THANK YOU HELENA)
• The tempo was nice, could have varied it a bit more for greater effect but better than I expected
• I hardly rambled / repeated myself at all... once again I think rehearsals played a key role.

Forgotten part
Remember how I added balance in my 10 second summary of Yes Man (31:10 in the video)? Last winter I realized I couldn't just answer yes to everything. Sure cool things happened but that required me to spend quite a bit of time away from my family. That, after a while, became too much time away. So family has turned out to be something I need to think about before answering yes to too many cool things. Your balance might be something else like time with friends, time to sleep, travel costs, mental energy etc. No matter what it is, keep it in mind.

But that small addition was all I missed! Hurray!

Answering a few questions
I got a few questions I couldn't answer during the open season that I promised to get back to when I had been thinking a bit more so here we go:

Jonathan: Was there anything on you list you tried but you completely failed at?

Just before I started the list, at my former work, I tried to change how we tested in my team to make it more "Context Driven". I failed in so many ways, more or less putting the team in a position where noone knew what was tested, what was not tested, how well the testing had went and there was not a single document or statement that could help anyone figure that out, mostly because I didn't know either.

Later, actually partly thanks to the list, all that turned into one of my coolest adventures as a tester, but up until that transformation occurred it was a major mess up.

My way of dealing with it back then was to try and cover it up, which is not a good approach by the way. Afterwards though I quickly turned it into a learning experience trying to figure out why I messed up, what I could learn from it and what positive changes actually came out of it. I think that's my general approach to failures, accept what happened, accept I can't undo anything, try to learn as much as possible and move on.

Also, in my blog post from yesterday I spoke about my history of bad presentations.

Peter Walen: What is it you have done that you kind of wished you hadn't done

I don't regret anything I've done to myself or others as long as I or whoever I did something to, feel happy about their current situation. And if someone else feels bad I try to focus on what I can do to improve their situation rather than blame myself for something I can't change anyway. So far that strategy has worked out.

The story that still bugs me the most, that I can think about now, is when I was caught lying in like 5th grade. It was rather innocent, our teacher asked us about the temperature where we lived (don't ask me why). I lived far out on the countryside and we quite often had a degree or two colder than in the city. So I strategically grabbed a chair so that I would be asked last and always answered 1-3 degrees lower than everybody else. One day a classmate outsmarted me though and answered a ridiculously low temperature. I didn't notice the temperature he suggested was like ten degrees lower than everyone else's so I just answered like two degrees lower than his... and suddenly everyone started to laugh.

But like all the other stories that taught me a valuable lesson so I've come to terms with it... still hurts a tiny bit to admit though...

... From a testing perspective I can't really think of any... maybe that I didn't start to care about testing earlier but once again, my current position rocks so can't really feel bad about that either.

Simon Schrijver: How do you rebound from mistakes
I (and Simon himself!) answered that during the presentation but please check out the previous answers for some additional details.

Additional credits

Pekka Marjamäki
The kind and brilliant tester who offered me coaching before RST.
He will be speaking at EuroSTAR! Check him out!

Henrik Emilsson
Henrik provided the invaluable feedback that turned my "not so amazing Lightning Talk" into a kick ass learning experience.

Johan Jonasson
The person who helped me find my local test community, helped me survive my first peer conference and was part of founding Let's Test, what's not to like about him .)

Pierre Rasmussen
Mentioned during open season as the friend who shared his weekly reflections on Twitter. I have been too inactive for too long to say if he still does but no matter what he's a brilliant test-infected programmer worth checking out.

My success story, a story about failures

I have a lot of things to say about CAST, to people who would like to speak at a test conference, about personal development and about my own presentation. But first a few stories I want to share, hopefully busting any ideas about "some people are born to speak while others aren't".

Messing up a play

My first memory of something presenter-like was in 4th grade. 4th, 5th and 6th graders were mixed together in drama groups and something like once a month each group performed a play for the other groups. My group's first play was ruined. How? Well I couldn't shut up. I interrupted the other actors, screwed up jokes by explaining even the most obvious ones and was too nervous to remember any of my lines giving everyone else a hard time... The self elected leader of the group (a 6th grader) was furious when all of us gathered afterwards to discuss the play.

My first presentation

Moving on to 7th grade and the first time I presented to a larger group of people (~30). For this presentation each of us were given a famous author to talk about, mine was Charles Dickens. I was so nervous, but I had rehearsed a lot and prepared a rather detailed script so everything should be fine. I went up on stage, took a couple of deep breaths and said... Blaghl...bl..br, which unfortunately doesn't make any more sense in Swedish. I couldn't form a single word! I couldn't even say my name! I tried several times with every failed attempt just inducing more and more panic. Finally I threw away the script and just relied on my memory, which was no problem at all since I had rehearsed sooo much. When the torture was finally over several class mates came up and said: Wow, you were really calm when presenting... I was still shaking.

At the university

I volunteered to become a university ambassador. One part of that job was to speak to groups of high school students. One time the group was rather large, about a hundred people. I froze! I froze for something like 30 seconds (felt like 10 minutes) before I started and when I finally did I think I forgot to tell them like half the stuff I was expected to present.

Improving legacy code
Moving on a few years, now as an employed software tester. I had suggested a very vague idea, basically saying we had to work with the quality of our legacy code. So I was asked to present my ideas to the rest of the department. To make matters worse I got sick a few days before and due to that I had basically no time to prepare myself. I also knew that the material was way too abstract due to the fact I didn't really understand the details. Any professional would say: "I'm very sorry but I'm not ready to give this presentation" (a question I was even asked due to my sickness)... I didn't. The result?
"We need to work with the quality of our legacy code. A few things I've thought of izzzz...", what happened after that is a bit blurry but apparently one of the managers saw I was about to pass out and caught me before I fell, while someone else grabbed a chair. I got some water and actually finished the talk sitting down, still a bit dizzy... it was a memorable talk but not for the reasons I would have liked.

CAST warmup
Let's finish with a much less dramatic story. Just a few months before CAST I presented at a local test meetup in Malmö, Sweden. I would give a short talk on security testing. I felt calm until the moment I sat down in the room. After that anxiety rapidly (and for me surprisingly) built up. I think one of the main reasons was I simply hadn't rehearsed my talk. When Henrik Andersson offered us a beer I quickly grabbed one and it was perfect to ease the anxiety (something I haven't told him). However, knowing I "needed" a beer during one of my last public presentations before CAST was not really... comforting.

CAST 2013
Let's save this one for another post but short story is it went great!

Why am I telling you this?
Long ago I had the misconception that speakers at, for instance, conferences were natural talents who just had something I didn't possess. A misconception with an interesting twist as today I often hear people call me a naturally talented speaker. What I've learned, and hope my stories help you see as well, is that that something is mostly hard work. If you decide you want to learn to present there's no exotic gene stopping you.

Why am I telling you this... 2?
You might look at the stories I shared and say: "Why not focus on your successes?", but here's something cool: The stories above are my most important events as a speaker. Without them I wouldn't be in the position I am today as a speaker and if I sound insane, let me give you some examples:

Messing up a play

• I need to sometimes stop myself and simply shut up.
• I need to think about what's interesting to the listener, not just what I want to say.
• Being well prepared (rehears) is key!

My first presentation

• I can actually present.
• I don't need a script.
• Even the worst case scenario wasn't that bad (you could argue that passing out is worse than not being able to say a word but they're pretty close).
• There are things I can't seem to learn/fully understand without actually failing first.
• There's no such thing as a failure or success, we always fail to some degree and we miss out on a lot of potential success if we don't take the opportunity to learn from these small or big failures.
• As long as I rehears, things seem to work out okay no matter what.

At the university

• Silence is actually not that bad.
• Less is more, I forgot a lot of the prepared material but in the end that seemed to make what I said, stick better (based on reactions from students after the presentation).
• You can turn a bad start or problematic presentation into something great, it's never too late. This one actually turned out as one of my better presentations as an ambassador.

Improving legacy code

• Doctors didn't find any problems with my heart, lungs or head (obviously physical health was enough). That's actually quite comforting.
• Due to all the medical tests I had to leave a whole bunch of blood samples which eased my fear of needles and hospitals.
• ... and that taught me a valuable lesson about fear: Fear is much about not knowing the outcome, not about the experience itself. Understand that and a whole lot of things stops being scary (very, very powerful insight).
• I know my limitations better.
• I know when to say no better.
• I know the possible consequences which further helps me say no when I really should.
• I've learned the value of understanding the content I'm about to present.
• I need to rehears.
• I need to rehears.
• I need to rehears.
• I've learned code quality is much more complex than I once thought it was.

CAST warmup

• I need to rehears
• I need to rehears
• I need to rehears
• Open season with K-cards is actually not that scary (I had not tried that as a speaker before)
• Beer solves a lot of problems... kinda.

You can do it!
If you feel like presenting at a major conference would be cool but you hesitate since you're not a "natural speaker", Think again!

Practice
At work, local meetups, small conferences, at home or maybe checkout Toastmasters International (Credit to whoever gave the lightning talk about Toastmasters at CAST, just found out we have a local club where I live so I'll give it a try!).

Challenge yourself
Try new things, get out and speak in front of people, record yourself, test various formats, present without slides, try drama or stand-up, present in front of more people, present in a non-native language...

Wrap up
I think I'm a talented speaker today, and that's not just based on my CAST performance. But it has little to do with my amazing genes, it has to do with practice and challenging my limits. I'm pretty sure all your favorite speakers have similar stories (or at least I hope) and that their biggest secret too is practice.

So don't wait to become a great speaker, act to become a great speaker!

Oh, I forgot!
A key inspiration for this post as well as one of the real highlights for me during CAST, was Dawn Haynes' keynote. Make sure you check it out!

Oh, I forgot... 2!
During open season, several people asked me about my failures and how I dealt with them. Hopefully this post answers some of those questions. If not, please ask your question again (Peter, Simon and Jonathan were the ones I remember, did I miss anyone?).

Thank you for your time and good luck with your presentations!

CAST, A sneak peek

In my last post I promised to release a sneak peek of my CAST presentation. Even though I'm infamous for being too optimistic and missing deadlines, that promise will actually hold true.

So... what will I talk about?

The story
In May 2012 the first ever Let's Test conference was held.

When I heard about this conference it immediately grabbed my attention. It was just a train ride away, the tester's I wanted to meet would be there and the general setup felt spot on for me.

So I prepared myself to just bash into my manager's office and demand he sent me to this amazing conference but... that never happened.

Instead I convinced myself, I wasn't ready.

Just over a year has passed but in just a few days I will present at CAST; an opportunity I got thanks to writing an abstract just 8 months after missing Let's Test. Today I am the tester, I before Let's Test told others I wanted to be but never dared to become... All that is quite a transformation and how that transformation could happen is what I will walk you through.

Actual content
There are of course a million things contributing to this change, many of which are highly context dependent. But I will highlight four that I think have been key, and try to extract as much practical and useful content out of those as I can. I will actually not list them here but in my 2012 reflections, you can see all of them in action and some of them described. The big difference between that blog series and this presentation is I won't focus on what I actually did (like reading blogs, meet testers, change job etc.) but rather the mechanics that made them happen. To explain that I need an example so even though I said I wouldn't, here is one of the four "chapter": My skill development list. In the presentation I will explain the list in great detail including what made it work, what problems I encountered and how I dealt with them.

I want more!
Okey, okey, that wasn't very revealing but let me give you something that is: Here is my latest skill development list and personal manifesto. In common they have cliché names and that both are very much relevant to this presentation.

Also I can tell you there will be an exercise...

... You will be asked to answer several questions (to yourself)...

... and you will see this guy in many shapes and forms:

Thanks to IBM and Jojo Mendoza for the original pictures that made this guy!

If that's not revealing enough you'll simply have to come and watch my presentation: Making learning my top priority, at CAST.

See you there!

CAST, The story about an abstract

The Challenge
It was late in January. I was spending the Sunday with my kids and fiance visiting my mother. As we were eating my phone did that annoying sound it does when I get a message on Twitter. I ignored it and kept enjoying my visit. Little did I know that the annoying sound was the start of one of my biggest adventures so far.

Anyway, later that evening I finally checked my phone and found this tweet from my, soon to become, manager:

@Brickuz challenge for 2013! "@lperold: We want YOU to tell your story! - #CAST2013 - not much time left! http://t.co/sWF1NoRf"
— Maria Kedemo (@mariakedemo) January 27, 2013

The first thought that ran through my head?
"Yeah right! Like I'm good enough to do that"
When it hit me, I had had the same feeling about Let's Test, 8 months earlier and still regret losing that opportunity and 3 months earlier when I was invited to SWET 4 but that time I accepted the invitation and loved every moment. This was sure a much greater adventure but why not give it a shot?

@mariakedemo challenge accepted! (after a quick chat with my fiancee, condition was for her and the youngest to come with me if chosen ,)

— Erik Brickarp (@Brickuz) January 27, 2013

Getting started
When Louise Perold said "not much time" she wasn't laying. Three days to finish my first ever abstract for a conference talk, add kids to that and I was down to 3 evenings... and I didn't even have a topic.

As the theme for CAST was "lessons learned" I figured I at least had a shot since my career so far was much more about experimenting than reading stuff. After some thinking I came down to three potential topics:

• Note taking - Based on my blog post and further experiences
• Going exploratory - Me and my colleague at Ericsson turned a factory school test processes into a context driven approach in our team. It was an amazing experience with some really interesting results. I will share those some day (you can read a tiny bit here).
• Mindset - I had went from knowing nothing about testing to learn about testing and finally excel to become a tester with ideas others seemed to put value in. What made that happen?

The first one felt like something others would pull off much better (and after attending Huib's and Jean-Paul's tutorial at Let's Test I'm glad I didn't pick that topic). I could have focused on the experimental part but that thought never appeared to me.

The second one felt a bit... well, with me soon leaving Ericsson to join Maria at Verisure it just didn't feel right.

So I went with number three.

Writing abstracts

I have a topic, now let's write an abstract about it... what should be in an abstract? I scratched my head and started browsing around looking at various abstracts. Finally I just shrugged and started writing.

I sent my first draft to Maria for review. We both felt it didn't say anything about the actual content in the presentation so I started on my next one... two days left.

During day two I managed to produce two different abstracts, both having the same basic problem: They described a topic way too big to fit in a 20-40 minutes slot. So with one evening left it was back to the drawing board to either focus on some key detail in my current topic or find a completely new one.

Delivery time
I ended up focusing on a smaller but reoccurring theme in my previous abstracts, that by the way was about the mindsets described in my The year I became a passionate tester -reflections. I wrote and wrote finishing late in the night, making it a completely new abstract that Maria never got to review. As I pressed "send" in the submission form I didn't know what to think. On one hand I was really proud of my abstract, to me it was interesting and well written. On the other hand I felt it was probably having similar problems as my previous abstracts I just hadn't realized it yet.

A first hint
Maria told me she had been asked if she thought I would be able to pull off the presentation (I actually have a background as a speaker but in a completely different area). That question was an early indication that my abstract was at least considered. Suddenly things became real, I might be standing in front of a crowd six months later giving a presentation at a major test conference on the other side of this planet.

Announcements
Finally the day came when presenters would be announced. I had mixed feelings, one part of me screamed "Don't you dare picking me" while the other wanted nothing else in the world than seeing that email in my inbox. The first people started announcing they would be speaking at CAST. After a while it became apparent no such mail was sent to me and I just felt... emptiness.

A couple of days passed. Even though I should be proud of myself for fighting the urge not to write, and later send, the abstract, I still just felt emptiness.

Spam
Two days after the announcements I cleaned up my spam folder. Usually I just press "delete all" without even looking at the content (yes, I once did trust Gmail that much). For some reason I didn't this time. When glancing the list I noticed a mail close the top:

Dear Erik,

Thank you so much for your submission for CAST2013. We are delighted to inform you that you have been selected to speak. Details will follow shortly around the next steps.

Best regards,
Louise Perold and Ben Kelly

Hey Google, that's a really ugly trick! Don't you ever do that again or you'll end up like Yahoo after spam marking mails sent to myself.

So what's now
I've been working on my presentation for quite a while now. Not too long ago though I finally asked myself: "What's the goal? What do I want people to feel/know/do when they leave my presentation". That question forced me to somewhat start over but it's coming together nicely and will be great in August.

The presentation? Well it's named Making learning my top priority and you can read more about it in the CAST schedule. The plan is to post one more blog post before CAST and in that provide a sneak peak of what I will talk about but that's for another day. For now, thank you for reading and I hope to see you in Madison later this summer!

... Oh, and in case you wonder about my promise to my finance: Yes, she and our (now) six months old girl with come with me.

Take care!

Observation Exercise / Experiment

Intro
After attending Ilari's tutorial at Let's Test I decided to write a blog post, with the goal to put what he taught us into my own context as a tester. That post is still in a raw draft state but in the meantime, on a similar topic, I want to share a simple observation exercise/experiment I've conducted.

The experiment
For one week I decided to "actively observe" during my 15 minute walks between job and home. I had no idea what "actively observe" would mean but I figured that would be clear as I tried it (which it did).

First walk
I left my house ready to observe. I started to search broadly just sweeping over my surroundings trying to find interesting stuff. I did this pretty much the whole way, finding nothing. That was a disappointment.

Second walk
On my walk home I decided to stop focusing on finding interesting things instead I simply tried to focus on things and see what came out of it. Bingo! Suddenly I stopped as two cemetery gardeners was cutting the grass with big scissors to get a perfectly straight border between the walking path and the lawn. This made me look at the flowers and suddenly I realized how symmetrically they were arranged. This continued as I started to notice interesting grave stones, grave stones I had missed during my first walk when trying to "observing everything".

Rest of the walks
For each day I seemed to lower my walking tempo slightly and I slowly went back to the sweeping strategy except I didn't just try to get an oversight of everything, instead I swept in the sense of rapidly switched focus from one thing to another.

Observations

• Initially my goal was to find interesting stuff (sweep) but that quickly changed to general curiosity (focus). In the end I didn't care about what I would find, the search in itself was way more interesting.
  
  
• For each day I seemed to walk a little slower. Since I didn't clock myself (which would probably bias me too badly to render any useful results anyway) I can't of course be sure, but it felt like I did.
  
  
• In the beginning I seemed scared of missing something important. That basically made me miss everything.
  
  
• When I swept over stuff the only thing I reacted to was very out of place things (which rarely was interesting to discover/observe) or motion. To change this I had to focus specifically on certain details, living with the fact that I probably missed a ton of things.
  
  
• After a few days I started to look forward to the actual walks, they became a somewhat spiritual exercise. Which isn't strange as it reminds me of many mindfulness and meditation practices I've come in contact with.
  
  
• I think I've started doing this kind of "active observations" in other places as well somewhat unconsciously (just noticed it the other day). This would be quite a significant change since I'm very easily distracted and absentminded, I don't really focus on my surroundings.
  
  
• Being tired (two mornings) or annoyed (one afternoon) significantly limited my ability to observe. This is nothing surprising but still interesting to realize for myself.
  
  
• To be able to ignore moving objects when observing stationary objects takes practice, which is also no surprise but once again interesting to realize for myself.
  
  
• The more I practiced the more I figured out what was interesting for me to observe. In the beginning it felt like I just looked at things for the sake of it, but after a while I started to ask questions and build genuine (I feel) curiosity... I also learned it'll take some time to really master this, my 10x15mins only made me realize I have a lot to learn more or less.

Conclusion
Will this make me a better tester? I don't know and I can't think of any way to measure it and even if I could, bias would probably ruin the measurements. But my guess is that some of these lessons and the practices will help, to what extent I don't know though. Examples could be to practice ignoring movement as I focus on stationary details or the need to focus on specific details rather than sweep. All and all it will at least not make me a worse tester (I hope .)

One interesting question after these kind of experiments... will I do this next week, in a month or a year? I have no idea but I hope so. Just like with training it right now feels like it's a sure thing but give it a few stressed days and I might have lost track, we'll see. No matter what; I've learned some interesting things during this week!

Experience Report: Pairing with a Programmer

Background
It was one of those typical "do or die" scenarios: A feature was implemented that was critical for the project but it was delivered late due to slightly optimistic estimates. To make matters worse it touched on rather fundamental parts of the product making it somewhat complicated to roll back. The job was to quickly test, fix bugs and, in corporation with our product owner, decide if the feature was ready to be released. The feature in this case was rather technical with a simple interface that, depending on configuration, triggered tons of background activity including communication between different servers.

What we did
Me and the programmer teamed up. The first day we worked in front of his computer only. Initially he pretty much explained the feature and I noted down some thoughts and scenarios that popped up in my head. When done we started with the most straight forward scenarios and immediately found some serious bugs that required extensive investigation and experimentation to fully understand. We managed to solve the most critical ones and left not that late feeling really good about ourselves. Day two would be a breeze!

Day two we made an "upgrade" and booked a room as well as brought one computer each. Immediately we found out we had badly underestimated the work left as critical bug after critical bug emerged. As some of them required knowledge we lacked we called in a domain expert to help us and continued to work all three together for the rest of the day (one computer each). Day two turned into a 12 hour long exploration and bug bashing. When done we felt slightly exhausted but proud, it was working!

Some info about the group
I'm a decent programmer and a good tester. The programmer in this case is fairly young but good programmer progressively becoming a better tester. Finally the domain expert is a bit of everything. He knows the system and customers as well as having a fairly good understanding of both programming and testing.

Observations

• We had fun! Personally I liked day one best, not because the presure was somewhat lower but because we cooperated more when sharing one computer.
  
  
• Continuing on the track of computers: I think from an efficiency standpoint one computer each was, short term, mostly more efficient (possible exception would be during the most intense and mind challenging investigations). It's important to note that one computer each didn't mean we just sat together testing individually, what we did was to work together on one task but doing different things (like taking notes, executing tests, monitoring logs, correcting code etc.). Working together at one computer though was a more learning experience and, as I said before, I think it was more fun if that counts for anythings.
  
  
• I feel very comfortable saying we would not had caught and fixed anywhere near the amount of bugs we did if working separately. A few reasons why:
• We have different investigation methods. The programmer did low level investigations really well adding debug printouts, investigating code etc. while I did high level investigations really well checking general patterns, running additional scenarios etc. Not only did this make us avoid getting stuck by changing "method" but also, my high level investigations benefited from his low level additions and vice versa.
• We could share some of the work, for instance I took notes as the programmer ran scenarios. This helped us avoid losing momentum.
• No time was wasted performing handovers from bug reporter to bug fixer back to the reporter.
  
  
• When we worked all three together I felt we often worked in one pair and one person alone (not all the time but most of it). In this case it was probably the right thing to do as we required all three persons' skills but I think that was an exception. My general judgement, only based on my own experiences, is there is little or no gain in being three compared to two if you don't really require everyone's skillset more or less constantly.
  
  
• We learned so much!:
• All three learned new things about programming, the system in general and testing, both from each other and from ourselves explaining stuff
• I learned more about logging in general
• I learned more about the system and feature
• I learned more about the code/code architecture
• I learned more about the others' strengths and weaknesses
• The programmer got help being skeptic about his own code
• The programmer learned some new scenarios his implementations need to handle
  
  
• We got to know each other's personalities and skills better which fosters trust/respect/team spirit.
  
  
• It made us communicate more which helped us gain from everyone's observations (sometimes an observation was communicated that didn't mean anything to the one making it but did to someone else).
  
  
• Pairing also made us stay focused for longer stretches (you don't want to be the first one to procrastinate).
  
  
• A byproduct was code review. As we investigated code sections other improvements/problems/potential problems became apparent and fixed.
  
  
• One thought that popped up was working separately and then pair as problems occurred. However, that would require time to be spent rerunning the actions, explaining the steps and possibly missing crucial details from the initial run. All and all I think there's a place for that kind of approach as well but not that often.

Sum up

I did pair up with programmers quite a few times at Ericsson and found it useful but for some reason I haven't done it on my current job until now. I will definitely continue doing it though, for the learning experience, for the laughs and for the (at least perceived) efficiency gain. Luckily it seems I wasn't the only one feeling that way!

Reflections and feedback request on communication

This is a post in which I will mostly ask for your help rather than me trying to help you. If that's not what you're after, feel free to skip to "Improving my communication" further down.

So what I would like from those of you still reading is any:

• Exercises
• Experiences
• Advice
• Helpful ideas
• Free speculation
• Things to look into
• Things to think about
• Other stuff you think might be helpful/useful

... related to what I'm about to describe. I leave it up to you to decide how to feedback but some suggestions are as comments to this post, email (brickuz(a)gmail.com), Twitter (@brickuz) or Skype (brickuz). Thank you so much for taking your time, I value this tremendously!

Disclaimer
I will talk about drifting as something bad. In many cases following thoughts to explore new ideas are  (I think) a great way to learn but the drifting I refer to is drifting away from a point I'm trying to make ending up with me not coming to any point.

I will also talk about communication only as verbal communication that is not (suppose to be) one-way.

Slowing down my tempo

I speak very fast, something I've done for as long as I can remember. The more excited I get the quicker I speak but it's an issue long before I get excited.

Problems: Sometimes people find it hard to pick up what I'm saying, it creates a barrage of words which makes people lose interest, it (I think) affects my credibility and it makes people lose track making it hard to get what I'm trying to say even when they stay interested and hear the words.

So far I've tried to actively lower my tempo but I quickly forget about it when discussions get intense or when I'm excited about the topic (as a passionate person that happens constantly). I've read before that it may be connected to stress, which is probably a factor and I'm trying to work on that as well, but I doubt it's the main reason. After all I've done this ever since I was a kid.

Lowering my voice

I often talk loud.

Problems: It can make it somewhat uncomfortable to listen to me for long stretches and it leaves a bad impression, especially when it's used to drown out other speakers (unfortunately not uncommon). The fact that I have a somewhat high pitched voice makes it worse I think.

I don't have perfect hearing but I also don't think that really affects this. I would rather say it's a bad habit I haven't learned to control. It also seems there's a connection between me raising my volume and my tempo which makes me believe there is something else that is the main problem.

Come to the point

I often have a point I want to make but I tend to drift off, simply because something pops up in my head and it immediately turns into words. A special case of this is when I throw out a claim and start reasoning around it (is it really true or not) as I speak. I do this in a way that, I don't think, is really helping anyone. Finally a third variant is I associate something said to something in my head giving me a starting point but not having any point to move towards. Even though this is the case I start talking and often end up in a situation there I'm desperately searching for a point to make AKA rambling.

Problems: A very common end result is lots of words, few relevant points which in terms makes people lose interest.

I try, but once again often lose the ability to when excited, to stop myself and just end my rambling as soon as I realize I've forgotten where I'm heading.

Stop interrupting people

I often interrupt the person speaking because I have a point, association or addition that fits in exactly at where we're at.

Problems: Apart from being rude/giving a bad impression, I make the speaker lose track/miss out on valuable information and it seems that interrupting others also makes it more okey to interrupt me more often.

My greatest ally in this so far is a well developed empathy. Thanks to it, "something" stops me and says: "if I speak now I'll likely hurt the person speaking's feelings, or at least rob him of the chance to shine"... not remotely close to stop me often enough though.

How did I come to these conclusions?

• Stopping and reflecting on what just happened after I've gone bananas in conversations
• I'm blessed with some really smart friends who care enough for me to give feedback
• Observations of how people react to/act after I've spoken/rambled.
• Reflecting on things said by people who don't like me.

Isn't this "just the person I am"?
I believe we all have various characteristics, like being impatient or humble. These provide us with some ups and some downs. I'm quite satisfied with the characteristics I have so I'm not really trying to "take the me out of my communication" but... it's also a lot about skill. Sure I get impatient or excited and that affects my communication, but on top of that there's a lot of skill I want to improve.

Why does this happen

Apart from impatience and excitement another thing that seems to "passively" affect my communication is fear. First it's the fear of people not letting me into a conversation. This, based on my own observations/reflections, makes me interrupt more often as well as keep talking without letting other people break in. The fear of not coming back into the conversation also gets worse the longer I go as I know people will hesitate to let me in again, for good reasons, when I stop. This is of course very counterproductive as people will stop listening at some point. Reading what I just wrote actually sparks some thoughts, we'll see where that ends up.

Second is the fear of forgetting about something that, important point, in the moment seems incredibly important (not so much when I say it though). I try to battle this by bringing a notebook but so far it hasn't improved the situation much.

Related to these fears there seems to be a mismatch between how I evaluate the "wow factor" of a thought inside my head compared to how it comes out. I don't think this is based on poor construction of the message, rather that I exaggerate the importance in my head. I think this mismatch is an important factor for me to generate a constant flow of ideas to explore so the problem is probably not the mismatch itself but rather that nothing stops my brain from communicating all those thoughts as soon as they pop up.

Improving my communication

In general, to battle these problems, I try to remind myself that people will only remember a few things I say (in general at least) so I better make sure that what I want them to remember is what's in focus rather than having it mixed up with a million other words and thoughts.

I try to stay aware of my though process and create a small gap between thinking a though and speaking the thought so that I can quickly make a rough estimate of: "is there a point relevant for this conversation in what I'm about to say".

I try to think more egotistically: When listening I generally learn more than when speaking. This way of reasoning has also made me use questions more often to still bring the conversations in directions I find interesting. One byproduct of doing this is I tend to communicate my own messages a lot more efficiently when baking it into this "question driven approach". Questions also help me stay focused on the current topic rather than drifting away. I thank Peksi and his exercise, as well as RST with James, for helping me learn how to do this.

Taking time to reflect, like in this blog post, helps me to become more aware of what I should think about/practice when speaking. Just getting this far has made me more aware of the silliness in many of my bad habits and ways of handle fear.

Moving on

Apart from putting my trust in some great things coming from those of you who have read this (grateful once again), one thing I've realized during these reflections is I should record my conversations and try to learn from listening to myself more often. Apart from learning more about my patterns I hope it'll make me better aware of how/when/why my speedy rambling kills any substance within.

Also I need to go into "practice mode" more often, observing myself as I speak and try to tweak the why/when/how/how much I talk instead of keeping my head busy with figuring out more things to say.

... I should do this kind of reflections more often it really generates interesting thoughts!

Wrap up

Thank you for surviving this rather long blog post. Please share your experiences and ideas regarding:

• Speaking slower
• Speaking more quiet
• Getting to the point
• Stop interrupting people

I really appreciate any input I can get!

(I keep coming back to the idea that I maybe should release a recording of me rambling... well, let's save that for another time .)

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!

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.

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