Digital K-Cards

The page is taken down since I felt I didn't need a web server anymore.

If you want the code, drop a comment or contact me via Twitter / LinkedIn.

A few days ago I was still in the Alps with my colleagues at House of Test, mixing some recreation time with test discussions. During one of these discussions we had a lot of parallel tracks going on and the immediate question when people raised their hand was "is this on the current thread or is it a new one?" which took a lot of focus away from the topic. Some of us started improvising K-Cards. I used a background color app which cycled through a dozen different colors, Carsten had something similar and Ilari used two different glasses of beer.

After this discussion me and Lars Sjödahl joked about creating a K-Card app. A few hours of programming later and the K-Card "app" was born (click anywhere on the card to change color):
K-Card example: http://brickarp.se/kcard/index.htm?text=5&image=http://brickarp.se/kcard/hot.png
K-Card information: http://brickarp.se/kcard/info.htm
K-Card setup form: http://brickarp.se/kcard/setup.htm
K-Card generator: http://brickarp.se/kcard/get_card.php

Main features:

• Turns your phone (or similar) into a fullscreen K-card.
• Card number, logo on the card and whether or not to include the rat hole card can be customised.
• Can be used offline (no server components for the actual card).
• A card generator created for e.g. conferences helps provide unique card numbers for all attendees.

If you have suggestions, questions or find bugs, leave a comment or contact me in any other way you prefer.

Finally: Thank you Andreas Cederholm, for spending a few moments to test the app!
Notice though: It's probably still quite buggy due to several changes after Andreas tested it.

Enjoy!

Testing Education: Curriculum

I promised a long time ago I would write about each of the subjects in the testing education in detail. I've learned that's not as straight forward as I thought. I need to be careful about what I say/imply about the students, course content, exercises etc. (law, policies, respect for the school (content ownership) etc.).

Due to that I lost the energy to do the detailed posts. But, since I receive a lot of questions about curriculum, here's a post describing the curriculum on a more general level. The subjects below are arranged in the same order as they are taught to the students but the items in each of the bullet lists are not sorted in any particular way. Also the lists are not complete in any way, they're basically what I find noteworthy among all the big and small things brought up. Finally from test design and forward it's not as detailed since those subjects haven't been finished/started yet.

Introduction to testing (4 weeks)

• What is testing and why do we test software?
• Note taking and Visualization (mainly mind maps)
• Heuristics
• Basic test design
• Risk
• Oracles
• Coverage
• Bugs and bug reports
• When are you done?
• Tools (e.g. Sikuli, Selenium, VirtualBox, Apache and jMeter)

We started this course by; first thing, first day; give the students a flash game to test, a basic testing mission and a bare minimum of introduction to get started, just to let them get a minimal practical idea of what testing is. The rest of this course was a combination of theory and practical testing; sometimes we started with letting them test and then explained some concept they had used (e.g. oracles) and sometimes we did the other way around; e.g. when explaining risk we first gave a lecture and then let them create a simple risk analysis of an application before they actually got to test it.

The testing in this course was (of course) very superficial and the goal was to introduce many different concepts to give them a "foundation" rather than focus on teaching them one part really well, All in all the students, in one way or another, worked with ~10 different applications including desktop (Windows/iOS depending on their laptop), web, mobile and, in some cases, Linux desktop applications using VirtualBox.

You have to remember that the students in many cases came fresh from high school and/or did not have any technical background so it was just a brief introduction to the concepts and tools mentioned.

Think like a tester (6 weeks)

• Critical thinking
• Lateral thinking
• Heuristics
• Bias and Fallacies
• Problem solving
• Test polarities
• Models and mental models
• Information gathering/learning

The general setup was similar to the one used in the introduction course however, during the "think like a tester" course we added a lot of general exercises (e.g. what can you do with a brick, the alien tour exercise and many other) to compliment the theory and practical testing.

During this course, James Bach visited the class in Malmö and my class in Örebro joined in via video. A great opportunity for the students to see one of the experts often referenced, in real life. The highlight was James testing the same application as the students had tested as part of their examination for the introduction course. Malmö had several visits from prominent testers (thanks to Öredev) but I leave it to Martin and Maria to speak about those.

Project contexts (3 weeks)

