Why I Spent A Day in Örebro (And What I Learned There)

Why spend my free time on preparing for a full day of lectures at some school in Sweden?

Why take a day off work to travel to that school right after an exciting but exhausting 3-day conference?

Because if at least one person in the audience feels inspired to do more, learn more, and become more, it has been worth it.

My friend Erik Brickarp asked me if I was willing to come and meet the students of testing he’s been teaching since last fall. He’s written about the education and the curriculum earlier. The goal of my visit was to share my experience and lessons learned to show what kind of things can happen in your professional career, and what kind of contexts and companies are out there.

Personally, inspiring someone or helping someone to realize they can do more they thought they could is a major source of satisfaction to me. I hold dear the moments when someone lets me know how I’ve helped them. For instance, someone from my team once told me that I’m one of the two women who changed their life (by hiring them, patiently training and coaching them about testing). Recently, another person told me that me joining the company has been one of the best things that has happened to them recently.

Maybe I shouldn’t be living for these moments but in some ways I do anyway. How wonderful is it that my presence and interactions can give a new course to or new perspective someone’s career (in testing)?

So my goal was to be present and share what I’ve learned. And hope something sticks and something wonderful will grow out of it (yes, I can get almost teary-eyed at this point…).

What did I share?

Part 1: I talked about my career and the twists and turns in it, why I took a chance that landed me in testing, and what I learned from it. I talked about what I learned about myself and what I learned about the world of software. I talked about what really made the difference and helped me progress, and that it wasn’t just about me but also the community.

Part 2: I talked about Raintree where I worked both as a technical writer and a team lead. I gave an overview of the product and technology mostly because it’s old, and a bit special. Hearing about such things might be a good thing that broadens the mind because even though it seems like nowadays it’s all about mobile apps and the web, you may end up in an interesting place with old and custom technology. I also talked about the testing challenges and a little bit about how we tried to tackle them.

Part 3: I talked about building a bridge between testers and developers based on my experiences at Raintree where a testing team was injected in the middle of developers, and noone knew how to work together. I gave a talk at Nordic Testing Days in 2013 about it, so I used some of the content. Of course, I looked at my slides and hurtfully facepalmed… What the hell was I talking about anyway…?! Anyway, I guess it was a good thing to realize that I now know better and that I’ve developed in the past two years 🙂 So in some ways preparing my talks for the testing students was useful for my own sake because I had to go over my lessons and experiences again.

Part 4: After lunch, it was time for something else. Erik and me had agreed that I will do an exercise on him using a small “device”. He knew what it looked like, so I invented another surprise for him during the exercise. The main point was that he had to test something, I needed the results quickly, and I ran away into meetings a couple of times which is a realistic thing (the meetings were the surprise moment which also gave Erik time to involve the students by asking them for suggestions to get out of the situation and satisfy the customer). I’m not the “bad cop” type of a person in such situations but can still push it (by saying things like “so are you a philosopher or a tester? Looks like most of what you do is talk and not test!!!”). I think I could’ve carried it out better, so I need to deconstruct what I was trying to do (something for me to learn) but it was quite fun. Students saw their teacher in a pickle – what could be better? 🙂

Part 5: a bit of a high-flying topic but it’s something I feel very strongly about, so I couldn’t leave it out. It’s about leadership and working with people. I titled the section “test leading” and claimed to talk about test management. I also claimed the picture of a big glass diamond with “This is what you made us” engraved in it was my credential from my team that I knew what I was talking about when it came to building teams and leading people. Yeah, Helena got ballsy.

My main point was that for me test management is mostly about managing humans who happen to do testing. Therefore, knowing yourself as a human being, self-reflection, and empathy towards other people come first. Yes, you need to learn about testing, too, but if you hurt people trying to “manage” them, your testing knowledge won’t take you very far (in my eyes). So I ended up talking about how I’ve approached my role as test lead, and what kind of other things people in this role have to deal with besides human beings.

At the end I asked for the one thing they remember or feel like can take away from the day. Someone said that they remembered hearing about how I struggled. It was an interesting comment because I did talk about my struggles a lot. I did struggle a lot but I start to forget the pain little by little.

Someone said they liked to hear that it’s possible to get somewhere and achieve something in IT even if you don’t have a technical background (my rough paraphrase as I don’t remember the exact quote). Someone said they liked the idea behind the Richard Branson quote I used (If somebody offers you an amazing opportunity but you are not sure you can do it, say yes – then learn how to do it later!). And so on. One of the students came to talk to me afterwards and I tipped him off about Weekend Testing. He asked for coaching over Skype. See? Things happen when people talk to each other.

