27 September 2013

Going Exploratory

Prerequisites
  • Test process dictating a factory testing kind of approach.
  • Progress was presented as pass-fail ratios with a brief comment at best
  • Test cases were saved in a humongous, very general, database application.
  • Bugs and requirements were saved in another humongous, very general, database application.
  • Most documents were based on big, thorough templates.
  • All development was split into features, a feature was then further split into smaller packages. A large feature could take over a year to finish (implementation description written to hand off to integration testing) while packages were typically released once ever two weeks.
  • The product was a huge real time system (middle-node in an even bigger system), had legacy from 1975 and was mostly written in a language older than C.
March to June - Starting out
Early in 2012 I was asked if I wanted to join a pioneering (second), self directed, cross functional team at my former job. It was the golden opportunity I had been searching for, in my wish to introduce more context driven thinking. I answered yes immediately.

Eager to put everything I had been reading about into practice I started scouting my possibilities. First mission was to figure out what "self directed team" actually meant. The answer was rather disappointing: "Well, you control the inner process but you have to provide the same output as everyone else" (documents, test case storage etc.).

I decided to interpret output a bit more... general (ask Meike about my willingness to test or bend rules). I began asking the various receivers of progress reports, strategy documents and other output, what questions they tried to answer with these artifacts. I then decided to interpreted "answering the same questions" as "same output", which would later stir up a lot of criticism but luckily noone seemed to know who was i charge of us at this point so I got away for now.

I began to wildly change everything around me, more or less removing the whole foundation on which all our previous testing relied without adding any new. For a while it seemed fine. I got shit done! It was fun, it was quick, it felt efficient, I was -exploring-!

July - Chaos

Vacation time, everyone was calm, just mentally preparing for a month of freedom.

... except anyone in contact with the testing in my team...