• Lean and Agile
• Scrum and Kanban
• Waterfall and V/W-modell
• Outsourcing
• Testing in agile
• Common challenges for testers

The most interesting part of this course was probably a pretty detailed lecture and discussion on agile testing followed up by a big exercise where students were asked to identify risk in various contexts (like isolation etc.) and what to do to mitigate these/solve the problem.

Programming (6 weeks)

• Java
• Automation
• File systems
• Programming theory (e.g. compilers, bin/hex and memory allocation)
• TDD/unit tests

Most of this course was used by the students to program their own testing tool (tool to generate and interpret test data). I'm working on publishing some of them. This has by far been the most challenging course making students work day and night to get their examination applications ready.

Test methods (4 weeks)

• Schools of testing
• ISTQB
• TMap
• Context driven testing
• Myths

We teach a context driven mindset and the primary objective with this course was for the students to learn about other ways of looking at testing. Most focus was spent on ISTQB since it's so common and the students got to read the syllabus in detail as well as discuss its strengths, weaknesses, goals etc. in true "critical evaluation style".

Test design (24 weeks, 50%)

• Test approaches
• Test techniques
• Technology
• Heuristics
• Risk based testing
• Coverage
• Oracles
• When to use what?
• Security testing
• Performance and reliability testing
• Usability and UX testing

This course runs in parallel with the test strategy, bug reporting and test reporting courses described below and is (by far) the biggest course in the education. The goal is to make it rather practical letting the students use their newly acquired knowledge as quick and much as possible, thus the courses will kind of intertwine as it would be pretty wasteful/fabricated not to do test design, test strategy and test reporting when practicing bug reporting etc.

Test strategy (12 weeks, 50%)

• Risk based test management
• Heuristic test strategy model
• Visualisation
• Testability
• Test framing
• Test processes

This is the other course starting this week. The most important goal is to make students comfortable when requested to create or present their strategy.

Bug reporting (6 weeks, 50%)

• Content
• Different receivers/readers
• Bug pinpointing
• Reasons not to correct errors
• Oracles
• Bug trackers
• Style and structure
• What's a bug and what is not?

Test reporting (6 weeks, 50%)

• Rhetoric
• What are we reporting and why?
• Metrics
• How not to misguide the reader
• Style and structure
• Different receivers/readers/listeners

Testing tools (6 weeks)

• Various categories of tools
• Introduction to common tools

The main reason for this course is students in earlier vocal university software testing educations (not taught by us) felt practical testing and a basic knowledge of tools were the biggest parts lacking in their education. Apart from tools, being the last course we will have to spare some time to talk about practical tips and tricks preparing the students for the internship and working full time as testers.

Internship (8 weeks)

To finish off the education students are sent on internship at various companies. If you're interested in taking on a student, feel free to contact me in whatever way you prefer (email, Twitter, LinkedIn, as comment, buy me a beer at some conference etc,). By the way; I've not forgotten about you Karlo, students have been informed.

Learning more

You can read about the education (Swedish) on EC Education's homepage. If you have any further questions or are interested in attending the next iteration of the education (Malmö or Örebro) in September, don't hesitate to ask.

Report from a software testing education