Also, it was great to get feedback from Erik who said I’m much more confident as a speaker than before (he saw me give a lightning talk at Let’s Test 2014), and that the pace was good. Well, that’s great to know and I felt quite good about the overall presentation. It never hurts to get to practices public speaking for a few hours, especially since I’m interested in speaking at conferences.

A Public Speaking Heuristic Discovered

One of the most interesting things was that there was a deaf girl in the class, so what I said in English had to be translated into Swedish Sign Language. There were two interpreters taking turns translating me. So I ended up learning a valuable lesson: having two interpreters depending on me to produce clear and “translatable” sentences makes me a lot more conscious than usual of how I actually say something. I caught myself on the verge of “rambling to mumbling to fading off” more times than I care to remember now. It’s so easy to do. So I forced myself to take a couple of seconds and round up my sentences. I forced myself to adopt a slower pace than my “natural” talking speed. This was quite good for me as I sometimes run out of breath when I get excited and start talking faster and faster (and if I also engage my hands I almost have lift off…).

I mean I had two interpreters sitting within one meter from me and the deaf girl in the first row. There was no way I could ignore their presence and it was a constant reminder for me that kept me in check.

Another related idea: I haven’t really tested for accessibility before. Now it was as if I had to constantly keep tabs on the accessibility of my speech, and the presentation in general because the need was real.

So here’s a public speaking heuristic called “Help the Interpreter” I’ll be using from now on: while giving a talk imagine a sign language interpreter sitting next to you and think of helping him/her do his/her job well.


Last but not least, I had a very nice chat with Björn Kinell who drove me from Runö to Örebro. And I got to meet Torbjörn Ryber again and catch up a little bit. So despite being beyond tired afterwards, I still say it was worth it.

So maybe you know of a place where someone teaches software testing. Maybe you could contribute by meeting aspiring testers. If nothing happens, then nothing happens. Make things happen just by sharing your experience.


Proof that I was there (or in some room somewhere that looks like a classroom)

A Workshop on Testing for Programmers

An idea had been twirling around my brain for a while. Then it became more and more insistent on breaking into the realm of reality. In the context of continuously learning about testing, and in the context of recognizing the ongoing challenges of programmers and testers working together, I realized that I need to do more about it. Quick conversations over lunch or in the hallway about one or other aspect about testing just didn’t seem to be enough. There needed to be something that’s a full package, coherent,  concentrated and experiential. There needed to be something that would renew the foundation for future conversations between testers and programmers.

Mission: create a full-day workshop on testing that would be tailored and targeted at the programmers I work with.

I consider this workshop as one of the great outcomes of Transpection Tuesdays. Without the work I’ve done with Erik Brickarp and without his support and encouragement, it would’ve taken me much longer to muster up the confidence to create and carry out the workshop.

The keyword here is “tailored”. Fun and exercises aside, I focused on tying together the general introduction into testing, the way testing had been done by my team, and whatever else was relevant in the company’s context in relation to testing. I wanted to frame some of the specific problems in our company as testing problems and have a discussion about them.


  • give a concentrated introduction to testing so that fragments of what programmers already knew were tied into a whole
  • introduce and explain testing problems to  programmers so that they could be understood and discussed better
  • immerse programmers in some testing problems so that they would see and experience them up close (followed by a discussion and explanations)
  • explain what testers do and tie it into their experiences of working with testers so that programmers can make sense of their experience and forge even better relationships with testers
  • explain the tester’s mindset and vocabulary so that further conversations between testers and programmers could be more productive

Why I’m Sharing This

I’m sharing this just because I believe from my experience that creating such a workshop can be useful and educational in many ways, and there are surely people out there who need just a bit of nudging to do something similar where they work.

Slides and some accompanying materials can be found here.

It doesn’t contain all handouts because well… what you think you need to provide to people you work with will really depend on the kind of workshop you create. I also didn’t include my notes for slides because they have quite a lot of context-specific stuff in them and it didn’t make sense to try to clean it up.

You can grab them and run but it would be so much more useful for you if you read the following as well 🙂 Then you will know WHY it is the way it is.

Planning: content and structure

Preliminary notes

One of my favourite ways of getting some mental work done is to go to a long lunch alone, take my notebook with me and just write my ideas down. I did quite a bit of work on the workshop in that manner, clarifying my initial ideas about the structure of the workshop, taking notes about what kind of exercises to use etc.


  • I created a mindmap using Xmind to sketch the initial structure of the workshop. The mindmap I’m sharing with you isn’t perfect and it looks sketchy. I just used it as a starting point.
  • I mindmapped the big sections and also drafted ideas for subtopics to be covered in sections
  • I added labels to each chunk estimating the time I’d be spending on it. Then I summed them up and the result was the time I was going to spend on each section. And from there I could calculate the time I’d spend on the whole workshop.
  • Estimating the time spent helped me balance the sections and decide whether to include or exclude content. It also kept me in check and guarded against adding too much.

