Showing posts with label SWET. Show all posts
Showing posts with label SWET. Show all posts

26 April 2017

Peer conferences, part 2, checklist


Intro

If you want to know more about what a peer conference is, general tips and tricks, different formats etc., do read part 1 first.

Notice, this checklist is based around how we run SWET with a conference center, shared costs among participants, experience reports, abstracts etc. but even if you choose a vastly different format I think a lot of this still applies; there's simply stuff you can ignore.

Finally: I'm in no way an expert but I couldn't find this kind of information so I basically shared my lessons learned... and since SWETish, EASTish and SWET 8 all felt like great peer conferences this, as a minimum, should be great enough.
    

Initiate

  • Set the group of organizers (my recommendation 3-4)
  • Schedule a startup meeting (e.g. Skype video or face-to-face)
        

First meeting

  • Set a date and duration (typically a Sat morning to Sun lunch)
  • Set the max and min amount of participants (my recommendation 10-13, incl. organizers)
  • List potential locations and start the process of booking one of these
  • Set the general format for the conference (see part 1)
  • Decide if you will have an opened or closed (invite only) invitation
  • Start discussing a topic/theme
  • Set organizer deadlines (e.g. deadline for invitations to be sent)
  • Set participant deadlines (e.g. when they need to confirm if they will attend)
  • Set how you will interact with participants (e.g. Slack, email, Facebook or Skype)
       

Prepare invitation

  • Book the place where you want to hold the conference
  • Decide who you want to invite, if invite only
  • Decide where you want to advertise your conference if open invitation
  • Practical details (see invitation below), e.g. "when should we start in the morning"
  • Send out the invitation (see below)
       

Invitation  

Email (example, personal invitation):
Hi Helena,

