Takeaways from a Pitching Masterclass

Pitching is 95% practice and 5% inspiration. -Annette Kramer

A couple of weeks ago I attended a pitching masterclass by Annette Kramer. It’s part of this strange habit I’ve developed that I watch masterclasses on Youtube to pick up ideas for my own coaching sessions. Now I decided to watch a live one. But more on that in some other blog post…

I learned things about conducting a live masterclass including interaction with the audience. In addition, I also picked up a few ideas that I believe would be useful for testers. Communication skills are among the core skills of testers and I’d say pitching is a subset that could be useful to have in your toolkit.


This masterclass focused on the 3-5 minute pitch format which, according to Annette, is the hardest pitch to do. This is because talking for longer is easier – you have time to expand on your points (though you may water down the content this way…). The masterclass was mostly targeted at different business representatives who need to do pitching to investors or potential business partners. We had a good mix of people: from a startup pitch to looking for partners for school software to a showroom rep. Therefore, it was great to see exampels of pitches for different audiences.

Annette live-coached the pitch makers starting from how they walked to take their spot, to how they stood, how they expressed themselves, and she also re-engineered the flow of their pitch on the fly while also including the audience in giving feedback. It was inspiring to look at how she worked with people.

Selective Hearing: Lessons in Communication

Annette says that when an investor listens to a pitch, they hear “blah blah blah will I make any money on this blah blah blah when will I earn money back blah blah”. When a potential business partner listens to a pitch, they hear “blah blah blah will this make me look good blah blah will I make/lose money with this blah blah”.

How does your audience listen and what is important to them?

Do you focus more on what you want to say or what they want to hear?

During the past year I’ve dealt with C-level and other directors and managers more than I previously have, so this one hits home and is a good reminder. I know I frequently fall into the trap of thinking more about what I want to say and what I hope the effect to be, rather than doing more listening to be able to target the message better. And understand the people I work with better.

From observing a number of testers over the past year, I think there is an important takeaway/reminder here: when talking to your manager (or some other stakeholder/decision maker) about testing, don’t focus so much on your specific testing problem but on the impact of the problem. When focusing on the impact of the problem, you can think of what that manager/stakeholder sees and what they’d like to hear. I bet it won’t be some testing-specific talk about the issue you want to address or the idea you want to introduce. I bet it would help you if they heard “blah blah solving this will make us look good blah blah blah solving this will mitigate the risk of not fulfilling financial goals that  a director somewhere set me blah blah blah”.

That being said, I really liked and I agree with Annette’s proposition that you can’t sell or push ideas on people – it’s much more liberating to think of pitching as a way to offer people an opportunity. So this is why you need to know what your audience cares about and is interested in.

I don’t do pitching on the stage to my managers but I treat some hallway conversations or situations at meetings as micro-pitching opportunities. I have a lot of ideas and I keep looking for ways to get buy-in or traction to take the ideas further. I don’t always know which ones get better traction which means I need to pitch them several times to different people. Which takes me to the next takeaway…

Process. Process Everywhere.

Annette emphasized that it’s useful to think of pitching as a step in the process, and to keep the process in mind (not the result). The goal of the pitch isn’t to close the deal because hey, that hardly happens so easily (or right after a pitch).

The goal of the pitch is to get people asking questions, to keep the conversation going. When I later talked to Annette about it, she said that we do this outside work all the time. And I said, “Oh, this is why we have friends… because we keep the conversation going and this is a process”.

When trying to approach a decision maker with an idea (which probably will take up time (=money) and money, so there are considerations in their mind you may not know about), don’t think of it as a “make or break” situation at the first try. I find myself sometimes doing this exact thing and then getting frustrated. Well, that’s not helpful, is it? And it’s not helpful because if I focus too much on the result, I forget about the process of getting the result. Introducing new ideas in organizations can be difficult, so focusing on the process, focusing on starting and keeping the conversation going is helpful.

Mean It. Clearly.

It was fascinating to watch Annette pick up the difference between when the speaker really meant and believed in what they said and when they didn’t because they focused on what to say (or remembering what to say…). I observed a significant difference in this person’s body language and facial expressions in the pitch after Annette had made some adjustments and asked them some questions to help them discover what they actually meant.

And I mean if I could pick it up, so can you. And other people will pick it up about you. Here’s another takeaway: don’t be abstract, be specific. It will be hard for you to say it like you mean it if the concepts you use are too abstract (and it will be hard to grasp).

Annette did a great job helping people to be specific and get the real meaning out from behind the words. I think this is also a process: you start with an idea, and through practicing a pitch for it, you peel away layers and arrive at the core that will be specific and clear.