Slides and notes

  • Based on the mindmap structure, I started drafting my PowerPoint slides, taking notes about the content and gathering relevant references.
  • I kept track of references in a separate document to make sure I can hand that list to the attendees later.
  • Working with the mindmap and slides I did a lot of gauging of the flow and used internal monologue or tried explaining some concepts to myself. The purpose was to make sure the flow of ideas made sense and that each section built upon the previous one. In that process I made structural changes to the mindmap which provided me with a good backbone and overview of the workshop.
  • For each section, I added a separate title slide and a recap slide. The idea was that the day will be so packed with information that it’s better to add some points where I can concisely summarize what we just talked about. All those recaps would then go on one sheet of paper. If that was all they ever kept from the workshop… they would have the essential ideas captured.


General idea behind beer

  • I wanted to have a “thin red line” that would run through the workshop. There would be so much ground covered in terms of concepts that I felt like falling back on a single constant thread would help pull us all back in.
  • I found that thin red line in the workshop by Louise Perold on test planning that I attended at Copenhagen Context this January. She used bottles of beer as the product in the workshop and it worked really well for a test planning exercise. Sure, it’s not software but… beer is fun, fairly well understood and doesn’t need much explanation. So I discussed this with Louise and she was fine with me picking up the idea and using it myself. Many thanks for that! 🙂

Kick-off exercise

  • Testing the beer was to be the thin red line and the kick-off exercise.  Each team of 3-4 people got two different bottles of beer. The only brief I would give to testing beer at 10am in the morning was to “test the beer and explore it” in 20 minutes. I didn’t give them the bottle opener as I wanted to see if any would ask for it. I gave them a sheet of paper and colorful markers to write down whatever they wanted about the beer they tested. I made observations and took notes about what they said in their interactions while they were testing the beer – I’d use these notes for debriefing and for tying the discussed topics with the rest of the workshop. For instance, if I’d ask how they knew the beer was OK, they could give me answers like “from my personal experience” and later when getting to oracles, we could discuss their initial test run in the light of heuristics and oracles (or anything else we covered during the workshop).

Follow-up exercises with beer

  • Testing mission – since very few asked why they were testing the beer and what was supposed to be accomplished, I used this as an example of how not to approach testing… and then asked them to figure out a few testing missions for beer that would frame the testing activities. I also brought in the project lifecycle to show how different things can be tested for over time.
  • Oracles – since it wasn’t that easy to find actual issues with the beer, it gave me a good segue into asking why couldn’t they spot some problems. And from there we could get into oracles and how they’re useful for testing. Later I used as another recap of the kick-off exercise when trying to come with some oracles for testing the beer and pointing out the ones they had actually used but didn’t realize it.
  • Test strategy – I gave them a brief, then asked to come up with a simple description of a strategy. I mostly meant this one as the “dip into this but don’t get too deep” kind of an exercise. The point was to teach about test strategy per se but to make them feel how difficult it may be to word it. Also, I gave them the whole HTSM on paper but limited what they had to use. It was probably a bit too much…. in terms of balancing time and materials. But I feel like they got the sense of complexity out of it at least…
  • Creating a script for opening the beer. This was a pretty fun one… The idea was to create an experience where you’re supposed to do something simple – just follow the instructions. But then describing how to open a beer in a specific manner isn’t THAT easy. So on the one hand, people could get creative (some drew up pictures to illustrate the steps) but then when executing the steps, I limited them in their interpretation. One of the coolest instances was when the script was followed precisely but the beer bottle ended up with its cap on not off  🙂 There was a very interesting contextual cue that a programmer decided to “misinterpret”…
  • Testability – when discussing testability, we returned to the beer trying figure out what would make it easier to test beer.

Other logistics

  • I divided programmers into 3 groups of 9 which meant I ran this workshop 3 times. This seemed like a manageable amount of people for me.
  • Since I knew them all well (I’ve worked with them for years), I tried to balance out the groups so that programmers from different teams could interact as well.
  • I tried to make the first group the most difficult for me in order to make sure I will find any issues in how I’ve set up the workshop and fix them before the next one. That one I got right – they were active, wanted to argue (not just with me… even more amongst themselves), wanted to discuss problems and potential solutions to them. I was able to figure out some issues in the order of sections which was a good thing to fix.
  • I had snacks ordered for the breaks and pizza for lunch – just to make it easier for everyone.

