21 January 2019

My Learning - Part 3 - My strategy

Before going into details about how I learn, let's look at my overall strategy and process.

Learning a new topic

  1. Build a learning foundation
    • Find the most influential experts
    • Find the most praised learning resources (e.g. books or courses)
    • Find the key concepts
    • Find the different schools of though and learn their differences
    • Meet people with the purpose to start understanding the playing field
  2. Build a topic foundation
    • Study the most praised learning resources
    • Study the one school of though (if several) that makes the most sense to me
    • Use only a few resources that focuses on core concepts
    • Make sure the few resources I learn from stick
    • Meet people with the purpose to learn from them
  3. Practice the topic foundation
    • Find ways to practice the foundation to make it stick
    • Experiment and start to ask more in depth questions
    • Meet people with the purpose to get feedback and guidance
  4. Branch out
    • Find blogs, podcasts or other sources where the new and fresh ideas are spread
    • Learn "everything there is to learn"
    • Gradually question more and more of my foundation
    • Meet people with the purpose to mutually challenge each other's ideas
Important: I don't move from one step to the other, I make additions to my approach meaning early on I only "build a learning foundation" while later on I do all of 1, 2 and 3; not just "practice the topic foundation" but I likely spend most time with the step I most recently added.

This strategy is basically the same no matter what I want to learn but different topics and different levels of ambition will alter the time I spend on individual steps, how I move between them and how much time I spend in general.

Make learning happen

How I make myself learn things:
  • Describe what I will gain from learning this
  • Clearly distinguish between focused and distracted learning
  • Make time for it (prioritization, not magic)
  • Have the resources ready (e.g. podcast episodes downloaded)
  • Surround myself with passionate learners
  • Remove unwanted distractions
  • Create a rough plan
  • Join discussion groups etc. to constantly expose myself to the topic
  • Engage friends in my learning (if possible) and/or try to find new peers
  • Constantly plan experiments or tasks so I don't get stuck with information gathering
  • Keep track of my progress and remind myself of completed milestones

Key ideas

  • Motivation is my most important tool and must be handled with great care
  • People are my second most important tool and must be handled with great respect
  • Focus my attention on the most influential experts
  • Teacher quality is more important than content quality
  • Only focus on the big lessons
  • For things to stick, I need to make them "my own"
  • When I've already learned something, reflection is more effective when I need to "relearn it"
  • A clear direction is invaluable
  • Finishing something for the sake of finishing it is a waste of time
  • Act on the things I learn (I always know enough to start)

My Learning - Part 2 - Me

Before we go into how I learn, let's look at who I am because that impacts what works for me when I'm trying to learn something.


My biggest strength and shortcoming is probably my impatience. I get bored very easily but thanks to that I don't stay with methods that aren't working or other things not helping me to progress fast.

Auditory learner... maybe

I'm a quite sociable person who loves to discuss and debate basically any topic with any person. One reason for that is probably because I take in a lot of information from listening and talking... Yes, I'm quite often surprised by things I say myself and actually learn this way.
For this to work I need... people. Due to this I spend a significant amount of time just improving, expanding and pruning my social network (which I'll come back to in later parts).

... that being said; the description of a visual learning style actually describes me better. So maybe I'm wrong... or maybe I'm a mix of the two.

Anyhow, what I do know is listening and talking is important to my learning...

Abstractions and visual thinking

My brain is pretty good at abstracting things making them easier for me to understand, summarize and apply to something else. I'm also a quite visual thinker (maybe that's true for everyone?) and adding visuals to something happens naturally. This has a few interesting implications:
  1. I'm good at writing summaries
  2. I'm good at abstracting something into a graph or simple visualization
  3. I'm good at taking a concept from one thing and applying it something else (e.g. retool heuristics created for software testing and apply them to my learning process)
  4. I'm good at making sense of really confusing things
  5. I'm good at explaining something complex by applying it to something easy that the receiver can better understand.
  6. I think this is a reason why I have quite a vivid imagination; I can create something visible and concrete in my head even from very loose thoughts.
  7. I'm good at pointing out what's missing in an explanation because when I abstract something in my head any lack of information creates a problem with my model. This also helps me come up with questions in various situations.
There are obviously drawbacks as well. Since I quickly try to create abstractions my response can end up too abstract for someone or at least too far away from where that person started. This is especially true when I talk to people who are very concrete and want to discuss the exact example they brought up.

On the end of the abstraction spectrum I kinda have to do the abstractions on my own for them to make sense, so speaking with someone who creates abstractions as well can be confusing as I have to reverse engineer that persons abstraction back to its original form to be able to start my own thinking process. This means I often "demand" actual examples from other people so that I can abstract them for myself... which can be weird... sometimes ("you must provide me real examples but I'll respond with abstractions because... reasons").

Implications when I learn:
  • I primarily look for core concepts. These concepts I can then start to apply to all sorts of imaginary things and situation to help me make sense of them.
  • Secondary I look for the actual scenarios or examples. I want them short and concise to make the abstractions more manageable and closer to the original. If I abstract a very big story I typically end up with something too generic.
  • Third I look for very skilled people's interpretations and abstractions of things simply because my experience is these are still worth trying to reverse engineer.
Implications when I socialize:
  • I have to consciously monitor what I say and the reaction it creates, to avoid becoming too vague or abstract.
  • I'm at my absolute best when the other person has a complicated thing they need help making sense of.


Let's just say discipline and "mental endurance" are not my biggest strengths... To counter this I need to monitor and nourish my motivation while avoiding distractions because my motivation is the tool I use to "fake endurance": I don't endure a long learning session, I marvel at the opportunity to learn something new and exciting.

I'll come back to this topic in great detail in a later post; but for now, just understand that my discipline is non-existent but I've learned to work around that challenge.


I have a strong competitive personality and can prepare myself for hours just to perform well in one particular situation. For instance when I play games (sports, computer or board games) I want to know everything about the game so I give myself the best possible chance to succeed... or rather minimal risk of failing, which seems to be the stronger motivation. This is a trait that can both help and hamper my learning efforts.

What I've learned is if I let this competitiveness run free I get bored quickly and start to jump from one project to the next; the reason being that I realize how far away I am from being the best and thus lose interest (remember what I said about my endurance just a couple of paragraphs ago).

So what I've deliberately done is decide to compete only with myself when it comes to the big, important areas in my life just to avoid frustration or losing interest: "I want to be the best coach I can be" or "I want to be the best father I can be". However, it takes energy to stop myself from comparing my progress to other's so to up my odds of not running out of energy I let my competitiveness wreck havoc in all the small things where it doesn't matter if I lose interest long before "I'm done".

Competing with myself