We also addressed the issue of using jargon and how this makes attempts at being specific revert to being abstract (“What do you mean by [this thing]?”). I’ve also observed in testers that they tend to use testing jargon when talking to stakeholders who don’t know anything about testing (or don’t care about it…). It’s a similar point to that above: think about the audience you have and what they can understand and want to hear (probably not jargon). Focus on the problem that they feel related to. Annette pointed out why TED talks are so great: among other things, the speakers avoid jargon (so that everyone can understand what they’re talking about).

And don’t talk on autopilot!

Autopilot leads to not really putting yourself in the words you’re saying and you end up “just talking” not delivering a message.

Annette had a great tip for this: remember why you care about what you do/say BEFORE you say it.


I’ll blog a bit more on the pitch structure and other takeaways in another post.

5 Years in Testing

My life changed 5 years ago today when I started as team lead for the testing and documentation team.

I knew nothing about testing. I had a vague idea about it at best.

I knew nothing about team leading or building a team.

I knew very little about software development in general except for what I observed while working as a technical writer.

My background in the humanities didn’t make it look like I would last for long.

Fast forward 5 years and I’m still here. Who knew? And, more importantly, why am I still here?


Well, I guess my to-be boss knew something about me that I didn’t when he asked me if I’d like to take the chance. It seems to be a recurring theme in the past 5 years: people around me point (or push) me to try and do things I didn’t know I could do. Sometimes I kick and scream but when I go for trying something (a peer conference, a test challenge) it usually ends up being rewarding. So I don’t know what’s the real lesson here: should I just think I have a lot of blindspots about myself (in which case it’s great to have smarter people around me)?

I know that the people in the testing community have made a great difference for me by talking to me (even when I was scared to say something for the fear of saying something stupid – I probably have said stupid things along the way), sharing, helping, mentoring in one way or another… I never knew how powerful the connection between like-minded people could be and how it can propel me forward. Now I believe in and advocate for simply bringing people together and supporting their interactions as a way to make things happen. Sometimes you may not know what’s really going to happen but that’s OK. I want surprises.

I’ve learned many things about myself. The environments I’ve been in have brought out the good and the bad in me. I’ve discovered integrity and grit in me that make me push myself to find yet another solution after having tried and failed several times. It has helped me through situations where it would be easier to just do what you’re told but which would make me feel like I would break and be lost forever if I did that. I’ve learned that I’m not good at just following orders: I prefer to think for myself and understand the situation fully, and make my own decisions because I can understand them and can be responsible for my work.

I’ve also discovered that I have a long way to go when handling manipulative people or dealing with certain conflicts in a productive way. I’m very grateful to my manager that was patient when I was sarcastic and ironic, and whom I could observe and learn from as he dealt with similar situations. I’ve learned from other managers who’ve shared their approach and who inspire me with how cool they are with conflict. It’s not about the fight. It’s an opportunity to get somewhere.

I’ve learned to think critically in a different way as compared to what I was taught at the university. It was almost uncanny when I realized how much learning to think like a tester intervened with my “academic” mode of thinking. I somewhat got into trouble with that over my MA thesis… On the other hand, I’ve found useful takeaways from my education to use in the testing field related to doing research and analyzing problems. What I’ve added now is systems thinking and wow, does world make more sense or what… Learning to think like a tester has taught me to think. Period.

I’ve learned that testing is wonderful because of the endless brain-tickling opportunities. I remember that even when I was younger I loved the feeling in my head when the pieces of information clicked together and the world transformed – I’d brought an unknown unknown into my world which made it a known thing for me. And it made the world more exciting. Testing provides such moments all the time for me. There is always something to figure out. There is always the chance you’re wrong, so uncertainty and doubt will be your trusty companions. Since I question myself quite a lot, it kind of fits me… This will keep me thinking, learning, re-evaluating, and searching.

There are many wonderful things humans can do using their skills and tools. Maybe I’m not so good at using a plethora of testing tools but I’ve discovered I’m somewhat good “at people”. I tend to care about them… And I like the feeling of having made a difference. Therefore, human-centric testing gives me plenty of space for helping to solve problems, change something, and learn in the process. It’s a space where the excitement of discovery and learning will be serving a great purpose. Had anyone told me this 10 years ago when I finished high school… It wouldn’t have made sense to me. I mean what can one possibly know about what they could do or are capable of or should do with their life when they finish high school?