Lessons learned

  •  Oh my god… was I tired after the first workshop! I felt completely exhausted. It’s the type of feeling when everything is in slow motion… like reaaaaaallllyy slllooowwww…. But I still felt great about how it all turned out. Luckily, the 2nd and 3rd runs weren’t as exhausting.
  • I learned how much time actually goes into putting a workshop together. I think I may have spent at least 100 hours when preparing for it.
  • I learned that I enjoy working on a workshop like this. It helped me to freshen up what I know (well, it’s fairly well known that teaching someone teaches yourself a lot, too). I also enjoyed delivering workshop even though I got tired and some people started arguing a lot 🙂 It was fun to observe how programmers from the same team started arguing how to test better and what they could or couldn’t do on their end. I felt like getting such a conversation going was an accomplishment on its own.
  • I wasn’t very good at using all of the information I picked up from eavesdropping on the conversations taking place during the exercises. I guess this is a matter of practice and a few other things… like having a much better command of the material. I feel like I could’ve done this part a bit better.
  • The second half of the workshop could’ve used more actively engaging exercises. For some reason I figured people could be too tired for them… but I guess there should’ve been something that would shake people up 🙂
  • After the first run, I did change the order of topics in part two: I figured I should introduce the terminology of oracles and heuristics before starting to talk about heuristic test strategy model. Else I would introduce words I would only explain later.
  • Good feedback from participants was along the lines of “I had no idea testing is so complex” and “I didn’t know how much more there was to it”. Someone even said that “I figured testers had to be smarter than programmers” 🙂 Since I left the company about a month after wrapping up the workshop series, I can’t tell what kind of overall influence the workshop had. But a few programmers I’ve talked to afterwards have told me they’ve thought about the workshop and what they took from it, so… I guess that’s a good thing. Even though I didn’t mean it this way, the workshops turned out to be my gift to my colleagues before I left.
  • It was also pointed out the using the image of a house helped to pull together some loose ends. Talking about the point of a house (it’s where people live in) nicely summed up the reason we ever develop something – there is a purpose for some human beings.
  • Would I change anything next time? Yes. I would probably pick a piece of software or prepare it myself (you know, learning challenges for me too…). I’m not sure I’d pick a different one for each exercise or not but I’d consider it.


Am I happy with my first attempt at putting together a workshop? Yes, quite 🙂



PEST3: Kickstart learning by teaching! Vol 2

Here are my notes  and thoughts about the rest of the presentations at PEST3.

Raimond Sinivee talked about how testing is perceived without teaching. His example was fairly simple but effective: have someone who doesn’t know much about testing set up a Selenium script. If they don’t know much about testing, then the idea of simply recording and playing back the script sounds very alluring (as we know…). Yet spending a little time on trying to set it up and then play it back with appropriate comments and feedback may teach more than all the hallway talks.

As Raimond showed, it is easy to come across the scenarios that should fail but don’t. This should prompt the teacher to talk about the weaknesses but also strengths of tools, about how, where and why to use or not to use tools. It is the teacher’s job to explain those possible contexts. I think he made an excellent point about keeping in mind that teaching about tools shouldn’t vacillate between “tools are great!” and “tools are useless!”. It’s better to start a conversation rather than remain binary.

Harles Paesüld talked about his teaching experience at the universities and what he has learned from this (he also touched upon his experience with the BBST course and other AST courses). The main learning outcomes for him were the following: have specific goals for learners; prefer narrower scope when choosing material and topics for teaching; make a quick and solid connection between the concept you explain and a practical exercise. Concepts may be easy to lecture on but it is the immediate practical application that will help the learners remember something.

Harles also pointed out that peer evaluation has been a big part of his own learning. He expects constructive criticism and refuses evaluations that simply say “very good” 🙂 Also, evaluating someone else helps you to digest the content of the course.