One thing I'm currently working on is to improve my ability to gain energy from competing with myself. Finding a way to monitor progress seems like a key factor here (seeing "proof" that I've outperformed myself from yesterday). Another, related journey is to better enjoy the activity itself and not just the end result. This is mostly to help me enjoy, and behave better, when participating in casual activities like board games or sports (I'm a pretty sore loser) but I think it could potentially improve my learning as well.

Limited motivation to finish things

I often start with grand plans and tons of energy. I then complete the first steps which typically teaches me the vast majority of what I want to learn... and finally I realize (or at least think I realize) that the rest of the trip is mostly repetition or would require enormous amounts of effort for quite limited learning results so I quit.

One example is the many unpublished drafts I have in this blog: I wrote the larger portion of them but got bored with the topic or the work to polish them and just left them there.

To some this might seem wasteful but to me it's not; I've learned what I wanted to learn, or realized that the learning I wanted wasn't there, at least not fast enough, so I'm done. Also when I feel the need to finish something; such as this blog post or most projects at work; I can but it requires energy and that's once again a precious resource so I need to carefully pick my battles.


Up until recently I thought I could multitask and I'm not kidding. For instance I use to watch TV while reading an article, I was listening to a recorded conference presentation while working or watching a YouTube video while writing a blog post. Turns out my ability to multitask is basically non-existent which I came to realize when doing the dishes one day...

I had been looking at some online presentations while doing the dishes every evening for about a week and every evening I was surprised by how long it took to get the dishes done. Finally I decided to monitor what was actually happening. Turns out a very small portion was me doing the dishes and a very large part was me standing still watching the presentation. The "funny" thing in all this is I couldn't recall basically anything from the presentation despite the time spent. So the next day I did the dishes as quickly as I could without any distractions and then sat in the sofa fully focused on the presentation... well, the difference was quite significant both in terms of personal satisfaction and in what I could recall from the presentation. A challenge here, for me, is I have no problem "allowing" myself to spend an hour "washing dishes" but to "allow" myself to do the dishes in 5 minutes and then sit in the sofa reading for 55 minutes is much harder...

Anyway, since this observation I've conducted more experiments and come to the conclusion that I can only do one learning action at a time and if I do anything else while trying to learn something things just won't "stick"... and I also do the other thing quite poorly. So for instance I can listen to podcasts, audio books or online presentations while e.g. doing the dishes or read while distracted by a TV but I can't have any intention to actually remember the stuff presented to me instead it's more of a passive filtering process: "Meh, this book was not great enough to actually read in a focused manner" or "Wow, I need to listen to this podcast while not distracted later". I'll talk about these learning modes in great detail in a later part but long story short: Being aware of them have had a big impact on my learning!


Related to multitasking is "stickiness". For things to stick in my head, I have three rules of thumb:
  1. Focus on only one thing
  2. Make it my own
  3. Apply it immediately
I've already talked about limiting distractions and focusing on one task at a time so let's focus on the other two.

"Make it my own" in this case means I need to use my own words and feelings to describe something, even if it somewhat distorts or modifies the original meaning/intent. Examples are:
  • Do something with it (action)
  • Say the thing out loud using my own words
  • Write down a summary/take notes using my own words
  • Deconstruct the thing and reassemble it in "my way"
  • Consciously modify my own (mental) models based on this information
  • Apply what I've just learned to a made up situation
The last three are best done on paper, not just in my head. If it's something physical, like a badminton stroke, I need to stop taking in information and do the thing myself while focusing on how my body feels while doing it.

Often when actively taking in new information (e.g. read a book) I'm content with just taking notes because if I start doing more I'll lose the flow and at that point any microscopic distraction will get me... so to help me stay focused I just take quick notes and move on. I then later go back and act on the notes I took, do the exercises from the book etc. (or at least I wish I did... more on that in a later part)

The last one is a work in progress. When I learned my way as a tester, practicing what I had learned came quite naturally. Now when my focus is to improve my ability to coach it's harder because I would prefer to coach other people even early on in my progress and to be fair, that scares the shit out of me and is not as flexible since I'm limited to when that person/those people are available. So I don't have too much to say about this yet but I know acting is important based on my previous learning adventures...

(while writing this I realize I could start with coaching myself using the various techniques I learn rather than on other people... just as an easy step one so I start doing it...)


One of the things I appreciate from having worked as a software tester for many years is the focused training and experience in asking questions. When I try making something my own, questions are typically my primary tool:
  • How does this fit my current model(s)?
  • If it doesn't, why?
  • What assumptions are required for my current model to work? Are they really true?
  • What assumptions are required for this new idea to work? Are they really true?
  • What does the author mean with...?
  • What's the author's intention by framing the idea this particular way?
  • In which context is this likely true?
  • In which context is this likely not true?
  • How can this idea be applied to other areas?
    (example: How could the concept of "critical distance" be applied to parenting?)
  • What if I knew this idea was universally true, how would that effect my actions and models?
  • ...
It's quite crowded in my head already so if I just took anything I read for granted and gave it a place to stay I'd be screwed, so questioning is an important tool not only to better understand an idea/concept but also to help filter out what's not relevant - right now - for me.

Goals and direction

I once attended a keynote about "how to become an amazing tester" from a well renowned expert in the field. She talked for 45 minutes and I saw all these people frantically take notes and afterwards there were plenty of questions from curious participants... but I was utterly disappointed! I felt like none of what she had talked about matched my experience...

What she was talking about was how to set goals and how important it was to commit to these goals. My strategy so far, and to this day, is to set a direction (call it goal if you want, but a vague one) and run in that direction... and it seems to have worked quite well for me.

After the keynote I met a few other participants and expressed my frustration, not that the keynote was bad but because everyone seemed super enthusiastic about it but I couldn't relate at all. A brilliant woman, Fiona Charles, looked at me and said:

"I look at it is a continuum. On one end is pure goal setting and for people far out on that side this was gold! On the other side I put the opportunists; I describe them as "having big ears", they're great at picking up various opportunities and are always ready to leave their current path if a new opportunity seems better. For them goals are more like prisons, impeding their creativity and energy. I would guess you're pretty far out on the opportunist side."

Since then I've altered my view a bit but Fiona's explanation is still the foundation I use.

So how have I managed to get anywhere with that attitude? Well, I need a clear direction. For instance my direction right now is to become an amazing coach and an expert in company culture. My approach to accomplish this is a mix of:
  • Find the important people
  • Find the existing networks
  • Find the often referenced resources
  • Find practice methods that work for me
I won't go into details on any of these right now but the important thing is I only have a vague idea on how to become great in this case but I'm confident I'll figure out various things to try if I just put enough effort into the four tracks above. So far I've connected with experienced coaches, I've realized a new local meetup/study group is needed so I've taken the first few steps to create one, I have a list of names of people who I want to learn more about/from, I've looked up and read several books some of which I'll read again and so on... I'm not following a clear path, I've not committed to complete any specific activities and I'm not sure what the next step is but I'm confident I have a strong forward motion (I trust my process because it has a great track record).

If you want more details on how I keep track of these various paths and opportunities you can read more in my old blog post about BOB. To be honest though; right now I'm not using BOB because I feel like my progression is too fast for BOB to keep up but he has been a trusted friend for a long time and I intend to get back to him when my progression starts to pan out a bit.

My Learning - Part 1 - Background

This blog series

In march 2019 Göran Bakken and I will organize a small "expert" conference on self-education. As part of my preparations for that conference I've spent a significant amount of time trying to understand my learning process. One thing led to another and here we are...

Why learning?

I hate not feeling proficient in the things I do. In the first job I got after graduating this happened though. I went to work not feeling as competent as my colleagues, in the areas valued by my boss. The job was as software tester at a big telecom company and the thing I was supposed to do was to learn this massive system and check if what was claimed about this system was actually true. After a few years I was actively looking for a way out cause not feeling competent was something new to me and it drained me...

One day I saw a video by James Bach. He was the most well-known tester in the world and I already knew about him but had never heard him talk about the mindset of a tester. I was mind blown! Could testing be something creative and fun where a restless, impatient brain like mine could actually be an advantage?

I often credit that video as the start to my "true career", a career where I didn't allow work to be boring because when I'm interested I learn, and when I learn I get passionate and when I'm passionate my work becomes exciting and when my work is exciting I want to learn more and when I learn more I get even more passionate and... yeah, you get where I'm going.

Learning about testing

So I started reading everything I could because I mean... that's how you learn, right? After a while I got bored; books simply didn't make me progress much anymore. But instead of turning my focus to something else, which I had done numerous times before, I decided to try a new path. I soon realized there was actually more people in the town I lived who loved testing and they had even formed a meetup group. I left my isolated learning at home and went there... and got inspired. The inspiration led to blogging because I like writing which led to interacting with even more passionate people because they liked my ideas... which led to a new job... which led me to more even more amazing people. Today I've found dozens of friends in the business, I've competed in testing, I've been teaching testing, I've discussed testing at invite only expert conferences, I've organized conferences, I've been mentoring testers and most importantly: I've loved every day of doing all this!

Figuring out my next move

But nothing lasts forever so after a while I started to get bored and jumped on an opportunity to "progress"; a new title, a new purpose, new expectations and a higher wage ceiling. This was interesting; suddenly I went from knowing where to find (almost) all the answers, knowing (almost) all the people and feeling like an expert, to being something else. The official title was test coach. "Test", even though the expectations went up, wasn't too hard but "coach" was. I felt lost; I didn't know when I was doing a good job anymore and it was suddenly much harder to find that "mesmerizing learning high" I had experienced for several years... I wasn't an expert anymore.

It took me a couple of years to find my bearings and I got that old feeling of not being competent more than a few times. It all slowly led to a bit of an existential crisis: What do I want to be when I "grow up"... I had lost a clear sense of direction.

My next move

Finally I gave myself a deadline and decided I had to figure out at least what I wanted to focus on for the foreseeable future. After plenty of thinking and research I decided to go wholeheartedly into coaching and company culture. As I'm writing this I'm still early in my progression but I've regained that critical motivation to learn, which leads to passion, which leads to more learning, which leads to... yeah, you know the drill.


The curve below shows the fluctuations of my passion/easiness to learn over the last few years.

Feel free to draw your own, it was a pretty useful exercise...

To explain the fluctuation a bit:
  • The curve starts with me starting my first job after graduating (2007).
    X is time.
    Y is my perceived passion/easiness to learn whatever I'm trying to learn.
  • Early 2012 I saw that video with James Bach that got me started. Long story short: Wow I had fun!
  • Late 2015 I was suffering from severe stress which is the reason for the steep drop. My recovery from that episode is still ongoing. The stress wasn't because of my learning ambitions per se but because I had a job where the expectations I put on my working results weren't aligned with what the employer was ready to allow me to do. Since the people actually taking the hit in this case was my students and I care about people a bit too much sometimes, I put a way too heavy workload on myself to sort of mediate the gap between their expectations and what the job allowed me to do. Not a strategy I recommend...
  • Spring 2016 I got the job as test coach and that's where the curve starts shifting upwards again. The problem at this point wasn't my progression but rather my inability to see that progression and since I didn't feel like I progressed I had a much harder time generating the energy/motivation needed to make things escalate like they did in 2012.
  • Early 2018 I finally started taking my own frustration seriously. Later, during the summer, I spent massive amounts of time trying to understand my situation. I'll show some results from that summer in a later post in this series.

Wrap up

All in all I'm a human being just like you; sometimes I'm frustrated, sometimes I'm motivated,  most often I'm a bit of both. I have friends and family who are more important than "my progression", most of what I do is not related to "learning", I'm easily distracted, I'm sometimes sad... but I still have a passion for learning and an ability to put words on what's going on inside my head. Hopefully that combination will make this series help you learn about your learning as your learn about mine.

20 December 2018

Change of name


When I picked the name "Test Adventures" I knew "Test" had to be somewhere in the title since I wasn't very well known and worried people might miss the blog if it wasn't clear what it covered.

The problem though was: What else?

I remember thinking about this for quite some time and I tried many different names. Some were cool but didn't match "me", some felt too generic and some felt too specific, such as "Test Stories" which the blog was actually named for a very short while.

Finally that magic question popped into my head:
How do I look at (my learning of) testing because that's what the blog covers?

The first word that popped up was "journey". It referred to my progression as a tester and the feeling there was still a long way to go... but it just didn't have that "umpf", that feeling of being "me"... but it was close. So I asked another question:
Why is journey good but not right?

Well, it was good because it described my never ending quest to become a better tester and it communicated my view: That this was a journey... but it wasn't just a journey... it was an exciting and daring journey... it was... an Adventure!

I changed the name in an instant and never looked back. Now many years later the name is still something I'm proud of because "adventure" truly describes the way I learn and think: I head out with a vague goal, I face hazards, I discover things and these new things lead me to new adventures.

So it's time to change the name of the blog from Test Adventures to Adventures...

Promoting "Test"

Let's start with some stats:
2012 - 20 posts
2013 - 26 posts
2014 - 15 posts
2015 - 4 posts
2016 - 9 posts
2017 - 4 posts
2018 - 1 posts (this)

What happened after 2014? Well I became a teacher and didn't have any time to write anything so 2015 doesn't really count. 2016 I was almost on track for 1 post a month despite starting slow due to spill over stress from 2015.

2017 is the year when something happened... looking at the posts from that year two cover "organizing peer conferences", one covers learning and one covers leadership/team building... none of them really covers test.

Let's make another list; here I'll try to list my career passions year by year:
2012 - Testing!
2013 - Testing!
2014 - Testing!
2015 - Testing and Teaching
2016 - Testing and Coaching
2017 - People and Coaching
2018 - Coaching! and People

A big reason why this blog has declined in regards to posting frequency is "Test" is not my adventure anymore so exciting adventures I'm ready to share just doesn't fit this blog. What "Test" is however is a loyal companion I bring on my other adventures. So congratulations to the promotion Test, you're no longer just a word in a heading, you're a trusted friend I need by my side!

What does this mean for the blog?

Well, like I said before, it was a while since I actually posted something about "test" (test techniques, test strategy, tester mindset etc.) so what you can expect is more content relevant to testing but not focused on testing. Examples are coaching, learning and culture.

2019 is the start of something new and amazing cause there's plenty of stuff piled up, ready to be written!

Adventure buddies, please say hi to Test!
Test, are you ready for our next adventure?

25 September 2017

Introducing BOB

Almost 5 years ago I created my first Skill development list. About 7 months later I made a public update of my list and wrote a blog post to explain it. Since then I've used the list sporadically but less and less. I've also seen my own education shift quite a bit away from testing and more into software development in general and coaching.

But I miss my list and also miss some of the energy I had back then when it came to learning. So it's time to revive an old friend.

A new name

I remember talking about my list on CAST 2013 saying something like: "give the list your own unique name to make it truly yours" and well, "Skill development list" just doesn't cut it anymore so meet my new friend: BOB: The Brickceptional Opportunity Bulletin board!

Image result for bob aliens vs monsters
B.O.B !

The new name is not just for the sake of having a new name and/or to include the word brickceptional. Instead it's changed because "list", to me, sounds too much like "stuff I should complete" and "skill development" is sometimes more of a potential by-product rather than the main purpose. So "opportunity" better describes what each of the items represents and bulletin board better describes the idea that this is a collection of things I could potentially look into rather than stuff I'm expecting myself to try/complete.

... and brickceptional requires no further explanation.

Updated content

Well, BOB is published and ready.

What's different

  1. The confer section is a lot bigger this time. I love conversing with people and since last time I've learned that it's actually quite easy to initiate (you ask people and they typically say yes).
  2. I have a better idea of what I specifically want to do. This might not be that visible in BOB since I try to keep many of the items open but it's an important change for me personally and makes each of the items a lot more actionable.
  3. It's more stuff this time partly because I know about more stuff that's possible to do but also because I'm not as concerned about what people might expect from me.
  4. I've removed the "continuous" part as this became way too vague (didn't provide anything). I much rather keep that stuff in a personal manifesto.
  5. I have more stuff under the read/watch category. Last time I was worried too many "easy" reading, watching or writing items would discourage me from actually seek out and meet people. Long story short: That's not an issue anymore but I think it was a good call the first time around.
  6. Finally a lot more of the items tie back to my actual job. I'm not quite sure why... yet.