Everything was in chaos! In the midst of trying out everything I wanted to implement (but didn't understand), I had lost track. To make matters worse I had to, in the middle of this chaos, hand over my work to an experienced tester who would join my team starting the first day on my vacation. I scratched my head trying to figure out what I had done and what I wanted him to do. I sat down and started writing, trying to at least make it look like I had things under control. Doing this I realized my team was not informed about half of the stuff I called "how we work with test in my team". The dreamy world I had been living in dimmed away as reality slowly materialized in the document in front of me. When done I could at least breathe a sigh of relief, I hadn't screwed up everything (yet). I handed over my work and went on vacation.


Vacation
A well packed schedule was turned upside down when my youngest son was hospitalized with a severe bacteria infection. All the traveling back and forth to the hospital gave me plenty of time to reflect on my work. I slowly started to see ways of turning my mess into something valuable.

August - The turning point

Vacation ended and I headed back to work. The day I came back my new testing colleague, who we can call Saam, since that's his name, left for his four weeks of freedom. I started looking at his testing. It was also chaotic, but a lot more structured (call it professional if you like) than mine. I started to clean up my mess by attacking the main problem at hand: How to know what have been tested?

The first solution was nothing fancy, but oh so important: A simple spreadsheet with functions to test on one axis and general stuff like how the function works under load or during restarts on the other. Each box that formed had a color representing its status, yellow for unknown, red for open bugs, white for invalid combinations and so forth. It was basically a simpler version of the Low Tech Dashboard, which I unfortunately didn't know about at the time (if I were to redo it I would use the Low Tech Dashboard as my foundation). The document started almost entirely yellow (unknown) but at least I had a plan.


When Saam came back we started talking about how to work with test in general and found out we had very similar ideas. From here on forward things worked better and better, thanks to brilliant chemistry and adventurous but realistic approaches.


September to October - Upping the pace

Saam loved to dig into technical details, I loved the more overlaying principles, together we rocked! As we learned more and more and started to form a routine I began documenting the process that had emerged. It all ended up as a concise, rather visual, easy to grasp, four page process description, probably the shortest document ever created inhouse (of course not exaggerating even the slightest).

It basically said:

  1. Start a wiki page for the feature. Fill it with information like; lessons learned, operational instructions and where to find more detailed information. This wiki page is updated regularly throughout the whole feature and emphasis is on keeping it as short as possible, only including valuable, up to date material.
  2. Learn about the feature, read docs, speak with programmers and experiment with what exists already. While doing this, document test ideas and a brief test strategy. Don't plan to much but make sure good ideas aren't lost.
  3. The moment before code is shipped to us, grab the developers and possibly a testing expert/domain expert. As simple as possible, present our test ideas so far and ask for feedback.
  4. When the code is shipped, use the test ideas as input, but don't in any way limit yourself to only test those. The goal is to steadily add new ones as more is learned about the system and feature.
  5. As the perception about the status of a certain area changes, update the current status (color code) in the spreadsheet and add a few comments to help explain the situation. This spreadsheet serves as progress and coverage report.
  6. When done with testing in an area (group of charters) sit down together, look at the test ideas now documented and see if there is anything important left out based on current knowledge. Consider inviting a developer.
  7. When the whole feature is done, book a feature retrospective to reflect on the work done; what do we want to bring to future features, what could be improved, what should be avoided, new ideas, lessons learned, gaps in knowledge and so forth, both regarding the approach and the feature tested.
  8. The output of this meeting is an end report. The end report is basically the wiki page with ending notes added. The receiver for the end report is integration testers, testers testing the same/similar features as well as stakeholders interested in the work done.
  9. Anything in this process is subject to change if the context suggests so.
The example above is stripped from everything company specific but that more concerned how things were solved in our specific context anyway. Also the original process included a short description of how to actually work with exploratory testing in a way that provides visual structure and a bit concerning flow. It had it's flaws, sometimes based on lack of experience and sometimes on context (like how well we had to keep track of test ideas since test data in this form was sometimes requested by costumers), but it was a tremendous improvement.

By the way, the spreadsheet was later replaced by an 8 hour PHP hack... imagine being able to improve your situation by replacing a tool costing thousands of dollars with an 8 hour inhouse hack. I felt pretty good about myself after that day.

November to December - People finding out
Up until this point very few seemed to care about our work. Some liked our new approach and the qualitative reports we created was appreciated but nothing more.

Suddenly someone noticed we had left out basically everything described in the official test process. Our work was questioned, our judgement was questioned and people demanded we fixed our "mess" (document test cases done for instance).


Luckily for us we had prepared ourselves both to explain our decisions, how the new output fitted in the old system and how traceability was still achieved. We heard some grudges but since the testing in the feature seemed to be a success and the transition towards agile was in focus it was actually received rather well. Especially my boss at that time, and the two test managers, deserves a lot of credit for their reactions (they also knew to some degree what was happening in the team as we stopped making most of it a secret when things worked well again).


Today - Trying to support from the outside
The brilliant colleagues I had, including Saam, keeps pushing for the ideas we introduced. I try my best to support them but this blog post reminds me I could improve on that.


Important to note: The company in question has developed a lot since this story happened so it's not in any way representative for how they work now, it's just a story about change, nothing else!

Lesson: Breaking rules should not be your first option
If you think what I did was irresponsible, I definitely agree. I do think you sometimes have to bend or break rules to make change happen but it should really be your last resort if the stakes are high and done with great care. Speaking to whoever is in charge and change things that way is generally a much better idea... what would had happened if Saam never joined the team for instance?

If it's completely impossible to change something without going behind everyone's back, a new job is probably a much better option.


Lesson: You can change most things
To continue on my previous lesson: Notice that I've never found something that with the right skill, time and effort, didn't seem possible to change though. I know it exists (e.g. strictly regulated industries) but it's rarely the problem. So trying over and over again, staying naive at a healthy level, is a great skill/trait.

Lesson: Experience is invaluable

If someone tells me:
- This idea with lightweight test processes are just bullshit
My answer would be:
- Let me tell you about when me and Saam...

Lesson: Testing requires skill
I knew the theory about how to organize testing in an exploratory way already in June but it took me many hours of practicing to really become skilled enough to perform efficient exploratory testing. It's like driving, you can't learn just by reading, you actual have to practice (but reading can speed up the process).

Lesson: My unsuccessful experiments were just as valuable as my successful ones
When I started to reflect on my work during my vacation I used my experiences so far to find problems to solve. When doing this I developed an understanding of each problem that a successful experiment probably couldn't had provided me. This was useful later when I ran into other problems that I could somehow relate back to problems I already had encountered.

Lesson: Reflection is just as important as planning
Reality constantly crushed my plans but in the beginning I was so focused on getting forward I completely neglected this. When I finally started reflecting, it became an invaluable tool to keep me on track. Plans didn't take surprises (changes, my misconceptions, my simplifications or my lack of understanding) into consideration. All those required extensive reflection to figure out as I learned more and more.

Lesson: Adaptation is key
I tried to just pick an interesting concept and force it into my context, this failed badly most of the times. When I started to look at what I was trying to implement to see where and how it fitted, my attempts to introduce things suddenly became efficient. It's like solving a jigsaw puzzle with the difference you have an unlimited amount of pieces, only a few can fit in a good way, when you actually find a good piece you still need to cut it to make it fit and as you solve the jigsaw puzzle the picture you try to make changes... so kinda not like a jigsaw puzzle at all but maybe that gives you a useful mental image.

Lesson: Learn from others' experiences
One thing I used when trying to turn things around during my vacation was things other testers had told me, stuff like "we did like this but it failed due to that". Exploratory testing was nothing new at the company, great testers already used it in secrecy, they just couldn't solve the problems they had run into trying to fit it into our process (problems like knowing what they had covered and traceability). What they told me helped me realize problems I had to solve and raised questions I had to be comfortable answering as well as provide solutions to problems I already knew about.

Lesson: Discovering my behavioral warning signs was great
Today I know I'm in trouble when I for instance stop sharing things with others or when I start to give very many reasons (rather than a few very clear ones) to why we should do something. Both are signs I'm either off course or at least don't know what I'm doing good enough. The latter can sometimes be a necessary step but at least it's good to be aware. When I discover one of these signs I can immediately stop what I'm doing and start reflecting to ensure I'm not drifting off in a dangerous direction.

Lesson: Being the only judge is dangerous
In my team I was the only one with testing experience (until Saam joined). This led to the rest of the team trusting my judgement when it came to decisions concerning test (which is to some extent reasonable). As soon as Saam and I started to work together we began questioning each other's opinions, ideas and directions, helping us to stay on a healthy course.

Lesson: Reasons are not proof
I can provide reasons for pretty much everything (including why you should jump off a cliff) but that doesn't mean everything is right (including the part where you jump off a cliff). I argued for my decisions early on, providing tons of reasons, even though I was way off. Now I know better than to accept peoples reasons, instead I look for lack of real life experience, generalizations, false connections and other assumptions (including my own).

Lesson: It's important to have someone to discuss with

It's no coincidence everything started to improve when Saam and I started to work together. When I was alone (Saam came to similar conclusions) my creativity dropped, my willingness to stand up for the changes I wanted to perform decreased, my motivation dropped significantly, my feeling of trust in my results dropped, learning was not happening as rapidly and finally I got stuck a lot more often and for longer duration (even when Saam couldn't help me it started the process of involving someone who could cause obviously I wasn't stupid asking whatever question it was). Having someone to quickly turn to whenever I needed a second opinion or some quick guidance was key.

Lesson: Exploratory testing needs support from your process

I didn't understand how crippled my exploratory testing efforts would be by the not adapted surrounding test process (like test reporting, test strategy guidelines, traceability requirements etc.). For instance the test management tool everyone had to use had no support for rapidly changing test scope and qualitative progress reporting. To even give us a fair chance of succeeding we had to work that out first.

Considering what kind of environment we actually created, my advice would be to isolate yourself. So instead of trying to change the world around you (which many will object and in the end you will probably just be allowed to change half the stuff anyway severely crippling your chances of success) try to build a micro universe where as much as possible is adjusted to fit an exploratory approach without colliding with the outside world. In agile, having an independent team with tested code as the only demanded output and working in an isolated part of the product / team owned product, could be one way.


Lesson: Education can save time and improve quality of test

In the beginning the exploratory testing didn't work efficiently. One reason, I believe, was I didn't really incorporate learning. Instead of stopping my testing effort when I felt my knowledge was insufficient I continued just putting out each fire I ran into (learning the bare minimum to continue). This was sometimes the right decision but often not as it constantly interrupted my testing flow. As soon as I started to spend longer stretches educating myself in an area (not just to solve one single problem), I also started to get a better flow and I started to recognize valuable tests I had previously not seen.

Lesson: If you can't argue for something you don't understand it

I've found a lovely exercise I wish I had performed earlier. Before I suggest a change I run it in my head trying to defend it against all the critique I can imagine. If I find a question I can't answer I try to sort that out before I continue. Notice, that the answer is context dependent so you can't just "learn" answers, you have to go through this over and over (but after a few times the loop will be faster as long as the suggestion is not too complex).

Example:

- We should remove the storage of test cases
- But without storage we can't reuse them
- Have we ever done that? For instance, it takes more time finding an existing suitable test case than to write a new one?
- But we lose traceability
- We could store session debriefs or one liners of tests we've performed, it would be a lot cheaper. By the way, when do we need traceability on that scale?
- Well, what if a customer asks for exactly what we've tested... or our test manager?
- Has that ever happened? And is it really worth all this time and storage money just to achieve that?
- But what about new tester, where will they go to learn test
- Our test cases are used for this purpose only due to lack of something better. I think the teams can manage this a lot better with pair testing and internal competence boosts. Also the test scripts don't really explain why you should do certain things partly because people stop writing when it becomes to complex (easier to figure out as you go), so the competence value is minimal as it is today.
...

Wrap up
This is one of my proudest moments, most frustrating experiences, most motivating explorations and definitely one of my most educational adventures. The lessons listed is just a brief start, we learned so much and I still learn things from reading this now.

Finally, this blog post was almost entirely written in December last year. I can now see lacks in my understanding of exploratory testing and how colored I was from only have been working at the company described. That's a lesson in itself.

Thanks for reading!

25 September 2013

Transpection Tuesdays

A couple of weeks ago me and Helena Jeret Mäe sent a few cryptic tweets about "Transpection Tuesday". Since then Helena has written a great summary of our first session and to add to that here are my thoughts so far.

What is Transpection
The best explanations I've found are James Bach's explanation of transpection and Michael Bolton's transcript of a transpection session. But basically it's one person asking questions to another person with the twist that the one asking has already tried to answer those questions. The result is you get two sets of answers, hopefully less biased from each other.

What is Transpection Tuesday
When I first met Helena it was during Let's Test earlier this year. She had tried to grab me a few times but sessions and other conversations had interrupted us. So suddenly during lunch she stood up and said: "You sit here!", and pointed at the chair in front of her. And so I did, which was one of the smarter decisions I've taken as a tester.

Transpection Tuesday happened in a somewhat similar fashion:

Helena: Hey. I was thinking this morning that we could have Transpection Tuesdays (because it rhymes :P) or something. if there's something each of us is trying to work through and solve, then we could try this transpection thing out. It's a bit random thought
Erik: Sounds cool... I'll take care of the kids alone tonight since my fiancé is working so suits me perfect... with the possible problem that a kid wakes up and I have to leave very suddenly and might not come back .)
Helena: I understand that and won't hold a grudge :P
Erik: In that case I'm in! Usually kids are asleep after 19:30 CET, hopefully there's no change tonight

So after some technical difficulties we started a Skype call with video. By the way, video was awesome for this since it made sharing visualization easier, body language is useful when trying to explain something and it helped, at least me, stay focused.

So to summarize:
Transpection Tuesday is simply a Skype session ~3 hours long, happening every Tuesday evening between me and Helena, dedicated to talk about testing.

Confession
Okey, so what we've done so far has been far from just transpection. Instead it has more been like a weekly dose of conferring where we discuss topics that matters to us in various forms; where form depends on mood and topic. You could argue the name thus is misleading, and it probably is... But we like it.

What did we discuss?
Helena shared our combined notes, from the first session. I won't write anything detailed about it now but if something in those notes seems interesting, feel free to leave a comment and I can try to write a future blog post about it (my guess is some of the more "community challenging" stuff would fit that criteria).

How did we discuss?
I recognized five different "styles"/formats used during our talks, plus one suggested that we haven't tried yet:
  1. Transpection
    I tried this briefly when speaking about why/if we should send people to courses and Helena did it much more extensively during the last TT when speaking about bias. When talking about these topics one of us asked questions we already had answers to but felt we wanted to improve/challenge. What makes this powerful is the person answering last get slightly less biased since he/she hasn't heard the first person's answers which gives you interesting answers to compare.

  2. Conferring
    Most of the talking was just quick questions being thrown out and then we together tried to answer and discuss them. I would say this is the style we use most (it's like our "go to" style) and for those of you who've been to Let's Test or CAST, this is very similar to the discussions you typically end up in during lunches (which is a good thing!).

  3. Challenging
    I plan to do a lot more of this going forward because it felt like an awesome way to learn. Essentially it's one of us asking the other to clarify something to a great level of detail or challenge a claim being made (similar to what happens during RST for instance). Very powerful as assumptions were uncovered and you constantly had to be on your toes.

  4. Role play
    We take opposite roles (e.g. the manager who questions the professionalism in ET versus a context driven tester considering ET a good approach in the current context) and simply fight it off with the goal to pressure each other to explain/motivate something at a deep level, as well as highlight assumptions. We have actually done this very briefly but I don't think enough to really call it role play, more quick imitations and reactions to that.

  5. Transfer
    Simply one of us telling the other something without any questioning going on; so basically a monologue about a topic. What was interesting to me was the information I received this way really seemed valuable but missing the interactive aspect hampered my ability to connect it to something else/make "lasting connections". Also I often felt the energy was lost a bit when one of us talk for long stretches.

  6. Interview
    Similar to Transfer but more driven by questions so basically the receiver "choosing" what information he/she is interested in. Better than the monologue version but still a lot less valuable than any of the more interactive ways. It was like, even with questions, I didn't get my brain into gears, so new information simply didn't stick as it was when e.g. Conferring.
Improvements
Here are a few things I've noticed:
  • Having a clear topic helps as we got fewer side tracks and thus easier could focus on going deep into the current topic. Side tracks are not evil per se, but too many and too big ones seem to make discussions rather shallow (my feeling so far).
  • Having prepared followup questions would had been helpful, we have improved this for next week, will be interesting to see the result.
  • We did get deeper into the topic during our third TT as we pressured each others to better explain what we meant and why even when agreeing. Think we can do this to much greater level though.
  • I need to try to quickly structure the information in my head, before starting long rants/monologues about something.
  • I think both of us could benefit from monitoring our own speaking trying to stop ourselves during long monologues. It's much harder for the other person to recognize a good break point.
Wrap up
So, Transpection Tuesdays are not so much about transpection but rather about weekly conferring. I already look forward to next week (preliminary topic: "Arguing for Exploratory Testing") and that's a great sign. I hope this turns into a long lasting tradition and it will definitely be the foundation for many future blog posts!

03 September 2013

My CAST presentation


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

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


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

Another kind of feedback was the recording. Listening to that helped me realize:
  • It took me a while to get the energy going
  • I had some annoying "ehh" and "and" early on
  • My flow was really nice
  • I should not interrupt the facilitator
  • I've always been a bit annoyed with how my voice sounds but listening to the recording has helped me appreciate it instead.
  • I felt several pauses was just a fraction too short (for me)
  • Well rehearsed parts did not sound "flat" or "boring", rather the opposite, so I'm very much questioning if I can "rehears too much" which some people warned me about before.
  • 26:13 (masochist "joke")... WTF! Still hurts to hear myself say... whatever I tried to say .)
  • I felt my energy raised every time I made some kind of imitation (THANK YOU HELENA)
  • The tempo was nice, could have varied it a bit more for greater effect but better than I expected
  • I hardly rambled / repeated myself at all... once again I think rehearsals played a key role.
Forgotten part
Remember how I added balance in my 10 second summary of Yes Man (31:10 in the video)? Last winter I realized I couldn't just answer yes to everything. Sure cool things happened but that required me to spend quite a bit of time away from my family. That, after a while, became too much time away. So family has turned out to be something I need to think about before answering yes to too many cool things. Your balance might be something else like time with friends, time to sleep, travel costs, mental energy etc. No matter what it is, keep it in mind.

But that small addition was all I missed! Hurray!

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

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

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

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

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

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

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

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

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

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

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

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

Additional credits

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

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

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

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

02 September 2013

My success story, a story about failures

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

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

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

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

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

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

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

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

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

Messing up a play
  • I need to sometimes stop myself and simply shut up.
  • I need to think about what's interesting to the listener, not just what I want to say.
  • Being well prepared (rehears) is key!
My first presentation
  • I can actually present.
  • I don't need a script.
  • Even the worst case scenario wasn't that bad (you could argue that passing out is worse than not being able to say a word but they're pretty close).
  • There are things I can't seem to learn/fully understand without actually failing first.
  • There's no such thing as a failure or success, we always fail to some degree and we miss out on a lot of potential success if we don't take the opportunity to learn from these small or big failures.
  • As long as I rehears, things seem to work out okay no matter what.
At the university
  • Silence is actually not that bad.
  • Less is more, I forgot a lot of the prepared material but in the end that seemed to make what I said, stick better (based on reactions from students after the presentation).
  • You can turn a bad start or problematic presentation into something great, it's never too late. This one actually turned out as one of my better presentations as an ambassador.
Improving legacy code
  • Doctors didn't find any problems with my heart, lungs or head (obviously physical health was enough). That's actually quite comforting.
  • Due to all the medical tests I had to leave a whole bunch of blood samples which eased my fear of needles and hospitals.
  • ... and that taught me a valuable lesson about fear: Fear is much about not knowing the outcome, not about the experience itself. Understand that and a whole lot of things stops being scary (very, very powerful insight).
  • I know my limitations better.
  • I know when to say no better.
  • I know the possible consequences which further helps me say no when I really should.
  • I've learned the value of understanding the content I'm about to present.
  • I need to rehears.
  • I need to rehears.
  • I need to rehears.
  • I've learned code quality is much more complex than I once thought it was.
CAST warmup
  • I need to rehears
  • I need to rehears
  • I need to rehears
  • Open season with K-cards is actually not that scary (I had not tried that as a speaker before)
  • Beer solves a lot of problems... kinda.

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

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

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

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

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

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

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

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