April 1st we will host the first iteration of PCSA at Amalias Hus (http://www.amaliashus.se), Gränna and we would love to have you as a participant! PCSA 1 is an invite only, peer conference. The topic for the conference is "Leading testers". In the attachment you'll find an explanation of what a peer conference is, a detailed description of the topic and other useful information related to the conference.

Why I want you to attend

Ever since we met 2013 you've been my main inspiration on how to lead, coach and support testers, so for this topic I think you're the perfect fit. I hope you can bring a very people centered view point to the questions and your broad experience in leading teams should be a valuable compliment/sanity check to some of the more "test lead centered" participants. I also value your ability to respectfully challenge and question people when you want more details on how they came to certain conclusions. Finally your dedication and passion for testing is something I think will inspire others during the conference, which is important to.
/Erik

What happens now?
By February 19th we need to know if you'll attend

By March 31st we need to have your abstract

Best regards,
Erik, Göran and Sigge 

Attachment or open invitation:
https://docs.google.com/document/d/1dnJEdAujFplX4cLWHqkS03wftMLpLD4Z11WT12Mo814/view?usp=sharing
   

Contract(s)

These are the things I find important to establish with external parties such as the conference center, catering etc. Some of these will not be relevant to your setup, keep that in mind.
  • Price for both minimum and maximum number of participants (hotel, food, facility etc.)
    • Is tax included or excluded?
  • What is included and what is not, in the price above?
  • Here's the schedule we suggest, will this work for you?
  • When do we need to report food allergies/preferences?
  • What food will you serve? (menu suggestion)
  • What facilities will be available to us in the evening?
  • Will there be a bar/snacks available in the evening?
  • When may we check in and when must we check out?
  • What equipment (projector, whiteboard, sound, flipchart etc.) will be available?
  • Do you prefer if participants contact you upon questions or should I do that for them?
  • When is the last date we may change the number of participants? (e.g. cancellations)
    • What will we have to pay for after this date? (e.g. only room, only conference or both)
  • How do you best get to the location with public transport?
  • How much parking space will be available?
  • Can you manage the splitting of costs (including cost for the conference room)?
  • When will we pay (e.g. on check out) and is there a deposit fee?
         

Waiting for people to confirm

To keep track of invited people setup some spreadsheet/system.
Example: For SWET 8 we had a spreadsheet with the following columns:
  • Name
  • Email
  • Order; we had a list of 30+ names and had to keep track of who to invite first.
  • Who among the organizers invites this person
  • Invited (yes/no)
  • Response (yes/no/maybe, empty = no response)
  • Arrives; we had different prices for arriving late on Friday or early on Saturday.
  • Allergies
  • Abstract sent (yes/no)
  • Comment; e.g. "will answer after the weekend but will probably attend"
We later created a separate list with name, arrival day and allergies so that participants could fill this out themselves.
   

Handling abstracts

When all participants had sent in their abstracts we set up a new spreadsheet (we like spreadsheets) with one column for the participants' names and one column each for organizers. We then scored the abstracts from 1-5 in our respective column and summarized the result.

After that we listed the top ~8 abstracts and discussed if we wanted that order or if we wanted to change anything; for instance in the case of SWET 8 we had a couple of fairly similar abstracts so we opted to skip one of them even though it made top 4 and then switched order of a at least two other after considering experience, how much discussion we anticipated etc.

Finally we showed the participants the top 5 of our modified speaker list (ranking of abstracts).
    

Communication to participants

Here are all the things I can find in Slack and email, which we sent out to participants prior to the conference but after all the registration was done:
  • A detailed schedule (see part 3)
  • Food menu
  • Asked for suggestions for evening activities
  • Clarified the topic a bit and gave more examples
  • Feedback to some of the abstracts
  • Who would participate and where they were living to simplify car pooling
  • Reminder of the abstract deadline ~4 weeks and ~1 week before.
  • Kept the participants up to date with our (the organizers) work, e.g. when we planned to set the speaker list etc.
  • Sent out all the abstracts to the participants
  • Various information about payment etc. given by the conference center (see Contracts)
  • Explained the process around the lightning talks
  • Contacted the individual speakers to tell them who would facilitate their talk
  • Various clarifications and details asked for by participants
        

Summary

This may seem like a lot but let's be clear: What you basically have to look into is:
  • Where?
  • When?
  • Who will we invite?
  • What format should we use?
... the rest will come pretty naturally. For instance we (Göran Bakken, Sigge Birgisson and I) had no checklist when we organized SWET 8; basically the first peer conference anyone of us had organized. Most of the details (schedule, food, deadlines etc.) either came from questions/needs that popped up naturally, things that the conference center informed us about and we just forwarded or it was copied from previous iterations of SWET.

... but I wanted you to learn from stuff we for instance though of a little late (like the schedule) so that you can do an even better job than us.

Good luck!
    

Part 3

Part 3 will cover the actual conference including things like check in, facilitation etc. Stay tuned!

24 April 2017

Peer conferences, part 1

Warning

This blog series is mainly for people who (would like to) arrange or attend peer conferences (explained below). People not interested in peer conferences will find rather little value in this post. One exception though could be if you want to arrange some workshop/conference at your work and you want inspiration for that. Finally; you can replace testing/software testing below with e.g. "programming", "change management" or something else as the experiences and methods should work for any "topic", I just happen to work with software testing.

Finally, these are my thoughts, not "the truth".

EDIT: If you want more ideas on the topic of peer conferences, check out James Thomas' blog post "Trying to be CEWT" and James Lyndsay's blog post "http://workroomprds.github.io/LEWT".
  

Peer conference

A peer conference in this case refers to a small group of experts, gathered to debate a specific topic, based on their own experiences rather than e.g. abstract models and they do this in a focused manner for at least one day. "Small group" refers to something like 6-16 people. "Expert" is harder to define but means something like "a person with a lot of skill, passion and/or experience in software testing".

With this definition I realize other events I've attended might qualify but I hope it's good enough to at least understand this article.
 

Data

This section is to help you understand what I base my thoughts on. Feel free to skip it if not interested. Do note that I attend a lot of other "peer conference -like" events such as Transpection Tuesday, local meetups etc. and I will take that experience into consideration but haven't listed it in this chapter for the sake of your (and my) sanity.
  • SWET 4
    15 attendees
    James Bach present, lot's of well known names overall
    I was very inexperienced (compared to the other participants)
    Language: English
    Setup: LAWST inspired
    Topic: Models in testing
    Location: Sweden, fancy conference center
    Length: 1½ days (+optional 1/3 day before), Saturday morning to Sunday lunch
        
  • SWET 7
    10 attendees
    James Bach present, very inexperienced group
    I was one of the most experienced attendees
    Language: English
    Setup: LAWST inspired
    Topic: Test coaching
    Location: Sweden, fancy conference center
    Length: 1½ days (+optional 1/3 day before), Saturday morning to Sunday lunch
      
  • PEST 6
    9 attendees
    Michael Bolton present, the best of Estonia (which is pretty awesome btw.)
    I was an "international attendee" so a bit different
    Language: English
    Setup: LAWST inspired
    Topic: Gaining consciousness
    Location: Estonia, at Nortal (company)
    Length: 1½ days, Saturday morning to Sunday lunch
      
  • SWETish
    10 attendees
    "regional peer conferences" with attendees mainly from Linköping and Örebro
    I was one of the most experienced attendees and co-organizer
    Language: Swedish
    Setup: LAWST inspired
    Topic: Exploratory testing
    Location: Sweden, fancy conference center
    Length: 1½ days, Saturday morning to Sunday lunch
      
  • EASTish
    8 attendees
    Only attendees from Linköping, mainly from two specific companies
    I was one of the most experienced attendees and co-organizer
    Language: Swedish
    Setup: People brought their own topics so no "formal presentations"
    Topic: Any
    Location: Sweden, at Sectra (company)
    Length: 1 day (optional evening), Saturday
      
  • SWET 8
    11 attendees
    Experienced group, rather mixed skillsets
    I was one of the more experienced attendees
    Language: Swedish
    Setup: LAWST inspired
    Topic: Testing that's not testing
    Location: Sweden, fancy conference center
    Length: 1 day (+optional 1/3 day before), Saturday morning to Sunday lunch
        

Size

So far my experience is ~9 is the minimum; below that the amount of conflicting ideas and experiences, which are important, starts to become an issue. EASTish was still a great peer conference but I think that conference would had gotten even better with a couple more attendees. PEST was right at the minimum limit but I personally did not feel the amount of people negatively impacted the quality of the conversations. Of course the people matter a lot in this case; more experienced people with more diverse experiences having a lot of passion and willingness to debate will likely mean you need fewer attendees and vice versa.

My personal upper limit is ~13; beyond that it seems like every single person gets too little time; especially if there are a few very talkative individuals in the group.

I would typically aim for 13 and since people will get sick, can't attend in the first place etc. that might make us end up with 11-12 which seems great. Notice that "aim" in this case does not mean "invite". For SWET 8 we had, for instance, at most 18 invitations out simultaneously but ended up with 12 who accepted and in the end 11 attendees as one had to cancel.

Language

I didn't think of language as much of an issue until I attended SWETish, my first peer conference in Swedish. It helps a lot even in a country where people generally speak pretty good English. To me, using the attendees' native language seems to help people "dare" to share more ideas, there seems to be way fewer misunderstandings and the overall flow is much better.

But it's a balance as using attendees native language rather than a language more broadly spoken (such as English) will limit who can attend... a problem we have in Sweden as well as several top notch testers here don't speak Swedish or at least not well enough (yet) to attend a fast paced peer conference in Swedish.
   

Experts

I have huge respect for people like James Bach and Michael Bolton; they always add a ton of value to a conversation about testing and especially given a format like the one typically used at peer conferences. Also seeing how James really helped a bunch of less experienced testers elevate during SWET 7 was awesome... however...

In Sweden it impacts the language, which I think is a problem (see Language). We also have a lot of talented testers so giving a spot to an expert will naturally stop someone else from attending and/or give some people less room to express themselves. Finally my experience is it steals a bit of focus as some people, knowingly or not, try too hard to impress the expert and/or not look stupid, hurting their overall performance at the conference.

I think inviting someone like James or Michael is amazing if the language is English anyway and/or the group is very experienced (hopefully lowering the "need" to impress) and/or it's hard to attract enough attendees so giving away a spot is not an issue while the expert can act as a motivation for other people to attend... but it's not necessary, you can have an amazing peer conferences without international, or even national, "experts" (e.g. at work, in your city or in you "region")... and I say this from the context: Linköping, Sweden; a city where we have a fairly active and skilled test community, just to make that clear.
   

Attendees


Experience (as in how much "testing" and "software development" the person has experienced/seen/participated in) helps as we base the discussions on experience. But mixing in a few rather inexperienced people can really add some interesting new points of view, as long as these inexperienced people feel safe sharing their thoughts. To summarize: Having a lot of  experience helps but lack of it is not a deal breaker.

Skill (as in your actual ability to test and understand testing) is, for me, key. Some people might not be known anywhere outside their own company, they might not have much experience neither as testers or in talking about testing but place them in a situation like this and they will provide value, as long as they themselves understand that their skill level is on par with everyone else's.

So on the topic of "experts", how much experience and skill does the average attendee need to have to make the peer conference amazing? My personal experience is: "a lot less than many seem to think".

Two other interesting attributes to me are passion and (verbal) communication skills.

Passion helps a lot but I think that usually comes naturally with wanting to spend a weekend (during which peer conferences or often organized) "just talking about testing"... be careful though about attendees who just think "it'll look good on their resumés" or who want to attend to advertise their own services or hire skilled testers.

Communication skills are important in general but do not mistake this for "talkative" attendees. The K-card system often used at peer conferences, for instance, can help less talkative people gather their thoughts and help them get into otherwise intense conversation and it can stop people who think in an extroverted way ("while talking") from filling all "the space". Instead, much more important is having attendees who can express something in a concise way, who respect the facilitator/format (primarily who won't speak when they shouldn't) and who can understand when their comments won't help a conversation forward/add value as well as dare to speak up when their comments will.
   

Invitation

My first ever peer conference, SWET 4, had an invite only format. My second had an open invitation (first 15 to sign up), my third had an open invitation (everyone may send in an abstract but a program board will select who will actually get an invitation among those) and later I also attended a "semi invite only" where ~15 people got a few days head start (personal invitation) until an open invitation was sent out. Long story short: You can do it in many different ways.

Invite only is great when you know exactly who you want to invite and want control over the group. I also find this to be most efficient as people feel selected and thus prioritze the conference more. It also helps to get those crucial first two or three attendees you need to start a buzz about the conference. There's also a risk that the group becomes too homogeneous; resulting in fewer conflicting ideas/experiences and thus fewer opportunities for people to challenge their own models.

Open invitation is great when you don't know the people you want to invite and/or who you want to come. It also relieves you from some "why did she get an invitation but not be" comments and allows you to better talk about the conference before it actually starts. However, it may make it harder to get those first attendees to sign up as they don't know if the group will be good; this can be somewhat helped by e.g. make in open invitation in a large group (e.g. a Meetup group) but where all the members should be good candidates. Also, there's a risk "the right people" will ignore the invitation because they don't understand they qualify or they, for whatever other reason, don't feel like they are the ones you're looking for.

I personally prefer invite only, even when I don't get an invite myself. I think that allows the organizers to better create a group that's suitable for the topic at hand... but that's my personal preference.

There are like I described in the beginning of this chapter many hybrids between the two but I think that should at least give you and idea. Finding the right format to send out the invitations is pretty straight forward for invite-only (email is pretty good for this) but depends completely on your context if it's an open invitation.

In the next part I'll share a checklist and example of what I think you should consider adding to an invitation, so stay tuned for part 2.

P.S.
For SWET 8 we wrote a personal note in each invitation explaining why we wanted that particular person to attend. This was definitely a win-win:
  • Participants better understood our expectations
  • Participants got to feel good about themselves
  • It seemed to make more people accept the invitation
  • For us, the organizers, it felt good to tell awesome people why they were awesome and it didn't cost much time or effort.
I'll provide an example of this in part 2.
     

Organizers

My preference so far is "as many as possible but not more than 4" (so I guess 3-4). Communication and taking decisions become a problem as soon as you're two but to me it's still worth the benefits (see below) until you're around 4 to 5. Some benefits of having more organizers are:
  1. There are simply fewer people (easier) you need to invite to get a full group
  2. The first person to accept the invitation will join an already established group
  3. You are much less fragile, if one gets sick/life happens the work can still move forward
  4. Larger personal network, key to avoid too many like-minded attendees when using invite only
  5. Greater presence in social medias etc., key when using an open invitation
  6. You have more options considering location, food etc.
  7. More people mean each person needs to do less... and I'm lazy
  8. It's easier to identify who you want to invite since you better know what's missing in the group
  9. Each organizer can relax more during the conference (less pressure on each)
  10. A lot less risk as with one sick organizer a peer conference might collapse if only having one or two organizers but it's much easier to handle if 3 or 4.
If the organizers can meet in person I think it's a benefit but having a good communication platform (e.g. Slack, Skype etc.) should be sufficient. For SWET 8 the only physical meeting we had together was the evening when we decided we wanted to organize a test conference, everything else was handled via Slack.
      

Format

All peer conferences, except EASTish, I've attended have used basically the same format:
  • All attendees prepare ~20 min presentations based on something they've experienced.
  • A few attendees will actually present, usually 2-4, for a 1½ day peer conference.
  • After an experience report there's a facilitated discussion around that presentation. The discussion will continue until the group feel done with the topic (usually 1-6 hours).
  • At some point there's time for lightning talks: ~5 min talks including open season.
While I think this is a great format I think other formats could work just as well and potentially even better as they have been explored less.

Two suggestions:
  • Discussion topics and dot voting instead of presentations
  • Solving an actual problem (doing something); with one or more debriefs
At EASTish rather than presentations, attendees got to write down a few topics each (typically in the form of a question or short scenario) and then we dot voted. This basically turned it into a prolonged lean coffee. There were some cool benefits to this format:
  • People got help/got to discuss the exact topics/questions they were interested in
  • Much less time to prepare for attendees
  • People who feel uncomfortable to present didn't have that distraction 
Drawbacks could potentially be more abstract content rather than focus on experience (not my experience from EASTish), if attendees think the format means they don't have to prepare that may negatively impact the topics covered and the presentations (or rather preparation work needed) may act as a useful gate keeper; scaring off people who want to attend for the "wrong reasons". I don't know if any of these drawbacks are actually valid but no matter what; this is a format I would love to try at a peer conference fairly soon; with or without a specific topic/theme, but probably with.

The other suggestion is something I have tried at a local meetup where we split into smaller (mixed) groups, tested a specific application and finally spent a long time debriefing our testing including why we did the testing we did, how we organized ourselves, differences between individuals in the team etc. The idea has also been used at at least one peer conference before: PEST 4.5, where they tried to visualize various reports in testing in new and creative ways. I highly recommend reading about PEST 4.5 and ever since I heard about it I've wanted to attend/arrange something similar.

If you have ideas on other formats that could be useful, please comment and I'll add them to the post. This is one of the areas where I think we could really take the concept of peer conferences to a whole new level!
   

Topic/theme

Peer conferences typically have a topic/theme. This topic/theme is important to keep discussions focused, to get the right people interested in the conference and to help people prepare before the conference.

Generally topics should be broad enough to include some diversity but narrow enough so that we can actually get deep into the topic. You have several examples in the Data chapter and if you search for "peer conference software testing" you'll find more. One issue though is that the one liner rarely tells the full story as there are usually specific aspects you're interested in (the one-liner is too broad). To get a better idea what I mean, do check out the invitation for PEST 6, it explains their topic "Gaining consciousness" in a great way.
       

Presentations

This is relevant if you let people present, skip if you want a different format.

First of all, set a clear deadline for when you want attendees to inform you what they want to talk about. Informing you about what they want to talk about is typically done in the form of an abstract (~1 page description of the talk).

When you know what they want to talk about establish a speaker order and if possible, set who will facilitate each talk. You can read more about facilitation in the story behind K-cards. I'll try to share how I do this in some later part but if I forget, feel free to ask me.
If your peer conference looks anything like the ones I've attended you'll likely fit 2-4 presentations into a 1½ day conference, so my advice is to inform the top 5 participants (1 extra to deal with a potential cancellation) and let the rest focus on lightning talks.

I also recommend having appointed mentors (typically organizers, e.g. the facilitator) available for each speaker. This can help both experienced and inexperienced speakers present the "right thing" (an actual experience rather than some abstract concept).
    

Duration

Every time I've attend 1½ day peer conferences, I feel like half the group says "This sucks, I would like to continue" and the other half says: "I loved this, but now I need some sleep/think for myself" at the end. I don't know if that means the length is perfect or too short (or even too long) but I think it's a sign the length is quite good.

However, to avoid stagnation (few new ideas/low energy) when going beyond a day my experience is you need a larger group than ~10 and/or very passionate/skilled/experienced attendees. I for instance felt a bit of stagnation during SWET 7 but not during SWET 4 and SWET 8.

I would love to try a full 2 day version but when trying to find a good schedule I run into problems. If you want to avoid missing too much time from work (problem typically for consultants) you could either start by lunch on Friday and end by lunch on Sunday, this would cost one extra night (compared to the typical Saturday morning to Sunday lunch setup) and interfere with working hours especially for people with a long ride to the conference... or you could start Saturday morning but end Sunday evening instead, so you basically end after dinner (say everyone leave ~21:00). This would not cost an extra night but add quite a bit of conference time. Would suck though for people having e.g. a 3h+ drive home (common in Sweden)... Maybe end at say 17:00 or 18:00 and skip the extra dinner as part of the conference... I need to think about this a bit more.

The other option: Shorter, means you can cut costs (e.g. no nights) and make it simpler for people to "spare the time". We did this in Linköping (city with ~140k population) and it work out nice. I don't think shorter is an option when attendees have more than say 30mins to the conference but worked great if you want to introduce the concept of peer conferences to a more local group.
   

Facility and food

Facility and food are actually quite important since attendees will like sit for long durations and be exposed to a lot of information. When selecting a place to host the peer conference, take into consideration: costs, food, quality of the conference area, how much you have to fix yourself and facilities to use in the evenings.

For the evenings it seems like you want one of two things: An inspiring area to sit in (beautiful, unusual/creative, enough space etc.) or a relaxing pool area; e.g. a large outdoor jacuzzi... some alcohol (like a beer or two) also helps.

Being in an area that's great for taking a relaxed walk or jog also helps in my experience as people need some air after more or less a full day in a conference room. For this, choosing a location that's somewhat remote seems to help; this also has the benefit of helping people to fully commit to the conference as there are fewer distractions.

A conference center will greatly up the costs but also significantly lower the amount of work for the organizers. I've attended peer conferences hosted both at conference centers and at someones company, both work equally good to me as long as the organizers, in the latter case, have a good plan for e.g. food, evening location, some energy refillers (=candy/sweets) for the breaks etc.

Schedule

  1. Make sure there's a schedule
  2. Make sure the conference center, food catering etc. agree to your schedule
  3. Be flexible; not interrupting a good discussion is more important than sticking to the plan
  4. Schedule regular breaks but remember to not interrupt good discussions (see previous)

Evenings

During the evening(s) a lot of important processing, bonding and follow up discussions take place. Make sure there are good facilities for these, that attendees stay (except for the need of sleep or handle social overload) and that there are some "conversation/activity help".

"A good place" and "making attendees stay" were described in the "Facility and food" chapter above so let's focus on "conversation/activity help". A lesson learned (for me) during SWET 8 was I think the group benefits from being split up a bit in the evening. One simple example is having one or more tables devoted to e.g. the dice game, coin game, Test Sphere or Set as this will split up the group. If there's a pool area the size of the jacuzzi and the fact not everyone like spending time in a pool will automatically split up the group (not necessarily in an optimal way though, but hopefully good enough).

Other examples could be to actually schedule activities in the evening. One way would be to split into smaller groups doing some task, challenge or activity and then, in a simple and informal way, let the groups debrief their results to the rest of the attendees (either in the evening or the next morning). Another would be to set specific topics/tasks at different tables so people can rotate and discuss/do different things with different attendees. Be careful about ambitious plans though; it seems like as long as you provide a somewhat quiet area where people can easily split up into smaller groups themselves; you're basically set... but some help rarely hurts.
   

Summary

I think we can take the concept of peer conferences even further if we dare to challenge the current common setup by e.g. trying new formats, longer/shorter conferences, tinkering with the group we invite, try new locations etc. For instance my view of the "minimum viable product" for a peer conference (location, setup etc.) was significantly altered after I had attended PEST 6 which was the first peer conference I attended that wasn't hosted in a fancy conference center. PEST 6 then became important inspiration for how we arranged EASTish here in Linköping.

What's next

Part 2 will be a checklist for organizing a peer conference including an example of an invitation etc. The goal with this post was to help people learn new ways of organizing a peer conference, part 2 will hopefully inspire new people to organize them as they learn it's not that complicated.

Part 3 will deal with stuff related to the actual execution of the conference e.g. facilitation, check ins/check outs etc.

21 November 2016

SWETish

It was quite a long time since I wrote about an event. This is mainly because "it's not new to learn new stuff" anymore so for me to write about an event it need to be pretty special. SWETish, a peer conference that just ended, was exactly that: Special.

I've tried to wrap my head around what made this different and it boils down to:
I've not had this many "epiphanies"/been surprised this many time at a test conference since... one of my first ever.

Next question is: Why? What made me get all those epiphanies?

Well, I've rewritten my explanation to that I don't know how many times now. It boils down to things I can't seem to describe well enough yet but I'll give it a shot in a separate post, probably after a Transpection Tuesday (I need your brain Helena).

So, let's skip to the good stuff: Content and lessons learned.

Credit

Before we start: Credit for the content below goes to all the participants of SWETish:
  • Agnetha Bennstam
  • Anders Elm
  • Anna Elmsjö
  • Björn Kinell
  • Erik Brickarp
  • Göran Bakken
  • Johan Jonasson
  • Kristian Randjelovic
  • Morgan Filipsson
  • Tim Jönsson

Talk 1: All Pairs by Morgan Filipsson

Morgan basically described a tool he thought was more or less obvious and most of us went like: "mind blown"... it felt a bit like Paul and Karen in the K-card story. It was just a simple non-mechanical combinatorial testing support tool made in Excel where you could decide the input values you would use in a test and the program would help you by showing how many valid pairs (as in "all pairs") you had not yet covered. I don't know if this is exactly what Hexawise, or some other tool, already does but to me it was ingenious.

But this is a peer conference so why stop there; open season time:
  • Forming an unbiased opinion can be expensive and money does matter
  • Getting many peoples biased opinions and comparing them can help sometimes
  • Beware of decision fatigue when using exploratory testing
  • Improving your test strategy or moving towards a more formal approach can delay the decision fatigue process
  • Mind maps are cool but do have limitations
  • Don't underestimate pen and paper
  • Excel is a pretty bad ass testing tool
  • Remember data can come in many shapes and forms and it often has complex relations to other data
  • Sometimes the simplest of ideas are not obvious to others
  • There are so many potential benefits with screen recording

Talk 2: How we test by Anders Elm and Erik Brickarp

A bit unorthodox but a two person experience report at a peer conference. The background was I read Anders' abstract and realized we have a very similar test process at Verisure. So Anders described how they test at SICK, I described how we test at Verisure by focusing on the differences and at the end we shared our key lessons learned and challenges. Long story short: We had both started with the goal to implement SBTM (in my case credit should go to Maria Kedemo et al.) but in both companies this had diverged into something else. I described this new process to be much more similar to TBTM than SBTM.

I might talk more about this in the future but let's skip to the open season for now:
  • How much of this diverging is due to strategic decisions and how much is due to laziness/lack of competence (valid question that requires more thinking on my part)?
  • Internal demos after each completed user story and mob testing during these demos seemed awesome (done at SICK but not Verisure, where I work)
  • We got an interesting question from Björn Kinell about "if you could magically change/correct whatever you wanted, what would that be". I don't want to share my answer but my advice: Ask yourself that question cause it can help when forming a vision for your testing.
  • It's easy to forget/skip debriefs, test planning and testing not immediate related to a story in the sprint but be careful as these activities often provide quite a bit of value.
  • Find activities that are "not testing but still testing" to easier get the developers involved. Examples: Add testability, "try" the product and support a tester when testing.
  • Ask the question "how do we catch <very basic bug> before the product is handed over to testers?" to start a discussion in the team about testing and developer responsibility.
  • Remember that small bugs that normally don't slip through development/testing can be a symptom of a much bigger problem like stress, change in culture or lack of support.
  • Time spent improving charters is rarely a waste of time.
  • SBTM "by the book" in a scrum team is not easy...
  • If the timebox aspect (session) is removed you need to find new stopping mechanisms and/or heuristics to help you stop and reflect on whether or not to continue.
  • Debriefs can be useful for many many reasons.


Lighningtalks

Johan Jonasson spoke about construct validity in metrics
Anna Elmsjö spoke about finding and making allies
  • Candy solves most people problems (my wife approves)
  • Finding allies among the developers is important to help you get attention to testing problems
Tim Jönsson spoke about the value to "knowing your audience" when reporting bugs
  • There are more ways than an entry in a bug reporting tool to report bugs
  • Do highlight helpful developer behavior/good code and show gratitude when developers help you
  • Good lightning talks often focus on one thing and explains that one thing well!
  • A compelling story helps your audience understand your message
  • Testing is about psychology more that you might initially realize
  • Be humble, be helpful, be useful... and be respectful.
Göran Bakken spoke about how integrity can get in the way of efficiency
  • Refusing to do bad work is not always constructive
  • Two different ways to approach a change is to focus on supporting values or to focus on methods.
Kristian Randjelovic spoke about how analogies
  • There are many ways to use analogies to help colleagues with limited understanding of testing understand otherwise rather complex (testing) concepts.
A general lesson for me (even though I didn't present a lightning talk):
If I'm given 10 minutes for my talk and open season, I'll try to aim for a talk shorter than 4 minutes and only focus on one message.

Talk 3: Test documentation in the hands of a stylist by Agnetha Bennstam

Agnetha showed three different examples of how she had helped turn massive 200-page documents into lightweight, often visual, alternatives. It's hard to explain this in text but the running themes were figure out what is important, find the right level of detail and aggregate data in a way that's useful/enough for the receiver rather than show the full set of data.

Open season:
  • Dare to try something different!
  • You can add additional dimensions to a diagram by using the size of the dot you're plotting and color (see slide 55 in Andy Glover's presentation).
  • Use feelings when you test e.g. "why do I feel bored" as indication that there might be something you should react to/take notice of (see Michel Bolton's presentation).
  • Asking for people's gut feeling can be a good way to get their assessment without getting all the motives and data (makes people relax a bit).
  • Sometimes asking for people's gut feeling can help them "dare to answer" so that you can start to figure out what is happening e.g.
    "How 's the quality of ...?"
    "I don't know..."
    "But what's your gut feeling?"
    "Well, so far it's not looking good"
    "Why is that...?"
  • Gut feeling can sometimes mean "very useful and relevant information the person simply cannot/dare not articulate yet"
  • ... but gut feeling can also mean, or more often be interpreted as, "I base this on absolutely nothing but I don't want to admit that"
  • Beware of documentation existing only for the purpose of being ammunition/defense in a blame game
  • A tool that could clearly visualize:
    How fresh the testing is (time and impact of changes since last tested)
    How important the testing is
    How well the testing went (typically quality)
    ... would be cool.
     

Other stuff

One more crazy thing about SWETish: All the talks and open seasons were amazing and that's despite the fact that the experience report all organizers voted as their favorite... was not delivered since Joel Rydén got sick!

Another cool detail. Anna Elmsjö added a nice twist to the K-cards she created for the conference: On each card there was a short helpful sentence/statement/word at the top explaining the card a bit. For instance sentences like "I would like to add..." on a yellow card or "This is the most important thing ever!" on a red card, most were funnier than that but the funny ones I saw don't translate well to English. To make it even cooler she had different statements for every single card... Johan, I expect the same for Let's Test 2017 ,)


Summary

THANK YOU! This was one of the best conferences I've attended, I already look forward to the next one!

... and I hope I can bring some of SWETish awesomeness to PEST, a peer conference I'll attend in just a couple of weeks (we seriously need to work on how we name the various peer conferences by the way...).

29 June 2015

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!

13 April 2014

SWET 7, peer conference on test coaching

SWET 7 (Swedish Workshop on Exploratory Testing, a software testing peer conference) has just come to an end and here is the promised summary and lessons learned from the event. The topic this time was "test coaching".

Don't worry Sweden

First of all, knowing that SWET 6 had few attendees, SWET 7 was almost cancelled and the group that finally signed up had far less experience than groups from previous iterations; you might be concerned about where context driven testing is heading in Sweden. Well, don't! There's a ridiculously talented group of up-and-coming testers. I feel fortunate to have met some of them already!

The venue

Villa Mälargården was a great venue. We had the conference center all for ourselves, it was well set up and the chef's passion (and skill) was a perfect fit, both for our palates as well as for a conference with passion being a common denominator. Thank you Michael Albrecht for doing all the arrangements, you did an awesome job!

Intro

Before the experience reports (which I will call sessions by the way) we went through practical information like how to use K-cards, what goals we had as well as making a check-in. Interesting this time was James emphasized stating possible distractions during the check-in. In at least two cases this definitely provided valuable information; Michael telling us about illness at home which he later had to, very abruptly, leave to attend, as well as Annie telling us about her migraine and how that could affect her which made me better understand her reaction when I tried to start a couple of discussions.

Before starting, James also showed and explained his view on coaching, a great way to ensure we all had a common ground to at least refer back to as well as for many of us to better understand what coaching can be.

Session 1, Michael Albrecht

Michael Albrecht started by speaking about a consulting job where several groups within a company needed coaching and training to change their testing process.

Takeaways
  • Set the goals with everyone involved (e.g. manager ordering and participants), follow up these goals with the same group.
  • There are many aspects of coaching to look at (and improve); e.g. facilitation, set up/preparations, actual questions/exercises, follow up, session quality evaluation etc. 
  • Coaching is not necessarily a one on one activity.
  • Propose a radical idea and ask why it wouldn't be a possible substitute what's currently implemented, to force people into thinking differently/see beyond what exists.

Session 2, Erik Brickarp

I want to discuss this a little further with Helena Jeret-Mäe, whom I share this experience with, before posting. But it revolved around Transpection Tuesdays, how, and why, we've integrated more and more coaching into them, the format we use and lessons learned.

Session 3, Liza Ivinskaia

Liza spoke about her first test coaching experience and lessons learned from this.

Takeaways
  • Survey's can be used as a quick way of reaching out to a lot of people for some simpler coaching and/or as valuable input to coaching/coaching decisions (e.g. who to focus on).
  • Spend time with the people you are about to coach to make sure you understand their context
  • Make sure you focus not just on what's wrong but also point out what people are doing right
  • Presenter technique: Draw a big mind map (e.g. on a whiteboard) to help audience "navigate" your presentation. To enhance, create or highlight the connections as you present.
  • "Don't look at it as a problem, look at it as a challenge"
  • Everyone has coaching experience. You've most likely helped a friend/sibling/child/partner in a challenging situation or tried to help someone understand something in school for instance. Some of that is likely coaching.

Lightning talks

Annie Rydholm
Talked about her coaching sessions with Carsten Feilberg and how these have helped her.
  • Find out the missing "because" by asking "why"
David Högberg
Talked about his failed attempt to teach a student taking notes and lessons from that.
  • Taking notes is a vital skill we need to practice
  • We all take notes differently, teaching someone "their style" is hard
  • Take notes throughout the day and at the end of the day, collect them in a mind map
Björn Kinell
Talked about a mistake when coaching, where he had been too impatient to let the coachee figure out an answer for himself.
  • It's easy to get impatient and just give someone your answers. Coaching requires patience.
Amanda Johansson
Talked about how she basically made herself obsolete in a team.
  • Making yourself obsolete in a team is an interesting goal to get you to coach and help people take their responsibility in building quality in as well as finding bugs.
Meike Mertsch
Talked about her coaching session with James Bach and how what she learned unexpectedly became valuable much later.
  • You never know when and what experiences/knowledge will come in handy
  • Explaining exactly what you do provides insight for yourself

Lesson: "Innocent girls"

I heard at least three times, by different testers and in different settings, "I was surprised this innocent girl was so tough". I think that is an indication we should stop assuming innocent girl (or well, any girl) equals weak/fragile. My own experience in life is boys might be better at hiding/faking but we're not tougher.

Lesson: Admitting being human

I heard David Högberg in several open seasons, as well as in between sessions say things like "did you admit?", "it's okey to be human", "admitting can build trust" etc. He definitely hammered in a valuable takeaway from SWET: There is nothing wrong with being human, in fact it often helps strengthen relationships and build trust!

The mentor

I want to give a special thanks to James Bach. I had tremendous respect for the man who help me find my way into testing, already before SWET 7. But after seeing him work with all these rather fresh participants (including myself) he has raised my admiration even more. He inspired, he encouraged, he supported, he taught, he lead by example all and all, he did everything to make sure we all got the best out of every single participant, rookie or veteran (or at least that's my view). That on its own was a great and valuable experience for me in community greeting and group mentoring. Thank you James!

Summary

If you look closer you likely know/have experienced much more coaching than you think.

... and there are plenty of up-and-coming testers to keep an eye on!

Participants

These are the people who taught me the lessons shared in this post; all being curious, brave and smart testers, worth listening to.

Amanda Johansson
Annie Rydholm
Björn Kinell
David Högberg
Liza Ivinskaia
Mikael Ulander

Thank you!

23 January 2013

The year I became a passionate tester, part V

November 1st
Worth a special mention. The day was crazy for several reasons but three highlights:
  1. Securitas Direct asked for a second interview
  2. Invited to SWET 4
  3. My note taking post was retweeted by Michael Bolton (may sound silly but it was huge to me at that point)

RST (Rapid Software Testing)
RST started great, I was on top of my game, asking relevant questions, thinking, observing, reacting... all until the first break. I don't know exactly why but I lost track after that (had a great time anyway but was not happy with my own contribution to that).

When apologizing to James he responded:

I was going to say you should talk more.
First thing tomorrow you'll see something you haven't seen.
...
Well, don't worry about... or worry if you want, because I'm going to have you do the Mysterious Sphere problem.

I immediately scanned google, RST blog posts and other resources but found nothing.

A good ten hours of sleep made the trick and day 2 I was on top of my game again! Just before lunch James turned to me and said something like:

After the break we'll see Erik here, test the Mysterious Sphere, the only exercise that has made anyone cry during my class.

It was amazing! I still go "Ohhhh! That's why... I should have... what if... now I get it!" when I think about it. I'm forever grateful I got the chance despite my bad start!

Day 3 wrapped up an amazing experience! I left RST with my precious blue pouch (RST graduates will understand), new contacts, a raised confidence in myself as a tester and 21 pages of sketches, ideas and epiphanies. Thanks James Bach, Tobbe Ryber, Robert, Niklas, Per, Tiago, Layer10 and all the others that made this experience possible/invaluable! If you haven't participated yet I suggest you check out David Greenlees post on how he got to RST and schedule a meeting with your your boss!

Get the most out of RST:

  • Get there well rested (important!), the course will demand a lot of you.
  • Look up the word heuristic to make sure you understand it.
  • Show you want to be challenged (be active), it'll make the course even better.
  • Check out the RST slides before, I think that helped me stay focused on the discussions.
  • Don't care to print the slides and bring them to the course though, as slides will be skipped, order changed and the exercise slides are hidden anyway.
  • Faking will only lead to problems.
  • Read up on the Socratic Method (a low pressure example, expect more "pressure" in class)
  • Make sure you know how to get to the facility, have travel tickets in place etc.
  • Ask questions!
  • Drop the idea of finding the ultimate answer to the questions asked (important!). Most questions will not have one! Accepting that will help you both learn and contribute more.
  • Don't worry, things will just happen and you'll do great!
Thanks to Johan Jonasson, Joel Fridfjäll, Joel Rydén, David Månsson for contributing to the list together with James Bach, Michael Bolton and Paul Holland.

SWET 4: Intro
Please read Johan Jonasson's great post on SWET 4 for details on the event. Maria Kedemo has also shared some thoughts, especially check out the "what happens now" section, great reading!

After receiving my invitation I called Johan Jonasson:
- Am I really qualified for this?
- Go there and find out!

It was amazing! The presentations were interesting, the following discussions even more so, the lightning talks were cool and the people inspiring, I had the time of my life!

A funny thing: Maria Kedemo was presenting "Model based exploratory interviewing" or, in other words, her interviewing model when recruiting testers for Securitas Direct.

On the topic of switching roles: SWET started 2 days after RST ended, felt a bit weired to go from being James "unknown student" at RST to become his "peer" at SWET. Weired as in a good, interesting way I should add.

Want a quick reason why I think Securitas Direct and Sectra are two great companies for testers by the way? Both companies' test managers were among the 15 invited to SWET 4 (Johan Åtting couldn't come though and sent Joakim Thorsten instead).

I need a separate post to describe this crazy experience in any detail but one advice: If you ever get the chance, take it! I was really intimidated by the concept and merits of the other testers but as I arrived I quickly understood why great testers love peer conferences, you (can) learn so much! Going was definitely one of the best decisions this year!

One final advice: Prepare your lightning talks, I changed topic ten mins before walking up, the result was messy.

Special thanks to Torbjörn Ryber, Henrik Emilsson and Rikard Edgren for arranging this amazing event as well as giving me the chance, and thanks to Martin Jansson, James Bach, Sigurdur Birgisson, Sandra Camilovic, Anna Elmsjö, Johan Jonasson, Maria Kedemo, Oscar Cosmo, Saam Koroorian, Simon Morley, Joakim Thorsten... and myself... for helping them make it amazing!

New job
After interesting discussions, cool exercises and talks to potential future colleagues it was time to make a decision. In the end it came down to details; both Securitas Direct and Sectra have amazing testers, culture, test managers and products. Finally I decided to go for Securitas Direct choosing, what I interpreted, as the bigger challenge over Sectra's more helpful environment (all but one tester at Securitas Direct work in Malmö, not Linköping where I work).

Anyway, I think Joel Ryden (brilliant guy, test consultat at Securitas Direct and former employee at Sectra) summarized my situation quite well: "Whatever you choose it'll be a great choice". I'm thrilled to start my new job at the end of next week, something I'll talk more about in a later post!

Jiro dreams of sushi
This documentary is great enough to mention here. Watch it!

Kids
Finally... kids can smell when you really need sleep (like the day before RST and SWET). But at least that gives you a lot of time to hug them before you leave. Jokes aside, coming back from SWET 4 having my two boys rush into my arms was by far the best of all the cool things in November. Be passionate about testing but remember what's most important!

My boys pairing up to test/hack/crash a tablet.

Summary
November was crazy, feels like I've just mentions half the cool things that happened! Anyway, three key take aways:
  • Don't worry about if you're good enough or not, just get out there and learn until you are!
  • RST is a mind-blowing course that I recommend to every tester!
  • Practice putting thoughts into words (blog, reflect, join debates...), it's a critical skill to anyone, not just testers!

Starting level: Prepared
Finishing level: Self-recharging bomb of inspiration

12 November 2012

Lightning talk - SWET4

Intro
Last week included both RST and SWET 4. I have so much I want to share about these amazing experiences, not to mention all the inspiration, ideas and epiphanies related to the events. However, to start off I would like to just share a written, more complete, version of my lightning talk (SWET 4). After presenting it, people feedbacked I left out important information (extra credit to Henrik Emilsson for pointing this out in a great way). Hopefully this version solves any confusion.

The talk
During RST with James Bach I was staring at a long list of IP addresses. All of them shared some kind of pattern making a validation check fail but I just couldn't figure out what the pattern was. Here you can see a 3 row example of how the list was constructed (imagine dots between the numbers and you see IP addresses). Notice that the numbers in the example has nothing to do with the actual exercise, I just made them up right now:

203 176 15 117
74 101 255 103
65 18 247 0

At some point I started thinking about visualization and since I didn't have any better idea I just went crazy with the graphs in Excel. Most of these didn't provide any valuable information but two stood out:

With respect for the class I won't go into details but both the "boxes" in the first one and the "zig zag" in the second reveal useful clues to the mystery.

When looking at the graphs generated by Excel I also had an idea about a graph I didn't know how to plot. The idea was a box there each side represented one of the four numbers making up an IP address (0-255). By drawing a line from side to side a geometric four sided shape would appear in the box representing an unique IP address:
Example: The blue line would represent
an IP address similar to 40.180.110.80
starting at the top and ending to the left

Since this was during RST I asked James if he knew how to plot this. He said he probably could but we didn't speak more about it.

Some days later I met James again when attending SWET 4. He immediately showed me an exciting idea. The box apparently didn't reveal any useful information as a graph. However, if you instead drew your own shapes and used the IP addresses these shapes represented (same basic principle), it became an interesting way to generate test data and visualize data coverage at the same time. Brilliant idea!

There is a lot of things you can learn from this, the power of visualization being one. But I want to highlight three underlaying decisions I find crucial:
  1. When stuck, just do something
    Even if the graphs would have provided nothing, so would more staring. Just doing something can sometimes kick your brain into gear and give you new ideas (like the box graph for instance) so even when the initial act is fruitless it might get you forward.
  2. Don't overthink cheap tests
    I could have analyzed what kind of graphs to plot but plotting one cost just 2 clicks so why care? If it's really cheap, just do it!
  3. Share your ideas
    If I had decided not to ask James, the great idea with using the box as a test data generator would never had occurred. When something seems useful but you can't figure out when or how to do it, share it, cause others might!
Credit
In addition to James Bach, who played a key role in this, and already mentioned Henrik Emilsson, I would like to thank all the other SWET 4 participants for inspiration:
Torbjörn Ryber, Rikard Edgren, Martin Jansson, Sigurdur Birgisson, Sandra Camilovic, Anna Elmsjö, Johan Jonasson, Maria Kedemo, Oscar Cosmo, Saam Koroorian, Simon Morley and Joakim Thorsten. I had a blast!