What can BOB do for you?

  • Read the items from any of the three versions: 1, 2, 3.
    Anything that sounds interesting? Try it!
  • Use BOB or any other resources out there to create your own "BOB". For some additional inspiration, see "Thank you" below.
  • If you want help adding some initial items to your "BOB", just leave me a message on Twitter, LinkedIn or anywhere else and I'll do my best to help you.

Thank you

Finally: Thank you Ministry of Testing!

I've added ideas from many different sources but nothing beats your awesome content when it comes to creative, digestible ideas on things you can do to improve yourself (as a tester)!

26 April 2017

Peer conferences, part 2, checklist


If you want to know more about what a peer conference is, general tips and tricks, different formats etc., do read part 1 first.

Notice, this checklist is based around how we run SWET with a conference center, shared costs among participants, experience reports, abstracts etc. but even if you choose a vastly different format I think a lot of this still applies; there's simply stuff you can ignore.

Finally: I'm in no way an expert but I couldn't find this kind of information so I basically shared my lessons learned... and since SWETish, EASTish and SWET 8 all felt like great peer conferences this, as a minimum, should be great enough.


  • Set the group of organizers (my recommendation 3-4)
  • Schedule a startup meeting (e.g. Skype video or face-to-face)

First meeting

  • Set a date and duration (typically a Sat morning to Sun lunch)
  • Set the max and min amount of participants (my recommendation 10-13, incl. organizers)
  • List potential locations and start the process of booking one of these
  • Set the general format for the conference (see part 1)
  • Decide if you will have an opened or closed (invite only) invitation
  • Start discussing a topic/theme
  • Set organizer deadlines (e.g. deadline for invitations to be sent)
  • Set participant deadlines (e.g. when they need to confirm if they will attend)
  • Set how you will interact with participants (e.g. Slack, email, Facebook or Skype)

Prepare invitation

  • Book the place where you want to hold the conference
  • Decide who you want to invite, if invite only
  • Decide where you want to advertise your conference if open invitation
  • Practical details (see invitation below), e.g. "when should we start in the morning"
  • Send out the invitation (see below)


Email (example, personal invitation):
Hi Helena,