I’ve learned that (self-)reflection is a really powerful tool. If you want to double, triple, or quadruple this power, you should reflect with someone together. I’ve always been a person to do this (as long as I can remember myself) but it’s only during the past five years when I’ve seen the benefits of reflecting regulary and with purpose. I won’t be able to discover all my blind spots in the process but I’m getting better and better at it.

In the past 5 years I’ve found that I like to and can be good at training and coaching people. I’d been in testing for a bit less than a year when I had to hire and then train 2 new testers. Whatever I had learned in that year I had to pass on… quickly and effectively. This made me sharpen the focus on how to build the team, how to build skills in the team in a way that would have decisive impact (because ain’t nobody got time to wait until I take my time with it). Building a team for me is about creating the right conditions for people to do their best work. I can be quite protective if someone wants to stop them from doing that (because they have to go over my dead body but I refuse to die or get out of the way).

I also discovered that good leadership and people management is what I’m passionate about. Having reflected on my previous experience and having seen some dire “examples” of mismanagement, I get really fired up when I happen to see one again. I want to help people understand how much impact they actually have as managers and how much awesome it will be if they don’t try to just get by but commit to their team and serve them. I didn’t know I could lead or I would care about this topic so much but I’m glad I know it now. Because now I’m aware and can think of ways how to help. And I believe, maybe naively, that other people can cultivate their leaderhsip skills if they decide they really care.

I used to think volunteers were weird. Why do anything for free and out of your free time? Now I’m a big time weirdo myself thinking, reading, writing, sharing, talking about testing, helping to edit articles, helping to arrange testing events… What I didn’t know before is that if you find something you really like, you want more of it. And you especially want more of it in your free time because… well, it makes you feel awesome.

I guess there are many more lessons (and they would make this post awful long). I’m inredibly grateful for having been given the chance to learn about testing and thankful to myself for having the wits to have taken it. Somehow I’ve made it from a clueless test lead to Head of Testing. I don’t even dare to think of what lies ahead… No, wait! I DO dare to think about it and I will. It would be really weird to find myself in the same place as I am now in the next 5 years… I don’t know where I will end up because I sure as hell didn’t know I would end up where I am.

I want to thank everyone who has helped me in any way, who has taken the time to talk to me, who has had to exercise their patience to talk me into things (or out of things), who has taught me even if they don’t know they have. Thank you.

Here’s to many more!

Transpection Tuesdays Still Going Strong

Since September 2013 Erik Brickarp and me have spent a few hours on (most) Tuesdays to discuss testing or our lives and careers in relation to testing. What started as a spontaneous experiment has turned into a routine, a staple in our lives, a commitment. Erik spoke about Transpection Tuesday at #SWET peer conference (Swedish Workshop on Exploratory Testing), I gave a 99 second talk about it at TestBash last year and a lightning talk at work. We’ve both spoken about it to several people over time. We have tried to demystify Transpection Tuesday as well as we can because we do get questions about how it works and what we talk about, and, probably most of all, why we keep going.

So we ended up doing a kind of retrospective on Transpection Tuesdays a while ago. We attempted to answer questions such as “What kind of specific questions have we tried to answer?”, “Why has it been a good idea to keep going?”, “What formats have we used and how have the formats evolved?”. We also used some elements from the PROOF debriefing mnemonic.

At least one blog post has come out of this retrospection… Maybe there will be more. This one will offer answers for the question:

What are some good reason to keep Transpection Tuesdays going?

A Never-Ending Conference

We met in person  at Let’s Test 2013 and Transpection Tuesday has been a way to keep the conference going. It’s as if it never ended. Conferences provide social learning experiences that can be empowering, energizing and motivating. Discussing and exchanging experiences, letting down your guard and freely exploring ideas (or rather, conferring about ideas) help make sense of your own experience and thoughts, and help look at them from new and undiscovered perspectives. New ideas are necessary for solving problems you haven’t solved yet. The positive “slap on the back” you get after a good and open discussion is just what you may need to turn a new idea into action.

This is very much what Transpection Tuesday is about. Talking face-to-face over Skype is a personal and engaging way of socializing that doesn’t compare to Twitter chatter or emails. It’s a no pressure, no risk, relaxed environment that makes a great weekly conferring session.

A Supporting Structure

We are both driven to become better at testing. We’re passionate about testing. We both see many ways in which we could grow as testers. Having a fellow tester along on the journey has made us braver and more confident to face and take up challenges, and make changes in our professional lives. A lot of the time Transpection Tuesday is about giving and getting support in our ventures.