Petteri talked about the testing dojos. Boy, did this dojo thing get me thinking 😀 You could check out Petteri’s blog where he has described the dojos held in Helsinki (http://pro-testing.arabuusimiehet.com/?s=dojo).

In a nutshell (and in my interpretation), a testing dojo is an informal gathering of people who get to work in teams testing something for a limited amount of time. As I understood there may be unexpected scenarios tossed at the participants (this is the fun part, right?). Importantly, the participants don’t have to be testers per se. I think it’s actually more interesting if there are non-testers involved… (by non-testers I mean those that are not testers by their job description).

The main benefit seems to be the collaboration between people with different backgrounds and the possibility of non-testers getting their feet wet. I can imagine a lot of interesting conversations to be sparked if different perspectives are smashed together like this. So I’ll be looking forward to a testing dojo in Tartu 🙂 I want to experience one and then I have other ideas what to do with that experience 🙂

Kristjan Uba, our content holder and facilitator, also briefly talked about his teaching experience. His main point was that an integral part of doing a testing exercise is a debrief. This is because it will summarize the experience, reinforce learning, and help relate the experience and the testing skills this particular exercise was supposed to teach. Kristjan also pointed out that finding examples that anyone can easily relate to (some sort of real life situations) helps to explain concepts. Even though you may be teaching testing, you don’t have to relate EVERYTHING to testing.

Another method (that I myself have used as well) is that you have your student rephrase what they heard (OR they think they heard). I’d like to point out that this should be done carefully. I have some bad experiences with people who try to make me rephrase something TOO obvious (yes, it’s subjective). This didn’t help with cooperation and made me angry or insulated. Like, hey, do you think I didn’t get it? It wasn’t the fact that I was asked to rephrase. It was HOW I was asked to rephrase something. So here goes for the manners 🙂


PEST3: Kickstart Learning by Teaching! vol1

Last weekend I had the pleasure of presenting at PEST3 (third Estonian Context-driven Testers’ Peer Conference). The theme for this peer conference was focused on teaching testing. In addition to the presentation, each participant had to present an exercise for teaching testing. This “added bonus” turned out to be pretty fun for me at least.

So what was covered? Here’s the first part of my summary of the presentations.

Risko Ruus talked about how he taught management that things can be different and how he had to do his share of learning in the process. In his case, it appeared that the motivation to learn more came about when he was asked to work on his idea of a test tool to be used for smoke tests. As he admitted, his motivation had been sinking as his duties at work very quite routine and tedious most of the time. So when the opportunity was there, he took it and started teaching himself about programming to create the tool. Once the proof of concept was ready, he successfully sold the idea to management. I must say he has some mad salesman skills or the management happened to be able to grasp the idea without much difficulty 🙂 In any case, he could proceed working on his tool.

What he pointed out was that he always kept in mind the fact that he knew he was going to give the tool to other people to use. This forced him to think about teaching the future users and keeping everything simple and modular.

Eventually, he other team who got their hands on the tool got a bit carried away. Risko explained that they wanted to immediately broaden the scope and start using the tool for things that… Risko hadn’t planned. So here goes another point for teaching using a tool: be very clear and firm about the scope of your teaching. Listen to what your students say but don’t hatch a new plan or solution along the way. Managing the expectations is also a big part of successfully teaching someone.

Risko had a fun testing exercise, namely, juggling. So what does juggling teach you? Consistency, breaking down a complex activity. Risko also said he uses it for defocusing: it’s a good incentive to use in order to drag your butt up from the chair, move around, and give your mind a break. So you’re doing something physical and your mind is concentrated on juggling. But we all know how this works: you’re dealing with something on the surface while your mind solves some issues in the background.  This is how the heureka! moments are born.

Aare Nurm talked about coaching and SBTM. I really was one big ear because I’m interested in hearing about the experiences with implementing SBTM. I’ve been fidgeting with the idea and we occasionally apply this but I haven’t commited to SBTM just yet.

Fortunately, a lot of what Aare was talking about had a familiar ring to it. Important points I took note of:

  • he uses the debriefing session for a different function depending on context. For novice testers, it’s a coaching session. For experienced testers, it’s a learning session where he studies their minds and their test results.
  • getting the size of the session notes right is a difficult task at times. How much is too much or too little? His criteria were that the session notes are sufficient if all of it can be covered during debriefing (if something is left out – too much; if something needs to be checked – too little) and one has to be able to tell what they tested in a couple of weeks’ time.
  • Debriefing may turn into a brainstorming session and this is OK. It is my personal experience that these sessions easily become productive discussions. I haven’t tried to hold it back because I see a lot of good coming from this. I was glad to hear that someone has a similar experience.

I still need to figure out a bunch of administrative things before employing SBTM but I got a few simple but solid ideas that can help me.

Aare’s testing exercise was a sudoku. I haven’t really solved sudokus… I just haven’t picked them up. Aare, of course, gave us just a couple of minutes to solve this. Aaarghh… Well, I got a bunch of numbers right at least. I spent some time trying to figure out the strategies to use: I looked at number of digits in a row/column; how many numbers were in one 3×3 box and which number would most definitely match etc). Well, I guess if I practiced and found more strategies, I’d also become a better… sudoku solver 🙂 Though when talking about teaching testing, sudoku may be good for recognizing patterns, learning to use a proper strategy quickly (especially if you put yourself under a time constraint).