April 1st we will host the first iteration of PCSA at Amalias Hus (http://www.amaliashus.se), Gränna and we would love to have you as a participant! PCSA 1 is an invite only, peer conference. The topic for the conference is "Leading testers". In the attachment you'll find an explanation of what a peer conference is, a detailed description of the topic and other useful information related to the conference.

Why I want you to attend

Ever since we met 2013 you've been my main inspiration on how to lead, coach and support testers, so for this topic I think you're the perfect fit. I hope you can bring a very people centered view point to the questions and your broad experience in leading teams should be a valuable compliment/sanity check to some of the more "test lead centered" participants. I also value your ability to respectfully challenge and question people when you want more details on how they came to certain conclusions. Finally your dedication and passion for testing is something I think will inspire others during the conference, which is important to.

What happens now?
By February 19th we need to know if you'll attend

By March 31st we need to have your abstract

Best regards,
Erik, Göran and Sigge 

Attachment or open invitation:


These are the things I find important to establish with external parties such as the conference center, catering etc. Some of these will not be relevant to your setup, keep that in mind.
  • Price for both minimum and maximum number of participants (hotel, food, facility etc.)
    • Is tax included or excluded?
  • What is included and what is not, in the price above?
  • Here's the schedule we suggest, will this work for you?
  • When do we need to report food allergies/preferences?
  • What food will you serve? (menu suggestion)
  • What facilities will be available to us in the evening?
  • Will there be a bar/snacks available in the evening?
  • When may we check in and when must we check out?
  • What equipment (projector, whiteboard, sound, flipchart etc.) will be available?
  • Do you prefer if participants contact you upon questions or should I do that for them?
  • When is the last date we may change the number of participants? (e.g. cancellations)
    • What will we have to pay for after this date? (e.g. only room, only conference or both)
  • How do you best get to the location with public transport?
  • How much parking space will be available?
  • Can you manage the splitting of costs (including cost for the conference room)?
  • When will we pay (e.g. on check out) and is there a deposit fee?

Waiting for people to confirm

To keep track of invited people setup some spreadsheet/system.
Example: For SWET 8 we had a spreadsheet with the following columns:
  • Name
  • Email
  • Order; we had a list of 30+ names and had to keep track of who to invite first.
  • Who among the organizers invites this person
  • Invited (yes/no)
  • Response (yes/no/maybe, empty = no response)
  • Arrives; we had different prices for arriving late on Friday or early on Saturday.
  • Allergies
  • Abstract sent (yes/no)
  • Comment; e.g. "will answer after the weekend but will probably attend"
We later created a separate list with name, arrival day and allergies so that participants could fill this out themselves.

Handling abstracts

When all participants had sent in their abstracts we set up a new spreadsheet (we like spreadsheets) with one column for the participants' names and one column each for organizers. We then scored the abstracts from 1-5 in our respective column and summarized the result.

After that we listed the top ~8 abstracts and discussed if we wanted that order or if we wanted to change anything; for instance in the case of SWET 8 we had a couple of fairly similar abstracts so we opted to skip one of them even though it made top 4 and then switched order of a at least two other after considering experience, how much discussion we anticipated etc.

Finally we showed the participants the top 5 of our modified speaker list (ranking of abstracts).

Communication to participants

Here are all the things I can find in Slack and email, which we sent out to participants prior to the conference but after all the registration was done:
  • A detailed schedule (see part 3)
  • Food menu
  • Asked for suggestions for evening activities
  • Clarified the topic a bit and gave more examples
  • Feedback to some of the abstracts
  • Who would participate and where they were living to simplify car pooling
  • Reminder of the abstract deadline ~4 weeks and ~1 week before.
  • Kept the participants up to date with our (the organizers) work, e.g. when we planned to set the speaker list etc.
  • Sent out all the abstracts to the participants
  • Various information about payment etc. given by the conference center (see Contracts)
  • Explained the process around the lightning talks
  • Contacted the individual speakers to tell them who would facilitate their talk
  • Various clarifications and details asked for by participants


This may seem like a lot but let's be clear: What you basically have to look into is:
  • Where?
  • When?
  • Who will we invite?
  • What format should we use?
... the rest will come pretty naturally. For instance we (Göran Bakken, Sigge Birgisson and I) had no checklist when we organized SWET 8; basically the first peer conference anyone of us had organized. Most of the details (schedule, food, deadlines etc.) either came from questions/needs that popped up naturally, things that the conference center informed us about and we just forwarded or it was copied from previous iterations of SWET.

... but I wanted you to learn from stuff we for instance though of a little late (like the schedule) so that you can do an even better job than us.

Good luck!

Part 3

Part 3 will cover the actual conference including things like check in, facilitation etc. Stay tuned!

24 April 2017

Peer conferences, part 1


This blog series is mainly for people who (would like to) arrange or attend peer conferences (explained below). People not interested in peer conferences will find rather little value in this post. One exception though could be if you want to arrange some workshop/conference at your work and you want inspiration for that. Finally; you can replace testing/software testing below with e.g. "programming", "change management" or something else as the experiences and methods should work for any "topic", I just happen to work with software testing.

Finally, these are my thoughts, not "the truth".

EDIT: If you want more ideas on the topic of peer conferences, check out James Thomas' blog post "Trying to be CEWT" and James Lyndsay's blog post "http://workroomprds.github.io/LEWT".

Peer conference

A peer conference in this case refers to a small group of experts, gathered to debate a specific topic, based on their own experiences rather than e.g. abstract models and they do this in a focused manner for at least one day. "Small group" refers to something like 6-16 people. "Expert" is harder to define but means something like "a person with a lot of skill, passion and/or experience in software testing".

With this definition I realize other events I've attended might qualify but I hope it's good enough to at least understand this article.


This section is to help you understand what I base my thoughts on. Feel free to skip it if not interested. Do note that I attend a lot of other "peer conference -like" events such as Transpection Tuesday, local meetups etc. and I will take that experience into consideration but haven't listed it in this chapter for the sake of your (and my) sanity.
  • SWET 4
    15 attendees
    James Bach present, lot's of well known names overall
    I was very inexperienced (compared to the other participants)
    Language: English
    Setup: LAWST inspired
    Topic: Models in testing
    Location: Sweden, fancy conference center
    Length: 1½ days (+optional 1/3 day before), Saturday morning to Sunday lunch
  • SWET 7
    10 attendees
    James Bach present, very inexperienced group
    I was one of the most experienced attendees
    Language: English
    Setup: LAWST inspired
    Topic: Test coaching
    Location: Sweden, fancy conference center
    Length: 1½ days (+optional 1/3 day before), Saturday morning to Sunday lunch
  • PEST 6
    9 attendees
    Michael Bolton present, the best of Estonia (which is pretty awesome btw.)
    I was an "international attendee" so a bit different
    Language: English
    Setup: LAWST inspired
    Topic: Gaining consciousness
    Location: Estonia, at Nortal (company)
    Length: 1½ days, Saturday morning to Sunday lunch
  • SWETish
    10 attendees
    "regional peer conferences" with attendees mainly from Linköping and Örebro
    I was one of the most experienced attendees and co-organizer
    Language: Swedish
    Setup: LAWST inspired
    Topic: Exploratory testing
    Location: Sweden, fancy conference center
    Length: 1½ days, Saturday morning to Sunday lunch
  • EASTish
    8 attendees
    Only attendees from Linköping, mainly from two specific companies
    I was one of the most experienced attendees and co-organizer
    Language: Swedish
    Setup: People brought their own topics so no "formal presentations"
    Topic: Any
    Location: Sweden, at Sectra (company)
    Length: 1 day (optional evening), Saturday
  • SWET 8
    11 attendees
    Experienced group, rather mixed skillsets
    I was one of the more experienced attendees
    Language: Swedish
    Setup: LAWST inspired
    Topic: Testing that's not testing
    Location: Sweden, fancy conference center
    Length: 1 day (+optional 1/3 day before), Saturday morning to Sunday lunch


So far my experience is ~9 is the minimum; below that the amount of conflicting ideas and experiences, which are important, starts to become an issue. EASTish was still a great peer conference but I think that conference would had gotten even better with a couple more attendees. PEST was right at the minimum limit but I personally did not feel the amount of people negatively impacted the quality of the conversations. Of course the people matter a lot in this case; more experienced people with more diverse experiences having a lot of passion and willingness to debate will likely mean you need fewer attendees and vice versa.

My personal upper limit is ~13; beyond that it seems like every single person gets too little time; especially if there are a few very talkative individuals in the group.

I would typically aim for 13 and since people will get sick, can't attend in the first place etc. that might make us end up with 11-12 which seems great. Notice that "aim" in this case does not mean "invite". For SWET 8 we had, for instance, at most 18 invitations out simultaneously but ended up with 12 who accepted and in the end 11 attendees as one had to cancel.


I didn't think of language as much of an issue until I attended SWETish, my first peer conference in Swedish. It helps a lot even in a country where people generally speak pretty good English. To me, using the attendees' native language seems to help people "dare" to share more ideas, there seems to be way fewer misunderstandings and the overall flow is much better.

But it's a balance as using attendees native language rather than a language more broadly spoken (such as English) will limit who can attend... a problem we have in Sweden as well as several top notch testers here don't speak Swedish or at least not well enough (yet) to attend a fast paced peer conference in Swedish.


I have huge respect for people like James Bach and Michael Bolton; they always add a ton of value to a conversation about testing and especially given a format like the one typically used at peer conferences. Also seeing how James really helped a bunch of less experienced testers elevate during SWET 7 was awesome... however...

In Sweden it impacts the language, which I think is a problem (see Language). We also have a lot of talented testers so giving a spot to an expert will naturally stop someone else from attending and/or give some people less room to express themselves. Finally my experience is it steals a bit of focus as some people, knowingly or not, try too hard to impress the expert and/or not look stupid, hurting their overall performance at the conference.

I think inviting someone like James or Michael is amazing if the language is English anyway and/or the group is very experienced (hopefully lowering the "need" to impress) and/or it's hard to attract enough attendees so giving away a spot is not an issue while the expert can act as a motivation for other people to attend... but it's not necessary, you can have an amazing peer conferences without international, or even national, "experts" (e.g. at work, in your city or in you "region")... and I say this from the context: Linköping, Sweden; a city where we have a fairly active and skilled test community, just to make that clear.


Experience (as in how much "testing" and "software development" the person has experienced/seen/participated in) helps as we base the discussions on experience. But mixing in a few rather inexperienced people can really add some interesting new points of view, as long as these inexperienced people feel safe sharing their thoughts. To summarize: Having a lot of  experience helps but lack of it is not a deal breaker.

Skill (as in your actual ability to test and understand testing) is, for me, key. Some people might not be known anywhere outside their own company, they might not have much experience neither as testers or in talking about testing but place them in a situation like this and they will provide value, as long as they themselves understand that their skill level is on par with everyone else's.

So on the topic of "experts", how much experience and skill does the average attendee need to have to make the peer conference amazing? My personal experience is: "a lot less than many seem to think".

Two other interesting attributes to me are passion and (verbal) communication skills.

Passion helps a lot but I think that usually comes naturally with wanting to spend a weekend (during which peer conferences or often organized) "just talking about testing"... be careful though about attendees who just think "it'll look good on their resumés" or who want to attend to advertise their own services or hire skilled testers.

Communication skills are important in general but do not mistake this for "talkative" attendees. The K-card system often used at peer conferences, for instance, can help less talkative people gather their thoughts and help them get into otherwise intense conversation and it can stop people who think in an extroverted way ("while talking") from filling all "the space". Instead, much more important is having attendees who can express something in a concise way, who respect the facilitator/format (primarily who won't speak when they shouldn't) and who can understand when their comments won't help a conversation forward/add value as well as dare to speak up when their comments will.


My first ever peer conference, SWET 4, had an invite only format. My second had an open invitation (first 15 to sign up), my third had an open invitation (everyone may send in an abstract but a program board will select who will actually get an invitation among those) and later I also attended a "semi invite only" where ~15 people got a few days head start (personal invitation) until an open invitation was sent out. Long story short: You can do it in many different ways.

Invite only is great when you know exactly who you want to invite and want control over the group. I also find this to be most efficient as people feel selected and thus prioritze the conference more. It also helps to get those crucial first two or three attendees you need to start a buzz about the conference. There's also a risk that the group becomes too homogeneous; resulting in fewer conflicting ideas/experiences and thus fewer opportunities for people to challenge their own models.

Open invitation is great when you don't know the people you want to invite and/or who you want to come. It also relieves you from some "why did she get an invitation but not be" comments and allows you to better talk about the conference before it actually starts. However, it may make it harder to get those first attendees to sign up as they don't know if the group will be good; this can be somewhat helped by e.g. make in open invitation in a large group (e.g. a Meetup group) but where all the members should be good candidates. Also, there's a risk "the right people" will ignore the invitation because they don't understand they qualify or they, for whatever other reason, don't feel like they are the ones you're looking for.

I personally prefer invite only, even when I don't get an invite myself. I think that allows the organizers to better create a group that's suitable for the topic at hand... but that's my personal preference.

There are like I described in the beginning of this chapter many hybrids between the two but I think that should at least give you and idea. Finding the right format to send out the invitations is pretty straight forward for invite-only (email is pretty good for this) but depends completely on your context if it's an open invitation.

In the next part I'll share a checklist and example of what I think you should consider adding to an invitation, so stay tuned for part 2.

For SWET 8 we wrote a personal note in each invitation explaining why we wanted that particular person to attend. This was definitely a win-win:
  • Participants better understood our expectations
  • Participants got to feel good about themselves
  • It seemed to make more people accept the invitation
  • For us, the organizers, it felt good to tell awesome people why they were awesome and it didn't cost much time or effort.
I'll provide an example of this in part 2.


My preference so far is "as many as possible but not more than 4" (so I guess 3-4). Communication and taking decisions become a problem as soon as you're two but to me it's still worth the benefits (see below) until you're around 4 to 5. Some benefits of having more organizers are:
  1. There are simply fewer people (easier) you need to invite to get a full group
  2. The first person to accept the invitation will join an already established group
  3. You are much less fragile, if one gets sick/life happens the work can still move forward
  4. Larger personal network, key to avoid too many like-minded attendees when using invite only
  5. Greater presence in social medias etc., key when using an open invitation
  6. You have more options considering location, food etc.
  7. More people mean each person needs to do less... and I'm lazy
  8. It's easier to identify who you want to invite since you better know what's missing in the group
  9. Each organizer can relax more during the conference (less pressure on each)
  10. A lot less risk as with one sick organizer a peer conference might collapse if only having one or two organizers but it's much easier to handle if 3 or 4.
If the organizers can meet in person I think it's a benefit but having a good communication platform (e.g. Slack, Skype etc.) should be sufficient. For SWET 8 the only physical meeting we had together was the evening when we decided we wanted to organize a test conference, everything else was handled via Slack.


All peer conferences, except EASTish, I've attended have used basically the same format:
  • All attendees prepare ~20 min presentations based on something they've experienced.
  • A few attendees will actually present, usually 2-4, for a 1½ day peer conference.
  • After an experience report there's a facilitated discussion around that presentation. The discussion will continue until the group feel done with the topic (usually 1-6 hours).
  • At some point there's time for lightning talks: ~5 min talks including open season.
While I think this is a great format I think other formats could work just as well and potentially even better as they have been explored less.

Two suggestions:
  • Discussion topics and dot voting instead of presentations
  • Solving an actual problem (doing something); with one or more debriefs
At EASTish rather than presentations, attendees got to write down a few topics each (typically in the form of a question or short scenario) and then we dot voted. This basically turned it into a prolonged lean coffee. There were some cool benefits to this format:
  • People got help/got to discuss the exact topics/questions they were interested in
  • Much less time to prepare for attendees
  • People who feel uncomfortable to present didn't have that distraction 
Drawbacks could potentially be more abstract content rather than focus on experience (not my experience from EASTish), if attendees think the format means they don't have to prepare that may negatively impact the topics covered and the presentations (or rather preparation work needed) may act as a useful gate keeper; scaring off people who want to attend for the "wrong reasons". I don't know if any of these drawbacks are actually valid but no matter what; this is a format I would love to try at a peer conference fairly soon; with or without a specific topic/theme, but probably with.

The other suggestion is something I have tried at a local meetup where we split into smaller (mixed) groups, tested a specific application and finally spent a long time debriefing our testing including why we did the testing we did, how we organized ourselves, differences between individuals in the team etc. The idea has also been used at at least one peer conference before: PEST 4.5, where they tried to visualize various reports in testing in new and creative ways. I highly recommend reading about PEST 4.5 and ever since I heard about it I've wanted to attend/arrange something similar.

If you have ideas on other formats that could be useful, please comment and I'll add them to the post. This is one of the areas where I think we could really take the concept of peer conferences to a whole new level!


Peer conferences typically have a topic/theme. This topic/theme is important to keep discussions focused, to get the right people interested in the conference and to help people prepare before the conference.

Generally topics should be broad enough to include some diversity but narrow enough so that we can actually get deep into the topic. You have several examples in the Data chapter and if you search for "peer conference software testing" you'll find more. One issue though is that the one liner rarely tells the full story as there are usually specific aspects you're interested in (the one-liner is too broad). To get a better idea what I mean, do check out the invitation for PEST 6, it explains their topic "Gaining consciousness" in a great way.


This is relevant if you let people present, skip if you want a different format.

First of all, set a clear deadline for when you want attendees to inform you what they want to talk about. Informing you about what they want to talk about is typically done in the form of an abstract (~1 page description of the talk).

When you know what they want to talk about establish a speaker order and if possible, set who will facilitate each talk. You can read more about facilitation in the story behind K-cards. I'll try to share how I do this in some later part but if I forget, feel free to ask me.
If your peer conference looks anything like the ones I've attended you'll likely fit 2-4 presentations into a 1½ day conference, so my advice is to inform the top 5 participants (1 extra to deal with a potential cancellation) and let the rest focus on lightning talks.

I also recommend having appointed mentors (typically organizers, e.g. the facilitator) available for each speaker. This can help both experienced and inexperienced speakers present the "right thing" (an actual experience rather than some abstract concept).


Every time I've attend 1½ day peer conferences, I feel like half the group says "This sucks, I would like to continue" and the other half says: "I loved this, but now I need some sleep/think for myself" at the end. I don't know if that means the length is perfect or too short (or even too long) but I think it's a sign the length is quite good.

However, to avoid stagnation (few new ideas/low energy) when going beyond a day my experience is you need a larger group than ~10 and/or very passionate/skilled/experienced attendees. I for instance felt a bit of stagnation during SWET 7 but not during SWET 4 and SWET 8.

I would love to try a full 2 day version but when trying to find a good schedule I run into problems. If you want to avoid missing too much time from work (problem typically for consultants) you could either start by lunch on Friday and end by lunch on Sunday, this would cost one extra night (compared to the typical Saturday morning to Sunday lunch setup) and interfere with working hours especially for people with a long ride to the conference... or you could start Saturday morning but end Sunday evening instead, so you basically end after dinner (say everyone leave ~21:00). This would not cost an extra night but add quite a bit of conference time. Would suck though for people having e.g. a 3h+ drive home (common in Sweden)... Maybe end at say 17:00 or 18:00 and skip the extra dinner as part of the conference... I need to think about this a bit more.

The other option: Shorter, means you can cut costs (e.g. no nights) and make it simpler for people to "spare the time". We did this in Linköping (city with ~140k population) and it work out nice. I don't think shorter is an option when attendees have more than say 30mins to the conference but worked great if you want to introduce the concept of peer conferences to a more local group.

Facility and food

Facility and food are actually quite important since attendees will like sit for long durations and be exposed to a lot of information. When selecting a place to host the peer conference, take into consideration: costs, food, quality of the conference area, how much you have to fix yourself and facilities to use in the evenings.

For the evenings it seems like you want one of two things: An inspiring area to sit in (beautiful, unusual/creative, enough space etc.) or a relaxing pool area; e.g. a large outdoor jacuzzi... some alcohol (like a beer or two) also helps.

Being in an area that's great for taking a relaxed walk or jog also helps in my experience as people need some air after more or less a full day in a conference room. For this, choosing a location that's somewhat remote seems to help; this also has the benefit of helping people to fully commit to the conference as there are fewer distractions.

A conference center will greatly up the costs but also significantly lower the amount of work for the organizers. I've attended peer conferences hosted both at conference centers and at someones company, both work equally good to me as long as the organizers, in the latter case, have a good plan for e.g. food, evening location, some energy refillers (=candy/sweets) for the breaks etc.


  1. Make sure there's a schedule
  2. Make sure the conference center, food catering etc. agree to your schedule
  3. Be flexible; not interrupting a good discussion is more important than sticking to the plan
  4. Schedule regular breaks but remember to not interrupt good discussions (see previous)


During the evening(s) a lot of important processing, bonding and follow up discussions take place. Make sure there are good facilities for these, that attendees stay (except for the need of sleep or handle social overload) and that there are some "conversation/activity help".

"A good place" and "making attendees stay" were described in the "Facility and food" chapter above so let's focus on "conversation/activity help". A lesson learned (for me) during SWET 8 was I think the group benefits from being split up a bit in the evening. One simple example is having one or more tables devoted to e.g. the dice game, coin game, Test Sphere or Set as this will split up the group. If there's a pool area the size of the jacuzzi and the fact not everyone like spending time in a pool will automatically split up the group (not necessarily in an optimal way though, but hopefully good enough).

Other examples could be to actually schedule activities in the evening. One way would be to split into smaller groups doing some task, challenge or activity and then, in a simple and informal way, let the groups debrief their results to the rest of the attendees (either in the evening or the next morning). Another would be to set specific topics/tasks at different tables so people can rotate and discuss/do different things with different attendees. Be careful about ambitious plans though; it seems like as long as you provide a somewhat quiet area where people can easily split up into smaller groups themselves; you're basically set... but some help rarely hurts.


I think we can take the concept of peer conferences even further if we dare to challenge the current common setup by e.g. trying new formats, longer/shorter conferences, tinkering with the group we invite, try new locations etc. For instance my view of the "minimum viable product" for a peer conference (location, setup etc.) was significantly altered after I had attended PEST 6 which was the first peer conference I attended that wasn't hosted in a fancy conference center. PEST 6 then became important inspiration for how we arranged EASTish here in Linköping.

What's next

Part 2 will be a checklist for organizing a peer conference including an example of an invitation etc. The goal with this post was to help people learn new ways of organizing a peer conference, part 2 will hopefully inspire new people to organize them as they learn it's not that complicated.

Part 3 will deal with stuff related to the actual execution of the conference e.g. facilitation, check ins/check outs etc.

26 January 2017

How do you help a team become awesome?


I raised a question, first during a Transpection Tuesday, then in the TestSverige Slack chat and finally with all sorts of people I've met; mostly software testers. The question was:

How do you help a team become awesome?

Awesome in this case refers to the kind of team where everyone seems comfortable; they laugh, they communicate, they do silly things but don't seem embarrassed and at the same time they seem productive, motivated and ever evolving with low employee turnover rate.

This is my summary of those discussions.

Before we start: This is not specifically for managers, team leads, scrum masters etc.; it's everyone's responsibility and opportunity; anyone can improve a team's "mood".

Personal attributes/attitudes

Personal attributes and attitudes came up a lot during the discussions and they seemed to be the foundation on which you can add helpful activities. All of these work as self reinforcing systems so if you start to set a positive direction others will (eventually) follow. The same applies if you set a negative direction though, as this will start to create a deeper and deeper hole to get out of.

So why don't we just act "good"? Because we're imperfect, also known as being human: We're scared, we sense injustice, we want revenge, we get stressed, angry or sad, we're sometime egocentric and so forth.

For these reasons there are a few things you need to consider for each of the attributes listed below:
  1. It'll take courage to set a new direction and you might get hurt... sometimes a lot
  2. You'll need to consciously monitor yourself to avoid stress etc. getting the better of you
  3. You'll need to nurture these attributes in the team primarily by making positive examples visible

So, without further ado; dare to...
  • Be vulnerable
    "My uncle used to say that we like people for their qualities but we love them for their defects."
    /John Myers, Hellboy

    Share your struggles, admit you're scared, open up, allow people to come close and dare to be imperfect (aka. human) in general.
  • Be transparent
    Share what you know and do, that's relevant to others even though this might make them question your decisions, force you to (temporarily) stop something or even use the information to personally attack you.
  • Be accountable
    When you've messed up, take responsibility, apologize if appropriate and accept the consequences. Sometimes it's even beneficial to take responsibility for things you weren't responsible for just to get out of a negative loop.
  • Appreciate
    Make it a habit to register when someone makes something good and tell them this. Make sure you're sincere, empty flatter is not helping. Another nice way to appreciate people is to be a proxy for appreciation e.g. "Just so you know, Bob gave a two minute speech this morning about how great he thought your design was".
  • Trust people
    People want to do good so do trust them. Sometimes they'll let you down, sometimes you might even get stabbed in the back but keep trusting them. With that being said, of course bad behavior should be dealt with, e.g. see "be sincere" below, but as soon as you stop trusting people you're heading in a bad direction. After all, if you don't trust people they'll never be able to show you they can be trusted starting a rather destructive loop. Also people grow with responsibility. Finally: trusting people does not mean not helping them and/or helping them realize they need help.
  • Be sincere
    Integrity is sexy; if you think someone, including yourself, is being singled out, is getting unfair criticism or for other reasons aren't treated in a fair way: Speak up! Especially when people aren't given a chance to defend themselves.

    However, stick to your observations not your interpretations. You don't know for sure if "this person is actively trying to hurt you" but you do know for instance that "the person was told to give you the latest version but you never got it". Sincere != Judgmental, quite the opposite actually.
  • Care about people
    Caring about people costs very little and the main risk you face is simply to be creepy. Do notice that care does not mean micromanage, instead it's about genuinely trying to create a good situation for others. Carita Jansson Tsiantes gave a lovely example in the TestSverige Slack chat that went something like:

    When you boil water to make a cup of tea, don't just think about yourself; prepare water for your colleagues who might want tea as well.
  • Help and support
    This can shortly be summarized as:
    "If someone has a problem, we have a problem".

    When asked for help do help and if people express frustration or confusion offer to help. Few people ask questions if they don't need to so rather than telling them "you should know that" try to help them learn how they can find the answer themselves; e.g. by introducing them to the right people, help them get access to some information system, help them get invited to a certain meeting/mailing list etc. An attitude to avoid is "it's not my job to help...". Sure this is sometimes true and you need to work too but then again: help the person help herself rather than ignore the request.
  • Respect everyone
    No job, role or person is more important than any other. Of course some tasks might be more important to finish but then focus on getting them solved as a team. A key aspect in this is understanding your colleagues' tasks, challenges, frustrations and talents. Andreas Cederholm brought up a great example of how to nurture this attitude:

    We run team test sessions where the whole team test together. Add some cookies and laughs and it'll work even better.
  • Try
    If you want to challenge status quo you'll have to try new things. Trying comes with an increased risk of failing and potentially making a fool of yourself but that's necessary and typically a great way to learn. Sometimes trying something you don't really believe in might still be beneficial simply to acknowledge that ideas are appreciated and that you trust in peoples judgement even when you might not agree with them.
  • Auto forgive
    A psychiatrist once told me a very smart thing about eating disorders and how to react when people have not been able to fight the decease (generally applicable of course):

    Guess who'll feel worst when this has happens? You? No, the person who just "failed"! You don't need to remind them they "let you down", they'll know and they'll feel terrible about it.

    People mess up, people take bad decisions, people have bad days. You rarely need to remind them, it's typically much more constructive to say "don't worry, shit happens, let's fix this" and move on. This is also important to nurture previously mentioned attitudes such as "try" and "be transparent"; if people are scared about potential consequences (including reactions) the only thing they'll try is to cover stuff up.
  • Smile (and laugh)
    Being met with a calm, warm smile is great medicine when you feel down or nervous about some bad news you have to deliver. Smiling also helps at least me stay calm making it a useful tool to manage feelings of anger or frustration.
I get the feeling all the attributes/attitudes above point back to some basic principle like "get unhelpful frustration off the table fast; both yours and others" or "always trust in peoples willingness to do good"... but I can't really put it into words. Feel free to help me.


If the personal attributes/attitudes are the foundation the various activities below represent important tools to speed up the process. Notice though that the activities by themselves are not silver bullets and overusing them or using them at the wrong time can actually have a negative impact. Focus on the list above first!
  • Social activities outside of work
    E.g. cook together, sports or boardgames. Activities where everyone is active which is not necessarily true for e.g. your typical after work.
  • Quirky things
    E.g. quote book, silly competitions, fun/silly "rules" or internal titles.
  • Retrospectives taken seriously
    Not specifically the meeting, can be e.g. a continuous, everyday team reflection activity. All problems brought up are dealt with. Problems are taken seriously even by members not personally impacted.
  • One on ones
    Allows people to raise concerns in a safe environment (assuming the person meeting members one on one has earned the members' respect).
  • Do each others work
    An example of this is Team Test Sessions where the team test together (suggested by Andreas Cederholm, TestSverige) or move the other direction and try mob programming with testers included. Everyone (product owner, developers, testers, designers...) together attending e.g. courses in security or usability could also help support as this kind of activities creates some common ground. Yet another suggestion is team members meeting customers, accompanying sales/support people etc.
  • Discussions about values
    E.g. take the "personal attributes/attitudes" list above and talk about each one described. Is this something you want to strive for in the team; can you change something to help nurture this behavior etc. Make it a team goal to improve and nurture the "mood" in the team in general.
  • Personal values
    Most of the personal attributes and attitudes require consistency. An activity where you sit down an state you personal "manifest", goals or values can be important. For instance it might be hard to treat yourself in a fair way without some guidelines; either turning you into an asshole demanding more from other than yourself or a "victim" never treating yourself well enough.
  • Clarify your attentions to your boss
    If you want to invest quite a bit of time in this, go to your boss, explain your intention and ask for her/his support. Making your boss, or if necessary, your boss' boss, an ally can provide access to several powerful tools (e.g. see "Supporting context" further down).


The list below represent "symptoms" that your team (or even company) is moving in the right direction:
  • People laugh.
  • You're met with a smile, even in bad times.
  • You know what your colleagues like, both at work and outside. E.g. their hobbies,interests, spare time activities, important life milestones, work and private goals, "hidden talents" and previous experience.
  • People talk about hobbies, spare time activities and the other things listed above.
  • Conflicts are taken seriously and navigated swiftly.
  • People blame themselves, if anyone, not others.
  • High level of motivation.
  • You rarely feel stupid (in a bad way).
  • Stuff that "should be done", gets done.
  • Ideas are taken seriously, people try new things and experiments are run frequently.
  • People admit mistakes and challenges early as they're not afraid of the consequences.
  • People meet outside work because they want to, not because they feel obligated to.
  • Few taboos.
  • Very limited "bullshit" or backtalk in the team.
  • You know what's happening in the team and rarely get "unpleasant surprises".

Supporting context

These things might be hard for you to actively influence but be aware as they do seem to have an important impact:
  • Reasonable pace
    People need time to do supporting, long term activities and when under immense pressure/unreasonably high pace this is quickly forgotten or down prioritized. These lost activities help you become faster tomorrow than today meaning they're long term, multiplicative investments.
  • Stable organization
    Adding or losing team members can in worse case force the team to start over in their attempts to be awesome. If you're the manager; try not to change teams that work great together even though it might be tempting!
  • Ethics
    A product you believe in and feel ethically good working with, helps. The same goes for the company's actions: If it feels like the company acts in an ethical way that seems to help people "invest" in the company in a way that's helpful.
  • Good social (especially empathic) skills
    Having team members who like the social aspect and are good at nurturing positive social behavior (not to be mixed up with people "talking a lot") helps.
  • Previous friends
    Not always true as the previous friends may create a "sub team" within the team but seems to sometimes help as the friends most likely have a healthy relationship towards each others which can spread.
  • Management accepting problems
    Having a manager/management asking for "solutions, not problems" can suppress people's willingness to bring attention to important problems or make the company accept suboptimal solutions. The intention to focus on what's constructive is not bad but the message delivered can be. It's of course okey to ask the person if they have any ideas themselves on how to solve the problems they bring up but don't make the solutions a "requirement".
  • Culture awareness
    Manager/management that genuinely cares about the company culture and how to improve it helps.


Some "quotes", all loosely translated from Swedish:
  • "I ask myself: How can I make this person feel like I want her to feel?"
    Carita Jansson Tsiantes
  • "It's professional to be personal"
    David Högberg
  • "It's not unprofessional to have fun but to do something in a boring way when it can be achieved just as well in a fun way, that's unprofessional"
    Klas Hallberg, from his book: YCDBRALAI (Swedish).
Finally a comment I didn't know where to place:
  • "If I say I can't talk about it, you know and accept this". Transparency is important but some information you mustn't share for various reasons. However, sometimes the mere knowledge you know some secret information can be enough to help people prepare for a big change, avoid unpleasant surprises etc. One example could be: "We will get a new boss, I know who it's most likely gonna be but I can't tell you until papers are signed; however, I can tell you I think this person will do a terrific job, so don't worry too much about it".


It makes perfect sense but didn't really occur to me when I first asked the question:

Making a team awesome is basically the same thing as making any relationship awesome and it starts with you and all the small decisions you make every day.

Good luck!

29 November 2016

Learning about learning by teaching

I've undergone a tough education in software testing:
  • 15 months long
  • Tests 3 times a week, 7 hours each and in front of a crowd
  • If you skip a test you'll have to do it again, typically within 5 days.
  • The expected level of competence is: "Good enough to teach others"
  • Little or no chance of "redo:s", you better do it right the first time, every time
In other words: I've been teaching a class in software testing.
The intense experience of teaching testing like this has of course taught me tons of things and with this post I want to share the positive effects this particular job had on my own learning. Each benefit (of teaching) comes with a "why I find it useful" and "how you can apply this knowledge in a more everyday context".

Benefit: Curriculum


I'm not a fan of committing to a plan, especially not when it comes to my learning. However, the education's curriculum did force me to look into many topics/material I would otherwise had skipped due to laziness, lack of interest or lack of understanding (not thinking it was useful to me). Some of these have definitely made me a more complete/skilled tester such as test framing, deeper understanding of test techniques and a better understanding of bias.


Benefit: Go deep


I've read tons of articles, watched hundreds of hours of presentations/videos and spent a lot of time practically practicing testing. However, I often end up looking at topics in a quite shallow way especially when I find the topic a bit boring (may still be very useful). When you are to talk about a specific topic for just a couple of hours, you're okey, there's little "need" to go deep. When you have to prepare several weeks of study material though, that's a whole different beast! Being forced to go deep into topics has enables me to better question, improve, explain and argue for the various choices I make (for example why I chose to place my testing mission at the top in a certain status report).


  • Dig deep into fundamental questions e.g. what is testing, why do we test, what is an oracle etc.
  • Look into related topics. Say you want to improve your written reporting skills then look into e.g. rhetoric, design, how people read printed and digital documents, how people interpret colors or tutorials for your word processor/mind mapping tool/whatever. The point is: don't limit yourself to articles specifically about test reporting.
  • Set a "topic of the month" and try to become as skilled as you can in this topic. Don't stop because you feel "done", continue beyond that.

Benefit: Giving feedback


An important part of my job is helping students understand what they do well and what they might need to improve. To do this I have to observe and analyze what they've done, what they think they've accomplished, what actually made them accomplish what they've accomplished etc., all this I have to do rather thorough in order to be able to explain it to them. This helps me create an understanding that is beyond "do this or do that because it works better".
An example of this is when grading various assignments and projects as students, at least on a general level, need to understand what they did good and what they would had to do to get a better grade. If they get the highest grade they need to know why, so they both know what to continue doing and what to improve. As testers we need these kinds of observation and communication skills all the time when working with developers, project managers etc.


  • Study your own testing and try to explain why it was good and how it could be improved.
  • One area where I've found this pretty easy to practice (can't prove that the practice translates to other parts of testing but I think it does) is watching presentations (e.g. YouTube) and try to give feedback to the presenter. What specifically did she/he do good and bad?
  • Study other testers and try to figure out why you find them good/bad testers. Be as specific as you can.
  • When testing, try to find positive and negative patterns: "The log entries are (almost) always relevant and well described making my work so much easier" or "The UI components often have poor vertical alignment".

Benefit: Teaching


Teaching in itself is a great technique for learning. You have to rephrase the content to match your own language, you hear yourself speak about the topic and you get questions pinpointing gaps in your understanding and/or explanation.


  • Do teach colleagues and friends about the various topics you've practiced.
  • Write an educational article/blog post about what you've learned (you don't need to publish it to anyone to still get many of the benefits).
  • Talk at a local test meetup and if there isn't one, arrange one.