I feel that the sense of unconditional support that is readily available helps to overcome obstacles faster. There is hardly any need to keep circling a problem alone for a long time or think long and hard about who to talk to or ask advice from. I just have to wait until next Tuesday (or drop an emergency email) to get a problem thoroughly dissected, analyzed and discussed.

There is so much to learn about testing and sometimes it can feel a little intimidating to try to handle it all. Transpection Tuesdays sometimes are about overcoming the fear of complexity and failure in a low-pressure and safe environment. Having experienced dismantling some testing problems together has helped us realize that sometimes we know more than we first thought… or less, in which case we can consciously fix this problem.

A Habit of Keeping an Eye on The Ball

Transpection Tuesday is a way to keep ourselves focused on learning and development by discussing relevant topics regularly. Thinking about and discussing new concepts, revisiting known ideas to explore them further, or reflecting on and making sense of our daily happenings related to testing is a routine for us. It’s like our special tester’s mental floss. We want to floss regularly, don’t we?

We pick topics based on what interests us or what problems we need to solve at work. So one way of looking at it is that we sharpen our focus at work and think whether an idea or a problem would make a useful discussion and learning material. Chances are that we haven’t covered this particular topic or we think it’s worth revisiting to see if and how we’ve changed our thinking about it. This way we scout for interesting things we want to know more about (which keeps us looking) to take to Transpection Tuesdays (which makes us focused).

A Return on the Investment

It’s fair to ask whether one couldn’t just develop their skills and understanding about testing on their own. Why bother with such commitments to someone else but yourself? We find that the time we spend on Tuesdays is a return on our investment. We feel that we’d spend so much longer on our own getting to where we are now. A heuristic I use is that I’ve become more confident in my knowledge and skills thanks to Transpection Tuesdays. This is a major return on the investment for me.

Mentoring Is (Low-)key

We have different experiences, backgrounds (an electronics engineer meets an English major) and careers (a tester turned into a teacher of testing meets technical writer turned into a tester/test lead) which makes it all the more interesting. Mentoring each other isn’t something we try to do on purpose. We’ve just found that it’s something that happens when we discuss topics that one or the other has more experience with. So it’s low-key mentoring.

We nudge each other, give feedback and sometimes say “wow, that was brilliant because…” or “ok, this was a little bit stupid but let me help you…”. We know each other well enough to know when to keep pushing and asking questions and when to pull back or give time to breathe. This is one of the benefits of keeping at it for a year and a half: you know the other person well enough that even if you accidentally push too much they will forgive you.

We Don’t Know Why But We Just Do It

Eventually, when all of the above fails to explain why we keep doing Transpection Tuesday, it may well be because we haven’t fully understood it ourselves or aren’t yet able to express it eloquently enough. We feel like we’re just scraping the surface and that there is some underlying fundamental reason it works so well. Sorry, we’ll try again sometime.

Some Notes from Copenhagen Context 2014

Copenhagen Context is a new conference held in… Copenhagen, obviously. The focus was on longer keynote-style talks, so the whole conference was comprised of 5 talks. However, some of them introduced practical exercises as well. I’d go so far as to say that such talks align with the spirit of the context-driven community, i.e. ideas you introduced should be applied in practice.

Overall, I think there was a good balance between philosophical, inspirational and practical talks covering different aspects of context-driven testing. I left feeling content and equipped with useful material. Thanks to Morten Hougaard (and Anette) who put such a great program together!

Michael Bolton took his time to get to the whisky part. I almost got thirsty. He talked about the principles of context-driven school and his preferred order. I agree with putting the third one (people, working together, are the most important part of any project’s context) to the first place because it goes well with my own observations.

He also talked about the paradox of CDT: instead of being context-driven we sometimes have to be context-driving as we need to change the context to persuade someone that there is no one true way. That’s when you’re not context-driven.

Though, when I think about it an tie it with my experience, I end up with something like “the context can drive me to become a driver, that is due to something in the context I decide it has to be changed”…

Carsten Feilberg encouraged us to use child labor for testing remember how we used to be natural explorers as children, and how heuristics help us comes up with test ideas. It was useful to be reminded to go meta yourself and recognize the heuristics you actually use. I guess that if I tried, I’d initially come up with fairly context-specific heuristics but I’d like to try and generalize them. Although I think there’s a fairly good chance I’ll just re-discover what others have put out there. It would be a good awareness exercise anyway.

Carsten didn’t really trust a room full of testers with his remote-controlled helicopter (the remote was out of our reach but we could gently touch the helicopter at least). But it was fun to think about test ideas for it. Funnily enough, my first couple of ideas were pretty much a perfect match to the mission of Carsten’s test session of the helicopter: finding out the range of the remote control and if the radio signal could get obstructed by objects, and if the helicopter could get lost (apparently, my hunch was right and Carsten did find a bug with that :)).