(written in the middle of the night so you'll have to excuse any strange language or grammar)

Background

I'm currently teaching a 1½ years software testing education. The education is situated in Örebro, Sweden, and there's a similar one in Malmö, where Martin Nilsson is the teacher. In this blog post, I just want to briefly describe the education since many have shown an interest in what Martin and I are doing. This post will not go into any depth about exercises or lectures so in case that's your only interest you'll have to wait. The plan is to cover individual subjects in separate blog posts.

The Education

The education has a clear context driven touch to it, which is no surprise considering the teachers and that the curriculum was created by Henrik Andersson. Since it's the first year its run the material is created in parallel with the education. This has turned out to be a lot of work for me and Martin but it's incredibly rewarding.

Teaching style

This is a vocational university education meaning the students are expected to acquire a high level of practical proficiency or, as I prefer to describe it: Become awesome testers. Our approach to achieve this has been to mix lectures, discussions, exercises and a lot practical testing. Exercises both include exercises closely related to testing (like the critical thinking exercise I've written about before) as well as exercises designed to teach some aspect in a more general way. I'll tell you more about the exercises in later posts.

A lot of emphasis has also been put on creating an atmosphere where students feel safe to stand up, ask questions, question material and even, at times, get cross-examined. Considering it's a class of 30 students that's quite a challenge but we're getting there and I must say students are doing their part of the job splendidly.

The Students

While on the topic; the students range from fresh high schoolers to people taking breaks from well paid jobs. So far the students have completely blown our minds! I had 1/3 of the class attending a local test meetup last week in their spare time, their school results are amazing, during the first course me and Martin had to up the tempo (compared to our plan) roughly with a factor of 4 to keep up with the students and there's no sign of anyone slowing down.

So far, just in Örebro, they've sent in test reports to two companies, reported bugs to two more and I'm planning a project with Securitas Direct where they will briefly be part of a live project (focus is on learning project contexts and improve their ability to test but showing off for a potential future employer is never bad as an added bonus). And in Malmö all students attended two days of Öredev (thanks to Maria Kedemo), but I'll leave it to Maria and Martin to talk more about that.

The Subjects

So far two courses are finished: Introduction to testing and Thinking like a tester. I will cover the content, outcome and lessons learned from those in separate posts. A third is underway: Project contexts and finally there's a Programming course before the year ends. Next semester there's Test methods, Test design and techniques, Test strategy, Bug reporting and the final semester consists of Test reporting, Tools and finally there's eight weeks of internship to round up the education.

The Content

How do you set up 20 hours of teacher-led education in 10-20 hours (sometimes in topics you have very limited experience in)? Well, first off, you don't; but together, me and Martin are slowly closing in on 40 hours a week. A few things I've learned:

1. I created content ridiculously quick a few times and that quickly raised my general tempo (a bit like how you practice speed reading), so boring, but practice makes perfect.
2. Since I don't have time to practice what I'm about to say I try to think about key points I want to make and never put more than one on each slide to help me stay focused,
3. Use the community! Ask friends for help, get some coaching, copy or get inspired by other testers' exercises etc.
4. Google image is your friend when you dislike text in slides!
5. When designing my own exercises, I typically start with the one thing I want the students to learn (there are almost always added bonuses but I don't plan for those), From there I try to get to some context where this is very common and finally try to figure out a way to simulate this where I remove distractions or I try to find a way this can be isolated/highlighted while testing. I'll go into this in greater detail in later posts.
6. I force myself to focus on what's important. I often get caught up in, for example, trying to find that one perfect image or real life example but I've learned if I can't find it in 1 minute I will unlikely find it in 30 so I need to (if not critical) reconsider what I'm looking for.
7. I always strive for simple! It's tempting to show off by teaching the students unnecessary complicated things or making exercises overly delicate. They will forget a lot of what I say so time is, in my experience, better spent trying to teach them what's important, in an as clear and focused way as possible and repeating the key things over and over is typically good as long as you change approach (lectures, exercises, practical testing etc.).
8. I often find that exercises can, after run once, be slightly tweaked to either cement what I've been trying to show/teach the students, let them use their new knowledge/test that they've learned from their mistakes or to teach another aspect. And tweaking an existing exercise is typically much less work that to find/figure out a new one!

Sources are anything from articles and books to blogs and experience (from testing, workshops etc.). Finding good, reliable sources is also an area where I've gradually improved. Stories seem to be easier to relate to so I try to use my own experiences as much as possible. To make sharing between me a Martin easier we typically create simple, elegant slides (one or a few images and avoiding text) with a lot of notes. This works well for us when presenting the other person's material as well as for students when they have to read up (speaking about the notes right now). I should say the fact I have a deaf student in my class also is a factor here. She asked me early on to write notes for the slides since she had problems looking at the slides, the interpreter and take notes at the same time. So she should have a lot of credit as well for the detailed notes.

There's no limit to what I could say about creating content but let's stop there.

Company contact

Being an education requested from companies in the area, it's pretty natural to have a close cooperation with them. So far I'm still building my testing network in Örebro (I live, and typically work, 12 kilometers away, in Linköping) but I'm getting there. The goal long term is to get students connected with various companies long before the internship starts. We'll see how that goal turns out.

Internship

If you keep reading about the education and think it sounds interesting keep the internship in mind as many students are open, or even actively seek, to work somewhere else than in Örebro. Mostly in Sweden (Gothenburg, Stockholm, Västerås, Karlskoga/Karlstad and Helsingborg) but also abroad such as Australia, Austria, USA (especially San Francisco and Columbus) and Russia, just contact me if you wanna know more or feel like you could use one of these students at your company. The internship doesn't start until October next year but never hurts to get the connection done well in advance.

Wrap up

So that's the boring part, next up is "Introduction to testing"; what, how and why we taught the students the things we did and what we (Martin and I) learned from giving this course.

By the way: The education use #YHTest on Twitter in case you want to see what the students have created (used sparsely so far).

Exercise: Critical thinking in software testing

It's a hectic period right now (which explains the lack of presence on Twitter, email, the blog and everything else basically) and that will probably continue for the foreseeable future. But in the middle of this I would like to share an exercise I gave my students. Oh, I'm the teacher for a software testing education these days, in case you didn't know:

1. Pick a page (for this exercise, preferably a simple one).
2. Just looking at it: Form as many questions as you can think of.
   (to save yourself some time, just write down what you find potentially relevant)
3. Try to answer the questions formed, don't forget to use the rule of three*

* If you can’t think of three things that might go wrong with your plans, then there’s something wrong with your thinking. // Gerald Weinberg

So what's the goal? To practice critical thinking, to spark curiosity, to find a way forward when stuck/find different perspectives, to reveal important questions and to generate ideas for improvements. May sound a bit silly but give it shot!

Example of the "forming questions" part (Square - Login form):

• What does the logo communicate? Is it representative for the company? What else could be representable? What other locations of the logo would make sense?
• Why is it so minimalistic? Is there a specific reason? What options exist?
• What if the logo was bigger? WHat if everything was bigger?
• Could the sign in box's bright color be a problem on a bad monitor?
• What options are there to the text "sign in" in the sign in box header?
• Are the textbox placeholders HTML5? If so, how will the page work in a browser not supporting HTML5? If not HTML5 placeholders, how will it handle autofill by the browser? Risk of label overlap?
• What if the "header bar" (saying "sign in") was darker? What colors could be suitable?
• Is email a good choice for "identifier" (compared to e.g. username)?
• Password is obscured, why not do the same for email?
• The logo is not clickable, should it be?
• How do you get back to the start page?
• What options are there to the text "Forgot password?"?
• The text on the sign in button is a bit blurry, would a different font help? Size? Text weight? Color?
• What's the reason for the choice of languages?
• What's the difference between English and Canadian english?
• What's the purpose for the bright logo just beneath the language link?
• Why can't you tab your way to the language link? Could that be a problem?
• Any options to the language link (e.g. a flag)?
• What other fonts could be considered?
• Is it clear what page you're on (Square)?
• Is an account free to register? Should this be stated somehow?
• How will the page signal an incorrect email/password?
• There's no copyright information, could this be a problem?
• There's no footer at all, any typical footer information missing?
• ...

If not clear: This is described as an exercise but the principle, of forming a ton of questions to get you forward when stuck, get a new perspective etc. is perfectly valid whenever you're testing (as many before me have stated, not in any way taking credit for that one :)

Good luck!

To testers in Sweden: Get my job!

This is only for software testers interested in working in Linköping.

Under sommaren flyttade jag från Securitas Direct till House of Test. Nu rekryterar Securitas Direct för att ersätta mig och jag tänkte berätta varför du borde söka:

1) För gruppen: Utvecklingsteamet är en otroligt skön grupp med en bra mix av personligheter och en otrolig passion för det de gör. Låter lite klyschigt men när jag säger passion, menar jag det verkligen. Det byggs flitigt olika projekt på fritiden, pratas teknik och med allas brinnande intresse så är det svårt att inte själv entusiasmeras.

2) För din utveckling: Du är fri att testa nya grejer, läsa på och fortsätta utbilda dig på andra sätt. Skulle också vilja lyfta att Securitas Direct är ett av de mest generösa företag jag stött på när det kommer till kurser och konferenser!

3) För kulturen: På Securitas Direct lyssnar man på varje enskild individ, och då menar jag verkligen lyssnar. Man har verktyg för att anställda på alla områden ska kunna lyfta sina idéer, kreativa medarbetare belönas, det finns en påtaglig positiv attityd rakt igenom hela företaget och det är en väldigt platt organisation där högsta chefen syns och lyssnar, oavsett vem du råkar vara. Vill du uppleva agile, så som agile var tänkt så kommer du trivas.

