An extensive list of what helped me present

Dealing with anxiety

• Rehearse, rehearse, rehearse... rehearse. I thought rehearsing too much would make my presentation sound like a "script" but I was wrong. The parts I had rehearsed the most (and I rehearsed a lot) was probably the ones I delivered the best. The reason, I think, was I could relax and only focus on delivery.
• I skipped the session before mine and instead went to my room and gave the presentation to the bed, chairs and curtains (in other words, no crowd). That really helped me relax. Also I noticed in my recorded rehearseals that when I gave the presentation a few times in a row, the first time was usually the worst. So I figured rehearsing once right before the actual presentation would make the actual one better and I think it did. If I interpreted Clair Moss, who delivered a kick ass presentation as well, correctly, she seemed to have had a similar strategy.
• It may sound weird/impossible but I decided it wasn't that big of a deal to present at CAST. I think this was simply a matter of convincing myself by repeating the idea over and over again. When I was actually there it seemed to work cause I stayed a lot calmer than expected and never really felt that "this is insane" feeling.
• I found it important to remind myself I presented to impress myself, nobody else. That made the whole thing a little less stressful as worst case suddenly became me being disappointed in myself rather than half the testing world being disappointed in me.
• Smile! It's weird but it really eases stress (for me)!
• I found there is a huge mental difference between "I'm scared and nervous, but I can do this" and I'm scared and nervous, I don't want to do this". Once again, repeat to yourself until it sticks.
• What if I lose track? Once again: rehearse and it gets less and less common! Rehearsing also helps in case you actually do lose track as you can much easier find your way back (losing track is not necessarily a bad thing by the way).
• Being a presenter is a possibility and only a possibility. I strongly believe (don't correct me, it would make me a lot more nervous .) people rarely remember a bad presentation but good ones stick. As a presenter those remembered presentations open doors, lead to insights (and good in that sense could mean an utterly failed presentation you learned a lot from), help you connect with people and raise your confidence. Bad ones are forgotten by everyone else so learn from those presentations (make them good) or forget them like everyone else.
• I try to always get to the location where I'm about to speak before my audience. For me it's a mental thing; if I'm there first it feels like they enter my turf, if I'm not it feels like I'm on someone else's and the former just makes me less nervous.

Dealing with being "in shape"

• Eat, drink (water!) and sleep. Sounds simple but easy to miss, especially when you're getting nervous.
• Beware of jet lag, try to get there a few days early to adjust.

Dealing with language
I'm not a native English speaker so I had an additional challenge.

• For every day spent in the US my English got better and better. So arriving a few days before the conference was a great.
• Rehearse, rehearse, rehearse!
• I found it much easier to spot weird things I said when listening to them in retrospect, so recording my rehearseals really helped improving my language. I didn't ask any native English speaker to listen to my recordings and comment on typical linguistic errors I make, but that could had been useful.

Dealing with creating the content

• I took on a way too big topic in the first draft of my CAST abstract, the one I finally sent in was focusing on only one of seven parts described in the first draft and still I had to shred a lot of content and could even had focused the entire presentation on one of the four parts I talked about. So beware of too broad topics!
• Peers are invaluable! Having someone reviewing my slides, content and even a rehearseal was key. The feedback I got from Helena was invaluable! And without Maria's feedback when preparing my abstract, I can't imagine I would had been selected to talk!
• Questions I asked too late that forced me to basically rethink my whole presentation was: What's in it for the people attending? Why should they be there? What do I want them to remember? What do I want them to feel? How can I make that happen? Before I asked those questions the presentation was fairly focused on me and what I thought was interesting not what I thought would be valuable to someone else.
• Rehearse! It's the only way to see if the amount of content fits the time given.
• Keep adding content all the time! It's much easier to shred or compress content to fit a time slot than to fill gaps.
• Not allowing my ego to take content decisions helped me a lot. People don't care much about how great I am but they seem very curious about my mistakes, embarrassments and problems.
• My topic was sort of an experience report. The great thing about experience reports is you're sitting on all the facts and information. That also fights anxiety as "I know what I experienced and if your experience differs we can discuss it but mine is still valid (just like yours)" thus, you're always right as long as you stay truthful about what you experienced.

Dealing with delivery

• Rehearse, rehearse, rehearse!
• I recorded myself rehearsing and when I listened to the recording for the first time it just blow my mind! I thought I was varying my tempo and volume as I was presenting but realized ... I wasn't. My voice was monotone, I sounded uninterested and pauses were non-existent. Next time I will record video as well. (didn't video record any rehearseal this time, simply due to discomfort and laziness). If you feel like recording yourself is complicated, think again! I used basically the first free app I found for my smartphone and it worked beautifully!
• I forced myself to try very long pauses just to see the effect. That helped me realize the power of pauses (even though I felt I forgot that a little bit during my actual presentation). And the power? Personally I feel a well timed pause can help attendees digest my information and be ready for more and no pauses is a bit like reading a text with no space between paragraphs; it's exhausting and you lose some valuable structure.
• Listening to myself also helped me identify where I tended to ramble.
• I have three kids. As a way to prepare myself I read or made up stories for them and tried to tell them with as much energy as possible. Good way to practice storytelling.
• Actively using my body (using my arms to express something, move around, shrug, express what I'm saying with my face etc.) helped me "get excited"/get in my presenter mode.
• During rehearseals I sometimes found myself speaking faster and faster. The most efficient way I found to battle this was to just stop, make a long pause and kind of "reboot".
• As I rehearsed, I experimented with different ways of describing things, change order and vary the tempo. For me that led to some interesting insights, mostly related to pauses (already mentioned) but also how I could add energy to certain parts by raising the tempo/volume or better emphasize certain parts by saying keywords slower and and with a different volume (sometimes louder, sometimes softer, depending on context).

Dealing with remembering the content

• Rehearse, rehearse, rehearse, rehearse, rehearse, rehearse!
• Rehearse without slides
• Rehearse without any other tools (private notes etc.)

Dealing with making people come
I'm not much of a marketing person but...

• I wrote a couple of blog posts about the presentation. [1, 2]
• I spook with people at the conference.
• I spoke a bit about it on Twitter before
• I didn't do like Huib Schoots but god I wish I had! [1, 2]

Dealing with technology

• Rehearsing without the slides a lot helped me prepare in case the technology would fail me. Also I think doing this helped me to, with slides, look less at the slides while presenting.
• I booked a conference room for 1 hour every morning during the last 2 weeks before the conference. Being able to present with all the technology in action really helped, for instance I realized my computer was not well configured for attaching an external monitor. Also I got to test switching slides using my wireless mouse which took a little practice to get right (damn you scrolling wheel!).
• Triple check technology... and then check it once again.
• Oh, and US don't have European power sockets, luckily I thought of that.

Some CAST (CAST-like conferences) specific insights

• Everyone is there to learn so everyone wants you to succeed! May sound a bit strange but I've rarely felt more support as a presenter than I felt during CAST.
• K-cards may seem like a scary thing but in reality they are a great tool for me as a presenter to get valuable feedback and learn. Realizing that made them a lot less scary. The open season helped me understand if people liked the material, what parts seemed more interesting, things I might need to tweak/think more about, I got new ideas on how to improve the content etc. That gave me comfort!

My Top 3

1. REHEARSE! Thank god I spent so much time doing that!
2. Record yourself and analyze the content.
3. Presenting is an opportunity/privilege, not a punishment (usually), so don't make it so!

Last word

I wrote this post just under a year ago, on my way back from CAST. But I never published it as it seemed kind of silly for a first time conference speaker to share advice on how to prep an awesome conference talk. A few weeks ago I picked it up again and since it still made a lot of sense I decided to share it.

However, I would love comments from both experienced and inexperienced speakers on what I got wrong (in your opinion) or maybe even right (in your opinion), just to improve both this post and my own ability as a speaker.

Take care!

Peers

What is a peer
Definition:
A person of the same age, status, or ability as another specified person
(The Oxford Dictionaries)

The kind of peer I will be speaking about is other people within the testing community striving for excellence in a similar fashion as I do and preferably on a somewhat similar level even though that's hard to compare.

We love to team up
Everywhere in life we team up. We get partners to share our everyday life with, we get friends to whom we share similar stuff, we get other friends to share more specific things with such as a hobby, we get close colleagues to discuss work with and so forth. All these people help us as advisers, complement our skills, support when things are shitty, support when we need to challenge ourselves, idea generators, inspiration and many other things, in their respective areas.

A peer in testing to me is the same thing but from a general career/tester perspective. They add an external perspective (or at least second when they happen to also be close colleagues), they help me develop, they help me challenge myself, they help me solve problems I have that require testing or test related knowledge and they can help me when I want to/have to change job.

Does this sound a bit abstract? Let's get more specific!

Help solving a (testing) problem
A question that has been nagging me for a while now is: "What is my role?" or rather "What do I think my role should be?". The problem is I don't really know and I feel I'm stuck when it comes to figuring it out. During Let's Test recently, among many things, I had a 2 hour discussion with Anna Royzman and Andrii about the changing role for testers. It was a great discussion where both I and Andrii had similar questions and together we came to insights like "everyone comes with their own unique mix of skills/experience/knowledge and we have to be careful not limiting our potential and usefulness to the role's description, people's general expectations of us or the role we once had/the person we're replacing". That's one example of how peers (Anna and Andrii) helped me get a better understanding of/solve a test related problem.

Challenge to improve
I'll save my self some work by just pointing at my story of how I became a speaker at CAST. It perfectly illustrates how a peer (Maria Kedemo) challenged me to do something outside my comfort zone in order to help me improve.

Outside perspective
I use my super peer (Helena Jeret-Mäe) for this all the time and even have a name for the quick, very context specific, questions I ask her: Sanity checks. "Is what we're doing, that I feel is wrong/strange, really wrong/strange in your eyes?". If it is, it tells me I'm at least not the only one feeling that way and if not I might get an explanation I've simply missed. An example would be the deployment strategies used in another peer's company and he often asks me: "Is this actually how software is built?". I do my best to explain how we work and/or simply say "no, I've seen... instead and it seems to work better at least in their context", too often though I just answer "unfortunately yes".

Generate ideas
It's easy to get stuck, either if it's when I'm testing, in my career or in some other aspect of my "professional life". This is once again something I constantly do with Helena: "I feel like my only options are..." and she replies "but what about...". Practical example: "I feel like my role is somewhat limited to...", "Have you tried speaking to your boss? To the developers?...". And those, seemingly obvious, answers just didn't occur to me in the middle of my "this shit is broken" kind of mindset.

Practice
A recent example is Software Testing World Cup, which I participated in with a couple of other peers. Another one is practical exercises we've tried in my local test community (EAST), one being us splitting up in teams and attempting to use various thinking hats while testing. And finally a third one is any workshop at a conference where you interact with other testers to figure something out together, sometimes by simulating something which is more or less impossible to do on your own.

Support
Sometimes you just need some cheering or a hug when things don't go your way. And getting that from someone who does understand your headache is very much appreciated, at least for me. Also, something Helena (once again) and I do a lot: Remind each other of how incredibly much we've improved/accomplished, which is easy to forget.

Coaching and Teaching
During a recent Peer Conference (more about those in a moment), James Bach explained his coaching model, which added a whole new dimension to the visual representation I had already seen. That's one example of how a peer explained to me his view/experience/knowledge on a topic. Also any (peer) conference talk is one tester teaching others, often followed up by an open season where "everyone can teach everyone on the topic including teaching the teacher". Finally Helena and I do a lot of coaching as part of our weekly sessions.

Second opinion
Before Let's Test I recorded what I wanted to present as a lightning talk. I sent the video to Helena and her answer was something like "that should be a lightning talk, it doesn't work as good as a video". In retrospect I definitely agree but in that moment it felt like I had to release it, simply because I had spent a lot of time recording it. Thanks to Helena, I didn't.

"Am I stupid" -check
This goes for closer peers, either as in geographically close (sitting next to you) or personally close as in someone you trust very much; preferably both of course. Sometimes I have an idea or question that just seems stupidly obvious. If I have a close peer I can quickly ask that person and (s)he either provides an answer or a "well I don't know either so I don't think it's too obvious". If I don't have that person to quickly ask, I easily go into wasting time waiting simply to either get brave or frustrated enough to ask or to slowly figure out the answer myself.

One practical example was a specific way to trigger a kind of failover in the product I was testing. I almost felt stupid asking if there was another way to trigger the failover. My close colleague (Saam Eriksson) next to me answered "I'm not sure but could be..." and after we consulted the expert it turned out there was a way that had basically never been tested. Without Saam I might had accepted that there probably was only one way to trigger the failover and the "other way" would not had been discovered for another ten years or so.

Fuel the fire
I quickly lose interest in things (my fiancé just nods right now, looking at me like "have you finally realized that"). Having peers who constantly push me, help me find the necessary spark when my motivation is low and inspire me by showing what's possible to accomplish, helps me stay motivated and curious. Also doing things with others (for me) is much more rewarding than doing them alone, so peers help me have fun.

Inspire
Related to that: when I heard Helena would help out planning a test conference it suddenly struck me "maybe I can do that to?", when I watched Alan Richardson's technical web testing webinar/course I suddenly thought "maybe I could record something like that" and the list goes on. There's an unlimited amount of possibilities but sometimes you need a confirmation something is possible/available and the combined ingenuity/bravery of peers often provide that inspiration/confirmation.

Job
There's a lot to say about jobs and peers. Some quick benefits I've experienced myself

1. Peer review of CV/portfolio stuff
2. Actual job offers, either from the peer or recommended by the peer
3. Help choosing between job offers
4. Recommendations

I've reviewed several CVs, mostly non-testers but I still add it here since knowing the context definitely helps. I've also had peers review my own CV.

My current job was an offer I received from Maria Kedemo and I've also turned down two other interesting offers received from peers... and, well, let's not get ahead of myself.

Also when I got the job I have now I had a hard time deciding between that job and another job. Luckily I know a person who happened to had been working for both companies. He could provide me with tons of valuable info helping me decide.

I've helped peers recruit as well as get recruited, by spreading job ads or recommend specific testers I know for specific jobs.

Finally, I've put in a good word for several testers (and programmers) where I've known the recruiter.

Peer conferences
Peer conferences are not for everyone as you're expected to contribute (present an experience report, speak up, share knowledge/experience) as well as be ready to get challenged on whatever you say. If you feel you're up for the challenge the reward is huge though (lessons, inspiration, network and new practical things to try)!

Being alone in your company/team
I'm the only tester in my "part of the company" (the company is basically split in two). In this situation I've found various testers (peers) outside my company to be invaluable as they help me "stay sane" and not get stuck on seemingly simple matters. My experience from being the only tester in the company, the only tester in my team, one of several testers in a mixed team and being in a pure testing team, is that if you're alone, find someone to share your tester burden with, otherwise it'll grow! Even though this person might not know your context that well, he or she can provide an invaluable second opinion or help you solve problems when stuck, especially when stuck on "simple things you 'should' know and feel embarrassed to ask just anyone about" (I envy you if you've never felt like that).

Super-peer
I call Helena Jeret-Mäe my super-peer. The difference is she knows so much more about me (as in my personality, private life, aspirations, weaknesses, everyday work headaches etc.). This saves a lot of time when explaining a problem and she can see connections between for instance my personality and certain problems, I'm not aware of myself. Most importantly though: We've built a deep trust in each other. She can question things I really don't want questioned and I will listen (things like not prioritizing family as much as I should) as well as push me much further as she knows my limits sometimes better than I do myself and vice versa of course.

Can't you do this on your own
You can do most of this on your own but much of it will be harder and/or take longer time and/or not be as fun. Since I reached out to the testing community my level as a tester has skyrocketed!

How to find peers?
Getting to know other testers seems fine and dandy but where do you start?

Twitter
Some tester once said to me, about testers, "if you're not on Twitter you don't exist". Even though that's to exaggerate it's still true you'll find most renown testers on Twitter and it's an amazing way to make that first contact. For instance, when I went to my first big test conference, I could immediately start talking to a ton of people thanks to Twitter and the conversations there. A good thing with Twitter: Everyone is entitled to add to a conversation so there's no initiation ritual, instead you listen in och when you feel you have something to say you join a conversation and voí la, followers will come (if you're nice and/or smart) and relationships will form.

(Peer) Conferences and courses
Peer conferences usually have fewer, and likely more dedicated, participants. They don't last for many days but the bonds created are, in my experience, very strong.

A larger test conference is perfect to get in touch with many new testers and broaden your network.

Courses are a bit like peer conferences in the sense that you can easily become very close to some testers in a relatively short amount of time.

If you need suggestions for (peer) conferences and courses, contact me (some info at the end).

LinkedIn
I mostly use LinkedIn to connect to my local test group after I learned about them but can work to find new testers to hang out with as well. Not, to me, as obvious to make useful though, as Twitter.

Meetups
If there is no local test meetups in your area, visit a bigger town to join one or start your very own local test community. If you need some inspiration: Check out Erik Davis' excellent post!

Blogs
Starting a blog about testing is good for many things (reflection, portfolio, getting feedback etc.) and one of them is, a good blog generates interest in you. Also reading other testers' blogs and leaving (sensible) comments on these will teach you things as well as help you connect with these people.

Software Testing Club
I don't use this community very much for some reason but every time I do I get impressed. Seems to be a great way to connect so try it out for yourself!

Colleagues
Why look far away when you've curious testers next to you? Suggest an educational activity like spending an hour watching some great testing presentation (need suggestions? just ask me!) and discuss the contents together. Who knows, maybe you'll find a colleague to keep learning with.

Summary
Don't isolate yourself, or other testers if you're in a test lead/manager position! Instead, try to reach out, ask for help, provide help, share ideas, socialize, listen, speak up and network. The field we work in is way too vast to be covered by one person alone. Team up and you'll be much more efficient... as well as have much more fun.

If you are, or feel, completely new, ask for a mentor (I can either help directly or hopefully get you in contact with someone who can help). If you know your way around but have done things in solitude so far, go to a test conference, start a blog, join Twitter or go to/start a (local) meetup for testers. Still feel stuck? Contact me! (use this blog, Twitter, LinkedIn or any other way you find... except tapping on my window in the middle of the night as it would probably freak me out).

Good luck!

Software Testing World Cup, Test report

Credit
This is based on my team's effort in the European qualifying round for STWC (Software Testing World Cup). The team consisted of Agnetha Bennstam, Sofia Brusberg and me. Everything mentioned in this post is my interpretation of our collective work.

What is the Software Testing World Cup?
STWC is exactly what it sounds like: Testers from all over the world competing in software testing. You can read about it on the STWC web site but here's the bare minimum you need to understand this post:

To get to the finals you have to win a qualifying round. Typically there's one qualifying round per continent with a maximum of 250 teams each round and 1-4 testers per team. A round is 3 hours long during which the contestants test an application, revealed just before the round starts. Throughout the competition teams can ask questions to the application's product owner who answers these in a live video channel available to everyone. To get a better idea of how this works Matt Heusser have shared recordings of the video feeds. At the end teams are scored mainly based on a test report and the bugs they've filed.

Intro
To make any sense of this post you first need to check out our test report from STWC (in case worried; I've checked with the STWC judges it's okey to share our report).

My hope is this report can help spark some new ideas for other testers as well as, despite being written under severe time pressure, work as an example of how a test report can look.

Overview
Our test report is made up of six sections; Coverage, Bugs, Other risks, Suggestions, Conclusions and Strategy. Generally I think the report turned out pretty well; it's concise (not counting the coverage section), covers what the stakeholder asked for (including improvements) and communicates what we discovered. With that said there is definitely room for improvement...

Coverage
"What did we actually test?"

The reason for this section is bugs, risks and suggestions don't say much about what we actually tested, just where we happen to find notable stuff. Coverage is there to ensure further testing is focused on risky and/or not yet tested areas.

Given the limited time I think we did a decent job with the coverage section. Some of the categories are too broad and/or ambiguous (e.g. Search), thus making it easy to mistake testing from being performed when actually not. Also I think we should had communicated the coverage in a more concise way.

With more time to spend and better understanding of the product I would have liked to add a visual map of the coverage as an overview. Right now I think it's bits and pieces, missing the big picture.

Another way to improve this section would be to give a quick estimate on how confident we are in the respective areas as a way to show how confident we are in these areas. In our report there's no difference between "we made a quick test in this area" and "we spent a lot of time and effort testing this area", which hurts the section's usefulness.

Bugs
"How bad is it? Any reason to fear the product will explode in the customers' face?"

Lesson learned: Add a more business friendly description to bug reports and describe the business impact when actually reporting the bug! This time we didn't and thus had to quickly translate bug descriptions while writing the report. The result is not very impressive unfortunately. But I did learn something and, from what we discovered, I think the right bugs are listed.

Other risks
"Apart from severe bugs, what else did we observe/not observe that might affect release readiness?"

I like what we added to other risks, possibly with the exception of the potential availability issue described. I think that one was added because one of us pointed it out during the stressful last minutes, so we added it without really questioning if it was relevant. Compared to several reported bugs, not mentioned, and based on our interpretation of target audience it should probably had been reported as a minor (or rather potential) bug, not be part of the test report. But once again, overall I think this one did turn out nicely.

Suggestions
"Potential future improvements we discovered"

One of my favorite sections in the report. Could had been somewhat more detailed but to the point, relevant and what the stakeholder specifically asked for. I tend to always note down suggestions for improvements but adding them to the test report (I think) was a first to me. Will definitely consider adding a suggestions/improvements part to future test reports!

Conclusion
"Taking risks into consideration, what's our recommendation going forward?"

From a formatting perspective it's bad to let the page break in the middle of a section. Also I love the "edit Account editing" (time to proof read the report? obviously not enough). But, looking at the conclusion, I still find it relevant and correct even with some time to reflect. Another thing I like is it doesn't only present the stakeholder with one option, instead it embraces the fact we (testers) don't know the market and thus provides information relevant both for a "regular case" and a "we must release now" case.

Strategy
"What resources did we have at our disposal, what limitations did we have to adjust to and what ideas guided our testing?"

Since this report was given to an external customer we figured a rough plan might help their internal test team even though of course highly context dependent.

If you compare the time plan with my previous blog post you can see we didn't use the last hour to update it. I think it's close enough since we didn't diverge too much and updating the image would not had been a good way of spending our last precious minutes, however, a quick note on how we diverged from the plan, I think, would had been helpful/useful information. Also we wrote it on the form "we did", not "we plan to", which is simply wrong. Apart from that, nothing spectacular but hopefully somewhat meaningful.

Coloring
The header colors is there to make the report easier to overview. Apart from the red one for bugs and other risks they aren't very "self explanatory" but I do think they help the reader to find the information (s)he's looking for, especially when looking at the report a second or third time. One thing to improve is to make conclusion stand out more as I imagine a stressed reader would like to find this immediately. A different choice of, or way of using, colors might be a way.

Overall
I think we got the overall layout and categories right, I think most of the content was relevant and, after all, we only had 3 hours to finish planning, testing and reporting! For a 3 hour competition I think it's a well written report despite its shortcoming, which I hope I've highlighted well enough in this post.

To all the other STWC contestants; I would love to hear what you did different in your reports and how that turned out, eager to learn from it!

Finally: Thank you Agnetha and Sofia!

Lessons

• Colors are great to add visual structure and make the report easier to skim/overview
• Proof read more than once, stupid linguistic and grammatical errors hurt the report's credibility
• Think about the actual business impact/description already when writing bug reports
• It's hard to describe, especially in a concise way, what was tested and what was not
• Don't write things on beforehand guessing how something will turn out, in that case, describe it as a plan
• Improvements (what we called "suggestions") can definitely have its place in a test report
• Don't wait with the report until the end, try to create as much as possible in parallel with the actual testing and planning

Software Testing World Cup, Time management

Credit
This is based on my team's effort in the European qualifying round for STWC (Software Testing World Cup). The team consisted of Agnetha Bennstam, Sofia Brusberg and me. Everything mentioned in this post is my memory/interpretation of our collective work.

What is the Software Testing World Cup?
STWC is exactly what it sounds like: Testers from all over the world competing in software testing. You can read about it on the STWC web site but here's the bare minimum you need to understand this post:

To get to the finals you have to win a qualifying round. Typically there's one qualifying round per continent with a maximum of 250 teams each round and 1-4 testers per team. A round is 3 hours long during which the contestants test an application, revealed just before the round starts. Throughout the competition teams can ask questions to the application's product owner who answers these in a live video channel available to everyone. To get a better idea of how this works Matt Heusser have shared recordings of the video feeds. At the end teams are scored mainly based on a test report and the bugs they've filed.

The plan
We had a beautiful plan starting the competition:

Personally I have a history of not following plans so I was surprised when we actually executed pretty much according to it (I give Sofia and Agnetha full credit for this). Here is an adjusted, and somewhat extended, version of what actually happened:

First 55 minutes

After some minor technical issues with the YouTube channel we were up and running. While Agnetha and I mainly focused on the stakeholder's live video channel, Sofia started touring the application. We kept going like this gradually focusing less and less on the video until Agnetha mentioned we should stop and debrief what we had learned so far as well as discuss test strategy and possibly adjust the time plan. I would say Agnetha was our time keeper for most of the competition.

During the debrief/strategy discussion we identified 3 main areas to focus our testing on, based on the stakeholders' requests:

• Email functionality
• Screen resolutions (mobile devices)
• Possibility to steal accounts (customers)

To make it easy we focused on one area each. As security is one of my better areas I went with the account task, Sofia had already started looking into the emailing functionality so she continued while Agnetha started playing around with the mobile devices we had/various resolution.

Whiteboard from the competition

Exploring and debriefing

For the next 65 minutes we tested the product and had a debrief after 30 and 50 minutes. When we stopped for the first debrief (once again thanks to Agnetha) we realized all of us were testing user settings even though this was only part of Agnetha's "scope". To some degree this was good because the user settings functionality was rather buggy, but at the same time the bugs we found weren't generally that severe and once again, this was not communicated as a high priority from the stakeholders. So after the first debrief I think we got on track. During the second debrief everyone seemed to be in the zone. We kept this debrief short, just briefly summarizing the more severe bugs we had found, what we were currently looking at and if we needed any help, to make sure the flow wasn't lost.

One big difference between our plan and what actually happened: We didn't pair test nearly as much as we thought we would. I think this was a good decision, it was simply too much to cover in too little time so we had to spread out our resources.

Wrap up

In the initial plan we thought 30 minutes would be enough to finalize the report, review bug reports etc. Luckily I was a bit nervous about the report (my focus area) and suggested we should start with just under an hour left. After all, we could always keep testing after the report was done.

Let's just say there was no time after the report! I reviewed my bug reports and realized some things were not clear or I realized I had forgot to add something, I added things to the test report and often questioned "do we really know that or are we just assuming/remembering it wrong" which required further investigations and so on. We also had to rewrite some bug descriptions to be more business oriented rather than technical. All and all, the last hour went by quickly.

Conclusion

Thanks to Richard Robinson inviting me to a 3 hour test session during Let's Test 2013, I had an idea of how short 3 hours actually is. Still... 3 hours is not much time! I'm glad we did a time plan before the competition and reviewed it during the competition. Without it I think the limited time would had hurt us much more!

... and it was fun to actually follow a plan, I might try that again in a few years .)

Finally: Thank you Agnetha and Sofia!

Lessons

• Writing a good bug report takes a lot of time
• Taking notes is crucial, we could had saved a lot of time when writing the test report with better notes
• 3 hours is not much time
• A (good) plan helps a lot when under pressure
• Debriefs are valuable to continuously set/correct direction
• Even when alone you can benefit from stopping regularly to review what you're doing
• Visualizing (like a schedule or the image in this blog post) a plan helps as it makes it easier to relate to (at least for me). I think splitting it up in a way where the size of each activity is relative to it's length would had improved our visualization.