I missed out on Louise Perold‘s beer testing session at Let’s Test last year but I was in luck this time in Copenhagen. Many interesting conversations were sparked and cool ideas introduced as people were thinking of testing a bottle of beer. I really think it is an elegant example to use beer as the product to test because it’s versatile, informal, and pretty much everyone can relate to it in some way.

I really liked the idea of “talking to the function in your own words”. I tend to forget the power of paraphrasing from time to time but it is really powerful for clarifying my own thinking as well as detecting fuzziness in other people’s thoughts.

I’m going to work through the slides and the ideas again but there’s a lot of stuff I want to share with my team.

Huib Schoots‘ talk was about what he believes are the key ingredients of becoming a great GREAT tester: passion, learning, and courage. He emphasized practicing testing and asking feedback for learning purposes. Since Huib challenged the room of testers on knowing the test techniques they use (or rather… the number of them), it made me think of what are the criteria for professionalism in context-driven community. I asked him on Twitter, so now I’m looking for that blog post 🙂 Though I’m thinking now that “heuristics for recognizing professionalism” is a better way of putting it (inspired by “Context-Driven (presentation) heuristics“).

Finally, Henrik Emilsson encouraged us to put names and faces next to stakeholder roles, think of them as people (and the feelings we have towards them), and THEN think of how to communicate the test strategy to that person. The session included to practical exercises which I liked (they focused on writing) but I shall try this out on my own. I gave it my best but I felt I was getting tired already.

One of the most valuable thoughts for me from Henrik’s talk was related to having invested or detached stakeholders. I’m wondering if great test strategy communication could be way to gently “re-attach” stakeholders to projects. And I can see how this goes well with systems thinking when solving problems… So yes, a lot of good stuff to think about for me as I’ve been trying to improve my communication of test results over the past 6 months (still have to blog about it…).

And then I met my testing friends from Twitter and had a great time at a pub solving a testing challenge. There was other stuff but… what happens in Copenhagen, stays in Copenhagen 🙂

See you there next year?

The GNIKCUF Awesome conference – Let’s Test 2013

I have studied languages most of my life, yet I’m lost for words.

During the hours between now and the time Let’s Test conference ended (or did it?!), I feel like I am “growing into a very special family”. The reason why Let’s Test feels like an explosion in my mind and soul is that it conflated awesome ideas and passionate testers, and all of it happened in limited space and time. There was a lot of energy in the air (and Huib the Wise said that energy should be followed) that people brought together. And this is how I will remember the conference – not just the tracks and keynotes but the magic that happened at dinner table, sometime between sessions, late at night.


Here are my rough (and condensed) notes hot off my red notebook (in the order I took them):

Keynote – James Bach “How Do I Know I am Context-Driven?”

  • Dangers of shallow agreement: it’s important to know WHEN we don’t agree as we need to trust the agreement; debate should be allowed to avoid shallow agreement
  • Aspects of context-driven: community (people, mutual influences), approach (heuristics applied), paradigm (the model for understanding the world)
  • Rephrasing “context-driven” – a humanistic problem-solver is aware of their surroundings

Ilari Henrik Aegerter: The Challenges of Brilliant Observations and the Fallacies of Convincing Descriptions

  • DON’T TRUST YOUR BRAIN (yes, this is exaggerated)
  • Being aware of the “filtering power” of our brain: a number of things can go unnoticed while a lot of things are “helpfully” (re)constructed.
  • Power of priming: it makes it easier for us to retrieve information associated with the “primed” piece of info (priming is a familiar concept to me from psycholinguistics and it got me thinking about priming my brain to find certain kind of issues/info while testing…)
  • Putting the “(re)constructive” power of the brain to a good use: too detailed instructions/descriptions (difficult to follow, probably too much to process) versus too general (too open to interpretation) versus sufficient (enough info so that the rest can be filled in)
  • Tools (eyes) can be poor but the engine (brain) is great

Johanna Rothman: Kick-Ass Manager

  • It was a kick-ass keynote! I would’ve liked to stand up and say “AMEN” a lot (*hears the choir in her head*). I found that I’ve done or tried to do several things that Johanna was talking about.
  • Rejecting victimhood and taking the responsibility were thoughts that resonated with me. It’s easy to become a victim if the going gets rough but trying to keep what I call “productive attitude” is what’s going to get you out of there.
  • Ask questions about the career: what do your team mates want?
  • The importance of one-on-ones: creating a space of trust and openness helps people share their troubles and celebrate their greatness together. I also believe this makes the teams stronger in the end (and I have experienced that myself, too). The most important condition here is that you deeply care about the people you work with.
  • Understand what is important to the business!
  • The chasm between visionaries and pragmatists: what does quality mean to the product?
  • Foster learning: this is how you can grow the people you need.