4) För chefen: Markus är en av de bästa chefer jag kommit i kontakt med! Han är en trygg chef som litar på sina medarbetare, lyssnar och bryr sig, nyfiken, vill helhjärtat att alla ska utvecklas och är en beundransvärt skicklig/inspirerande visionär. Du kommer tveklöst vara i goda händer!

5) För produkterna: Snabbt föränderliga produkter med variation och "edge". De har en helhet och det du jobbar med finns snabbt i händerna på kunder.

6) För friheten: Du är i princip helt självorganiserad vilket är otroligt utvecklande, fritt och spännande! Jag upplevde att melodin var: Frihet föder ansvar (snarare än frihet under ansvar som för mig är mer kontrollerande).

7) För företaget: Ett innovativt företag med en platt organisation där alla är involverade. De står även starkt upp för sina egna moraliska värderingar, någon man känner, och blir del av, som anställd.

Den uppenbara frågan nu: Om det nu är så bra, varför lämnade då jag? Svaret: För att jag ville jobba med coachning och utbildning av testare, något som mycket få produktbolag har plats för (inklusive Securitas Direct). Men jag är också den ende som hittills lämnat utvecklingsavdelningen, det säger något i sig själv!

Utvecklingsavdelningen har än så länge bara en testare. Den växer, så det kan mycket väl ändras tämligen snart men viktigt:
Att vara ensam testare ställer högre krav på din självständighet. Dock bryr sig organisationen (speciellt utvecklarna) om testning så du är inte ensam om att kämpa för test, Linköping har ett starkt test community vilket hjälper, samt att ingen har förväntat sig att jag ska kunna allt utan istället uppmuntras inlärning. Själv kom jag t.ex. in med mycket liten erfarenhet av webbtestning och hade egentligen aldrig jobbat ensam men jag har inte bara överlevt utan njutit av resan. Fördelen med att vara själv för mig, har varit friheten, den lodräta personliga utvecklingskurvan och mångfalden i det jag testat/fått göra.