Benefit: Peer


Working with Maria Kedemo and Martin Nilsson have allowed me to get feedback on the ideas I'm about to share, feedback on my interpretation of various topics and someone to speak with when I feel stuck. It has also allowed me to learn from their knowledge and experience of testing.


  • Speak with a colleague
  • Join a local tester meetup
  • Go to a test conference
  • Join the active community on Twitter
  • Try your own version of Transpection Tuesday (my post, Helena's post: 1, 2)
  • More ideas...

Benefit: Observe testing


I've spent a significant amount of time both observing testers test (as a group), observed testers test (the actual testing done by an individual) and listened to testers speak about their testing. All three exposed me to new ideas and made me question my own approach. It's also interesting because you get to see a specific problem solved in many different ways which helps you understand what actually impacts the result; e.g. "what is the common denominator in these solutions, is there anything I can learn from that?" or "they all had different ways to setup but all ended up with the same solution, which setup worked best/most efficient and can I learn something from that?".


  • Pair testing
  • Look at other testers' notes, reports etc.
  • Do call for and attend debriefs no matter if you use the concept of test sessions or not
  • Offer to review things
  • Volunteer to mentor/coach another tester; this will enable you to observe another tester as well as get several of the other benefits mentioned in this post

Benefit: Consistency


To sit down and learn about various topics every day for over a year has definitely added some welcomed consistency to my self-education.


Benefit: Questioning basic assumptions


Explaining fundamental concepts is incredibly hard but rewarding! As an experienced tester I take quite a few things for granted and explaining concepts built on these assumptions to someone without experience lead to wonderful questions like "but why do we need testing at all", "what does it actually mean to test something", "why can testers find bugs if developers who know the code can't (as in why do bugs happen at all)?". Answering these questions without being able to rely on "experience based assumptions" has led to more than a few epiphanies (and a lot of frustration of course).


  • Talk testing with people having a different frame of reference (developers, management etc.)
  • Talk testing with people who don't work in the industry; for instance try to explain what you do to a relative.
  • Teach new testers at the company or teach e.g. developers in testing
  • Talk testing with new, inexperienced testers

Benefit: Ask yourself "how do you train this skill"


Reading and listening is nice but sometimes you need to actually practice skills to be able to learn them. When teaching I've spent a fair amount of time trying to figure out exercises pinpointing a specific skill I want the students to practice or just exercises/projects in general helping students practice relevant testing skills. This experience help me now both when less experienced testers want help learning a skill, when I try to explain/teach something and when I try to teach myself something.


  • After e.g. a blog post, YouTube video or book; think about how you can incorporate the new concepts you've just learned about into your own work.
  • Try various exercises and try to replicate various experiments yourself; such as: 1, 2, 3, 4; to help kickstart your brain.
  • Whenever you're asked to explain something; try to come up with an exercise or experiment that helps demonstrating whatever you are to explain.

Benefit: Getting questions


I've already touched upon this but getting questions from the students on anything that's not clear to them is incredibly challenging but rewarding. It has helped me realize flaws in my own understanding, forced me to question my own assumptions and challenged me to find new ways to explain certain concepts in.


  • Explain concepts to others
  • Ask for feedback
  • Ask questions yourself; this both inspires others and help you ask questions "to yourself"
  • When reading/watching e.g. a book, presentation (video) or article; pause periodically and ask yourself: "what did I just read/watch and what of that is unclear/seems strange to me?"

Benefit: Having the time and expectation to learn


When in the middle of deadlines, huge backlogs and conflicting priorities it's easy to forget learning. Having the explicit expectation to learn new things has been an interesting experience and I feel confident saying I leave the teacher assignment as a much more competent tester. Spending as much time as I did on learning is not possible in most working contexts but I think "expectation to learn" is the key concept here as it helps making it happen at all.


  • Ask your boss: "How much time am I expected (or at least allowed) to spend on education?"
  • When doing backlog grooming (if you do this); add learning stories as dependencies e.g. "before we implement the new video player we need to learn a bit about streaming, video formats and performance testing related to streaming". If you end up never having time for these learning dependencies, try timeboxing them to make the expected time invested in learning more explicit.
  • Remember learning is a fundamental part of testing.
  • Differentiate between the learning that's necessary to solve your current task and learning with more long term, strategic value (e.g. learning more about testing in general, about web security, about test planning etc.). The "strategic learning" is often important to keep you and the company progressing but can easily be forgotten if put in the same "budget" as the task solving learning.

Final word

I removed several additional benefits I had initially included just to finally get this blog post published (it's been stuck in "draft" for over a year) so just to be clear: You can learn so much more about learning by teaching; this is just a mere introduction.