I am also grateful for Johanna for this piece of advice I got at the breakfast table: “live your values because you have to live them; but see how you could serve your company using those values.” I have been circling around this idea myself trying to meet certain challenges and this provides a great perspective for me.

Maria Kedemo: Hiring to Solve the Puzzle

  • Random thought #42: shirts with studded skulls rock!
  • RISCx3 matrix: a model that helps you remember the important pieces of information/activities (my random thought: helps with “coverage” of the hiring process; helps with comparing applicants across the matrix); the matrix actually needs a longer discussion…

Leo Hepis: Linguistics – On How to Keep Dialogue Constructive

  • I guess I must have pleasantly surprised Leo over lunch when he briefly summarized his talk and I asked “oh, you mean the Grice’s maxims?” 🙂 I am always glad to meet people who pull stuff from “my field”.
  • Since I participated in preparing for the exercise, I don’t know what was the discussion of the maxims like (but since I know what they are anyway, then I guess it doesn’t matter).
  • I liked the idea of setting up a dialogue so that participants could observe the exchange and detect the potential violations of the maxims.

Fiona Charles: Leadership Heuristics

  • Fiona set up a short but productive workshop where the heuristics for leadership were brainstormed. Our group had a great discussion about them and we came up with these: find time to talk/travel to people (the importance of casual conversation); giving trust; short feedback loop (honest, quick, and open communication between a leader and their people). For the heuristics, we also had to think of three conditions/context when they worked and three for when they wouldn’t work. I just hope the photos of the posters will become available…

Tobias Fors: Systems Thinking for the Rest of Us

  • ORG DOODLING! Components: me&the problem; other people; resources, platforms, tools; relations, interactions; problems/pains; joys/strengths; what else is missing. I already showed my doodle to my boss today 😀 See, I already got to use it. I really want to do more doodling to model the issues I am trying to solve.
  • MESS is a system of problems (I love this phrase!).
  • Org doodling is good for finding a different perspective on the problem.
  • Assume that people are rational: if you explore why something is true for other people, you may reveal the unseen structures that previously made their behavior seem strange; but if the structures are visible, the behavior is understood better.
  • Performance is the product of interaction between the different parts of the system. So to “fix” something, don’t focus on the quality of one particular part but focus on the interactions of the parts.

[notes and drawings about some stuff I explained to Erik (@brickuz) – thanks again for listening to the rant! 😀 I guess I’ll write a short blog post on one of those things as it could be useful to other awesome testers, too]

John Stevenson: Information Overload

  • Information overload: available information exceeds the user’s ability to process it (the same thing was happening to me at the time of the presentation… hence my crappy notes)
  • Be aware of being anchored in a particular context or being primed. What to try to shake them off? Try Weinberg’s rule of three and slowing down.
  • Plan making mistakes (maybe this would help to  be less afraid of them as well?)
  • Pro-tip: send your testing notes to yourself at the end of the day and read them next morning (see if you understand them and SPOT MISTAKES).

Steve M. Smith, Debugging Human Interactions

  • To put it shortly, this was an awesome workshop where the participants formed two live super-organisms that interacted with each other.
  • The breakdown of communication helped to see how much actually gets lost (yay for bugs!). Knowing that, you can go back and ask to repeat something.
  • Connection between low self-esteem and defense; the importance of feelings about my feelings.
  • Try to think of more meanings: this means feelings will be activated less.
  • Survival skills: rules about life + metarules trigger certain behavior

Zeger van Hese, Testing in the Age of Distraction

  • Zeger talked extensively about (de)focusing and the presentation was packed with information! What’s not to love!
  • http://coffitivity.com/ – I already found it useful today
  • Procrastination and how to deal with it: I liked the idea of first scheduling things I wanted to do, then things I have to do.
  • Reflect and defocus without guilt – your best ideas won’t come to you when you focus hard.
  • And a lot of other useful stuff.

Scott Barber, Business Value of Testing

  • Man, I was sitting in the first row but was about to be blown off against the back wall by Scott’s energy 😀
  • I learned I’m like coffee in value 🙂 But I can be VERY good coffee (and who wouldn’t hate BAD coffee, eh?)
  • Understand the business and learn to speak business.
  • Understand your primary business mission and forget about being the white knight on a white horse who salvages the world.
  • Goal: become invaluable to the business.