Ett sista argument:

När Markus (din blivande chef, längst till höger på bilden) fick höra att det fanns en utvecklarkonferens i Linköping var budskapet: "Alla som vill gå säger bara till så bokar jag in er", samt att han själv gick. Fokus på lärande och personlig utveckling som sagt.

Missa inte chansen, ta mitt jobb! Det är ett drömjobb på en drömarbetsplats om du vill utvecklas som testare!

Sök här:
https://adecco.zerolime.se/show.aspx?src=internal&tag=feed&id=962BD45E-2658-4C71-96BA-435197D32909

/Erik Brickarp, numera House of Test

Why we need realism in testing

I was sitting on the train. As the train attendant passed a woman right behind me called out "Excuse me, is that ticket reader from 2013?".

- I'm not sure, why do you ask?, responded the train attendant
- Well, this morning I noticed the train attendant's ticket reader seemed very bulky so I called the railway company and they rudely told me it wasn't a problem anymore since they had upgraded the model in 2013. So I was wondering if that's the new or old model.
- Well, I don't think there's a newer model but honestly I don't know, what I do know is this one is at least not built for me.

They started talking about various problems the train attendant and her colleagues had experienced. Of those these seemed to be the biggest ones:

• The device was made for much bigger hands than most train attendants'.
• The device was way too heavy.
• The device was tough to get a grip around and maneuver, probably even if you had "right sized hands".

The most alarming result was the amount of people on sick leave had grown notably since the current ticket reader was introduced, according to the train attendant, and the main reason was reportedly over-stretched arms.

The biggest issue with the current ticket reader seemed to be the humongous battery on the back. At this point I had curiously joined the conversation and commented that the battery's size seemed unreasonable knowing even several years old, cheap, small smartphones had batteries lasting for days doing much more complex tasks. The response to that was quite telling:

- The one we had before was much easier to carry but the battery didn't last long enough.

At this point I suspected two things:

1. Someone was informed: "We need to improve the battery on our ticket readers". Armed with that information, this someone wrote a spec saying "same functionality but better battery" and the humongous battery was the quick fix, a seemingly identical device but with more power. Implicit requirements such as "it should weight a maximum of ... grams" or "it should fit the hands of our train attendants" was most likely not considered.
    
2. Whoever tested this didn't test it under realistic conditions such as for many hours, trying to reach over other passengers, walking long distances carrying it and so forth. Another possibility is the casing and hardware was "just an ordered standard third-party device" (probably not built for this specific purpose) and all focus was on the software. A third option would be no testing was done since it was "just a change of battery, which will not change anything to the device, only improve it".

I'm still very curious if any acceptance testing was done by the railway company. If so, under which conditions, for how long and by who, actual train attendants? If not, why not? (I can list many plausible answers but still curious)

Continuing the conversation the woman initiating it started to list a few simple ideas, just from the top of her head, that could had eased/solved the problem. My personal favorite was: "Why don't design it so that the battery pack is in the belt". That seemed like a minimum effort, low cost solution to both the old and new problem. Knowing the current state though I suspect the manufacturer would probably had delivered a too short power cord.

I thanked this wonderful women who asked the question, as well as the train attendant. I got a valuable reminder of how important "dogfooding" and testing a product under realistic conditions are, as well as a good reminder of how much you can learn from just being curious.

My message with this story: Yes, it's often inconvenient to figure out and set up realistic conditions when testing but failing to do so can be catastrophic. As the train attendant pointed out: "Some days when my arm is aching I just look at the tickets and assume they are valid".

Update

Here's an image of the ticket reader. Notice the battery (bottom left) and how it obstructs a "natural grip" around the device. This train attendant also had notably larger hands than the train attendant mentioned in the original post (two different train attendants) to further emphasize the problem.

Finally, when I snapped this picture the train attendant immediately responded: "Are you gonna get us a better ticket reader?". Pretty telling comment.

Using STWC to explain testing

When I explained STWC (Software Testing World Cup) to a friend recently, I realized that story actually encapsulated testing in a pretty good and concise way:

Well, the general setup was pretty easy: Each team had 3 hours to test a product, revealed just before the competition started. Throughout the whole competition we had people in charge of the product available on a live video channel so that we could ask questions and get valuable information from them as we were testing. Finally, before the three hours were up, we had to file all our bugs and send in a test report containing stuff like critical bugs, suggestions for improvements, what we had covered and so on. The winner was then chosen based on value from bug reports, the test report and how well we communicated with stakeholders. And value of bug reports was not our bug count but rather severity of the bugs, if the programmers managed to understand and reproduce the bugs based on our descriptions and so on.

Our team started out by just clicking around in the application, trying understand how it worked. In parallel we watched an introduction given by the product owner where he shared what he wanted us to focus our testing on etc. After doing this for a few minutes we stopped to share what we had learned, split up the work and briefly talked test strategy. When done, we started exploring, or well test, the product, stopping every now and then for debriefs to ensure everyone had a good flow. At the end we finalized the report, made some improvements to our bug reports and well, that was it.

To just briefly explain concepts like debriefs, touring, the importance of questions and communication, common artifacts/output, value from bug reports and how the process of testing actually (can) look like, is hard! Being able to put them into a simple context like this, seems to me like an efficient way and if something is still unclear I can just zoom in on that specific detail, for instance:

Hang on, what do you mean with test strategy?

Well, in the intro the product owner shared what parts he wanted us to focus on; the email functionality, screen resolutions and the possibility to "steal" other user's customers. The strategy in this case was: Is this enough or should we focus on something else? Any general ideas on how to test these things? Who does what? How do we use our time, like how often to debrief and when to start with the test report? Also, as part of the strategy, we set some roles to make sure nothing was forgotten; so Agnetha was responsible for our communication with stakeholders, I was responsible for the test report and Sofia was responsible for the quality of our bug reports. All and all a plan on what to do, roughly how to do it and who should do what.

My message with this blog post is: If you are to explain something complex, it often helps to find a simple context to apply it on. The story is like a picture, even when brief it can tell a thousand words worth of complex, abstract details.

By the way: Gerald Weinberg is a master when it comes to explaining complex concepts using simple stories. I do recommend his books if you wanna see this in full action (guess that's kind of an unnecessary recommendation as I seem to be the last tester to have discovered his brilliance)

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