I want to thank everyone that I had the chance to spend time with and talk to. I am very sure I am going to miss somebody because the whole experience is a bit of blur right now (and it’s 2:30am right now, too). But I can’t wrap up without mentioning Huib, Erik, Aleksis, Johanna, Carsten, Ilari, Paul, Simon, Martin (ha, you guess WHICH ones! :D), Leo, Kristoffer… and so on.

Thank you everyone and see you next year!

What I Learned: Coaching Testers with James Bach and Ann-Marie Charrett

Thanks to the ever charitable Rosie Sherry, I was able to attend the course “Coaching Testers” in Brighton earlier this March. I was expecting to learn about the mechanics of coaching and to reframe and reevaluate my previous (practical but mostly intuition-based) experience. In this post I’m going to give an overview of what I learned from the first half of the training (for the sake of my readers and for the sake of me writing shorter blog posts :)).

What I liked about the course was that after a fairly brief introduction about the coach-tester relationship and the coaching space, we got to work and conducted a brief testing session as a student, then reversed the roles. Just 15+15 minutes later I had learned a couple of lessons.

Firstly, even if the coaching session has a relatively “loose goal” at the beginning, it is important for the coach to pick a trail quickly enough to avoid a situation where there are two lambs (not just one) wandering on the meadow. Of course, it is challenging to pick a suitable topic when you hardly know the person and their skills. I’m thinking that even a preliminary coaching session for mapping the student’s skills and building the relationship is a good start.

Secondly, beware of the magic and mechanics of hearing, listening and processing student’s responses. For example, I picked up on a vague explanation my student gave and I wanted him to be more specific. He explained again. I wasn’t satisfied and applied some more pressure. He explained again. Since I had a fairly specific answer in mind and I didn’t hear it, then… well. Luckily, James was observing this exchange and said “oh, but he IS more specific now!”.

I suddenly realized that while trying to process the student’s answer, I was comparing it to my preconceived answer I would have given. This made me deaf to what he was saying. I felt like I had slapped myself. At least I am now a wiser slapped version of myself.

Discussing it later, I was relieved to hear from James and Ann-Marie what I already suspected: improving the process of  listening, processing, and giving feedback is a matter of mechanics and practice.

Thirdly, focus on what and how the student is doing not on how you could do it better. It doesn’t matter. This is the conclusion Anis drew from coaching me (and I share his sentiment). Demonstration and concrete examples are in order if the student is in the state of “spinning wheels” and it seems to be very difficult for him/her to get back on track; or it may be part of establishing your credibility as a coach. But don’t rush it. It’s about the student’s skills.

These lessons I learned nicely fit into the model of the coaching space that James and Ann-Marie introduced. In this model, the coach and the tester bring similar elements to the coaching arena: both have their context, expectations, abilities, etc, yet these may not be shared through joint experiences (though I think that long-term coaching sessions would increase the overlap to some extent). Both share some of each other’s roles: the coach learns from the student, the student can facilitate coach’s learning. On that arena, there is energy (and trust) between the tester and the coach that needs to be managed. If I remember correctly, the managing of energy was initially attributed to the coach. But I think through the discussions we came to an agreement that energy and trust are to be read and managed by both (if we didn’t agree, then I guess this is how I interpreted it). Yet the portion of managing the pressure belongs mostly to the coach. And then there is direction given by the coach which provides the method for the session.

Using this model, I could describe my lessons as follows:

lack of direction on the coach’s part can make the energy wither so that the coach and the tester wander apart and maybe even leave the arena;

abilities and expectations can be different between the coach and the tester but one can find the other as a source for improvement (I can practice and improve a certain aspect of my listening skills);

giving direction should be administered with care and attention so that the coaching session wouldn’t turn into a training session without planning to do so.


These are some initial thoughts in context… I’m still processing the experience, so more to come.

Nordic Testing Days 2012: Keynote – How to Become a Really Great Tester by Torbjörn Ryber

When checking in to the conference, I was handed Tobbe’s “Essential Software Test Design” along with the rest of the conference stuff. I smiled because I remembered the hours I had spent reading this. It was one of the first books (if not THE first book) I ever read on testing back in the autumn of 2010. This was just a couple of months after I had started as the team lead of the testing and documentation team.

I re-read some chapters several times, I tried out different bug report stuff customizing to my context; I photocopied some sections so I could scribble my notes and go wild with my highlighter (I had borrowed this book from somebody working at a different company) and I shared this with my only tester on the team. Thinking about it makes me nostalgic, actually. I had just started, gone through Rapid Software Testing course, seriously started reading and researching and practicing… I have come a long way since then.

Yet, Tobbe’s keynote reminded me that I have a VERY long way to go. So much for feeling good about myself.

I don’t have many handwritten notes from this presentation because my pen went on strike, so I have lonely words and desperate scribbles in my notes (so I probably have forgotten some punchlines).

However, what I took with me and what stuck with me was the following (Tobbe’s points + my musings):

  • above all, you need to be motivated to become a great tester. One might say it’s a given or stating the obvious. But well, sometimes the obvious things must be stated to trigger recognition. The ever-frequent moment of recognizing old truths is what this statement was good for. And then you have all the more reason to dig into your motivation: what is it that really drives you? If that is not easy to answer, I suggest thinking about what are your values in life. I learned that at a training. Knowing what is important in your life in general also means you know what motivates you (hmm… maybe I should write a blog post about it later…).
  • just wanting to be a great tester is not enough.  You must have a plan. And then you need to execute it. Obviously, execution is the hardest part (no pun intended), and this is what separates wannabes from serious folks.
  • practical stuff: if you delve into something, then a good way to solidify your learning is to write a paper. I am planning to do that. Also, I am planning to ask my team members to organize their learning into papers.
  • I took a note to find out what is effect mapping .
  • I also promised myself that I would create a plan (more on this in next blog posts).
  • Thinking critically is something a tester cannot do without, obviously. I think I’m doing that as I tend to analyze stuff (all kind of stuff) but I think I need to learn to communicate the results of my analysis better sometimes (especially to people who know little about testing).
  • “Say NO to bad stuff”. YES! I want to say “YES” to that. This is something I feel strongly about. When I started, it was one of the first things I had to learn to do. A lot. I agree with Tobbe that it is absolutely necessary because then you have time for the “good stuff”. I’d also add that then you’re going to have time to do what matters, and have an impact instead of doing what you’re told and not being able to apply yourself. However, learning how to say “no” to people you’re working with (in my case, Americans who often misunderstand Estonian bluntness) is also important. I had to learn it the hard way but I have got better at it.
  • “Testing should be fun”. I totally agree and I have tried to make work fun for my team. We actually laugh a lot during the day as jokes fly around about bugs or whatever comes up.

All in all, it’s a keynote I have thought a lot about because it probably put my mind on the right track.

Tobbe’s presentation slides can be found here: http://nordictestingdays.eu/2012/uploads/Presentations/How%20to%20become%20a%20really%20great%20tester%20-%20Torbj%C3%B6rn%20Ryber.pdf

PEST2: Bug Chase

One of the things I mentioned in my presentation at PEST was the “bug chase” idea. I would categorize it under “fun things to do with your team to get the adrenaline running”.

Back in February somebody IMd me about a strange bug he had seen but couldn’t really reproduce. Since the effects of the bug seemed important and it affected critical business flows, it was logical for me that we as a team should act swiftly.

I felt that it would be a good idea to shake things up a bit and pose a challenge for a couple of testers. Depending on the workload, I allow or then curb distractions, shake-ups, or any other interventions to our work. If we have a good pace and things get done quickly, it’s good to pop in something fun. If there are a lot of things going on and tasks are pouring in, it is still a good idea to pop something in. It just might be something less time consuming.

In this case, I came up with a bug chase which ended up being a duel. If you want to include more testers, go ahead. There shouldn’t be any limits.

So… both got the same amount of limited second-hand information from me, both were familiar with this business flow.

If I remember correctly, I limited the time to 1 hour.

Ready, set, go! Who will be able to reproduce the bug first? Infinite glory will be yours.

A bit later one of them cheered and let us know that he got the steps. The other tester found another pretty interesting bug that is difficult to find (a kind of edge case but it was in an area that is at the heart of the product).

I was really pleased and excited because, for one, a certain important area got a lot of attention and depth in testing. Also, the feedback from them was positive and they liked this friendly competition.

Obviously, as a team lead you don’t want to put two people up against each other who don’t get along. Luckily, I don’t have this problem and the two testers get a long very well working together, sharing ideas, and supporting each other.

This exercise also gave me the confidence that I can approach them like this. Of course, I can’t crash the party when somebody has thoroughly focused on something.

So, if the atmosphere and the timing are right, the relationships are good, and the people understand that they will not be evaluated, the bug chase can contribute to team work and learning (what better way to compare the approaches when debriefing afterwards!).