EAST meetup - talking metrics

Yesterday's EAST meetup was focused on test metrics, starting with us watching Cem Kaner's talk from CAST 2012 and then continuing with an open discussion on the webinar and metrics in general.

Cem's talk
Cem talked about the problem to setup valid measurements for software testing and the work he presented on threats to validity in measurements seemed very interesting (you can read more about that in the slides). He also talked about problems with qualitative measurements:

• Credibility, why should I believe you
• Confirmability, if someone else analyzed this, would that person reach the same conclusion
• Representativeness, does this accurately represent what happens in the big picture
• Transferability, would this transfer to another similar scenarios/organizations

So far so good.

But Cem also, as I interpreted it, implied that all quantitative measurements we know of are crap but if a manager ask for a certain number you should provide it. In this case I agree we testers in general need to improve our ability to present information but, as I will come back to, I strongly disagree with providing bad metrics even after presenting the risks with them.

How do you measure test in your company
Everyone was asked: How do you measure test in your company. The most common answer was happy/sad/neutral smilies in green/red/yellow, which was quite interesting since it relates closely to emotions (at least as it's presented) rather than "data".

The meaning of the faces varied though:

• Express progress, start sad and end happy (="done")
• Express feelings so far, first two weeks were really messy so we use a sad face even if it looks more promising now
• Express feelings going forward, good progress so far but we just found an area that seems really messy so sad face (estimate)

In most cases some quantitative measures were used as input but wasn't reported.

My personal favorite was an experiment Johan Åtting talked about, where a smiley, representing the "mood" so far (refers to item two in the list above), is put on a scale, representing perceived progress (see picture). Seemed like a straight forward and nice visual way to represent both progress and general gut feeling. The measurements of progress in this case were solely qualitative if I understood correctly but would work if you prefer a quantitative way of measuring it as well.

Also a couple of interesting stories, both from the great mind of Morgan. First was an example of a bad measurement with managers basing their bonuses on lead time for solved bug reports. This was fine as long as developers had to prioritize among incoming reports but when they improved their speed this measurement dropped like a stone (suddenly years old, previously down prioritized, bugs were fixed) and managers got upset.

The second story was about a company where developers and "quality/production" (incl. testers) were separated. Testers in this case tested the components sent from developers in isolation before going to production. However, when the components got assembled tons of problems arised, problems customers reported back to the developers without quality/production knowing it. This lead to a situation where quality/production couldn't understand why managers were upset with bad sales, the product was fine in their view. The situation improved when Morgan started to send the number of bugs reported from customers (bad, quantitative measurement) to the quality/production department.

An interesting twist was later when they tried to change the bad quantitative measurement with something more representative and met a lot of resistance since management had learned to trust this number. I asked him if he in retrospect would had done anything differently but we never got to an answer.

I shared a creative test leader's way of dealing with number. She reported certain information (like test case progress and bug count) but removed the actual numbers. So when presenting for upper management she simply had visual graphs to demonstrate what she was talking about. As far as I know this was well received from all parties.

Finally an interesting comment from Per saying: "Often I find it more useful to say; give us x hours and I can report our perceived status of the product after that".

Epiphanies (or rather interesting insights)

During the discussions I had a bunch of interesting insights.

• Measurements are not a solution to trust issues!
• Instead of saying "we have terrible speech quality" or "the product quality is simply too bad" we could let the receiver listen to the speech quality or demo the aspects of the product we find bad. It's a very hands on way to transfer information we've found.
• Ethics is a huge issue. If we want someone to believe something we can (almost) always find compelling numbers (or analysis for that matter).
• Measuring progress or making estimations will not change the quality of test/product's state after a set amount of time (just as a reminder of what you don't achieve and the cost of measurements).
• If a "bad measurement" can help us reach a better state in general (like in Morgan's example), is it really a bad measurement? (touching on ethics again).
• When adding qualitative measurements to strengthen our qualitative measurements, are we digging our own grave? (risk of communicating: So it's not my analysis/gut feeling that matters, it's the numbers)
• How a metric is presented is often more important than the metric itself.
• In some cases brought up the measurements weren't even missed when not reported anymore.
• Don't ask what reports or data someone wants, ask what questions they want you to answer.
• Cem talked about transfer problem for students, making it hard for them to understand how a social science study can relate to computer science for instance. I think the same problem occurs when we move testing results into a world steered by economics (numbers).
• Even bad measurements might be useful to highlight underlying problems. Once again Morgans examples somewhat shows this and Per talked about how more warnings in their static code analysis was an indication programmers might be too stressed (if I interpreted it correctly). In these cases it's important to state what the measurement is for and that's it's just a potential indication.

Measurement tempering

We talked about how we easily get into bad habits/behavior when quantitative measurements becomes "the way" to determine test status.

Bad behavior when measuring test case progress:

• Testers saving easy tests so they have something to execute when the progress is questioned
• Testers running all simple tests first to avoid being questioned early on
• Testers not reporting the actual progress to avoid putting too much pressure on them or to fake progress to calm people down.
• Testers writing tons of small simple tests that typically test functionality individually which creates a lot of administrative overhead as well as risk of not testing how components work together, this to ensure a steady test case progress.
• Test leaders/managers questioning testers when more test cases are added (screws up "progress"), as a result, testers ignore broadening test scope even when obviously flawed.

Bad behavior when measuring pass/fail ratio:

• Ignoring bugs occurring during setup / tear down.
• Slightly modifying a test case to make it pass (making it conform with actual result rather than checking if that's a correct behavior).
• Slightly modifying a test case to make it pass (removing a failing check or "irrelevant part that fails")

Culture

We also talked about how the culture (not only related to test measurements) in various countries affected testing. One question was: Why is CDT so popular in Sweden. Among the answers was low power distance (Geert Hofstede, cred to Johan Åtting), Law of Jante and that we're not measured that much in general (i.e. late grading in schools, not grading in numbers etc.).

We also talked about drawbacks with these cultural behavior (like hard to get to decisions since everyone should get involved/agree).

Finally, and mostly, we talked about how our view on testing and measuring sometimes collides with other cultures, with actual examples from India, Poland and the US. This discussion was a bit fragmented but feel free to grab me if you want to hear about it.

Summary

This was a great EAST meetup and I really feel sorry for the guys I know like this topic but couldn't attend. Definitely a topic I hope (and think) we'll get back to!

Finally a lovely quote from Magnus regarding a private investigator determining time to solve a crime:

"Let's see, there are 7 drops of blod, this will take 3 weeks to solve".

Good night! .)

EAST meetup - Trying a new format

What is EAST
Short version: EAST is a local network for software testers in the area I live (Linköping, Sweden). About once a month we meet to share thoughts, learn and socialize/network. If you want to know more you can read my post from my first EAST meetup.

New Format / Concept
Most previous meetups have followed the format: Start with food and socializing, then 1-2 presentations, each followed by discussions. A few other formats have been used, like letting each participant shortly describe how testing is performed at his/hers company (try to get everyone involved), testing games and the pub evening with only beer and socializing. This time some hands-on testing was on the menu.

Webinar
As usual we started with food but instead of casually chatting with each other we together looked at the Six Thinking Hats for Software Testers by Julian Harty (referring to Edward de Bono's thinking hats). The webinar was interesting but I missed the social part. Maybe a 5-15 minutes long webinar would have worked better for me.

Hands on
Second part was hands on. First David, the facilitator, quickly presented the application we were to test and how to get it. The application in this case was an app for taxi drivers to help them keep track of their work (part of a full system for taxi companies). Second we would, in groups or alone, test the application using the six thinking hats in any way we saw fit.

First I and a former colleague from Ericsson started out exploring/scouting the app but soon felt we didn't get any momentum and joined another group of three. A vivid discussion on how to use each hat and what fitted where ended with us being ready to actually start generating test ideas about 5 minutes before deadline but that didn't matter, at lot of interesting stuff came out of the discussions.

Sharing results
When we were back together we started the sharing of ideas and experiences from the hands on part. Immediately it became clear the various groups had used the hats very differently.

We attacked the whole app and used the various hats from the perspective of an actual user (or rather our made up view of how it was to be a taxi driver, lesson learned: better understanding of the user; for instance its needs, knowledge and general behavior, would have helped a lot). This perspective gave us an interesting high level view but it was a bit hard to stay focused as we often drilled down too deep exposing too many details. Others focused on a smaller part of the app which, in this case, seemed a lot more efficient.

Of course how to use the hats would depend on the mission in a real life scenario but in this case the mission was not set like that, the goal was just to try out the hats and learn from each other's way to approach the hats and for this, our perspective took a little too long / became a bit too complex, at least for beginners like us.

Wrap up
To wrap things up we had a more general discussion about the hats and format.

A few thoughts about the hats:

• In this scenario we had no problem coming up with ideas quickly and the hats initially felt more limiting than helping. In a situation where we would have been stuck or at least worked with the product for a bit longer, the hats would probably had been more helpful. This might also change as we get better and better at using the hats but only time can tell how that turns out.
• Keep using the hats on items already identified would probably render interesting results. For instance first we could use the white hat to identify a data item, say cars in the Taxi app, then we could use the hats on this item to identify risks (lack of cars), opportunities (more efficient usage of cars), new data (various types of cars), feelings (lust to drive fast), "darkness" (breakage, with passenger in the car) and ideas (what if the cars were any kind of vehicle, like bicycles or trucks, what other users could then benefit from the app). Continuing to apply the hats on each new item added would help to dig really deep down.
• The hats would be interesting to use on the product elements or quality criteria categories described in the RST Appendices.
• You should be able to visualize the findings quite effectively using a mind map.
• The hats could be a great tool to help refining, populating or creating a model.
• Someone suggested it could be useful to help explaining the various parts of testing to, for instance, a programmer (not sure I understood this correctly but as I interpreted it, it could be used to help them understand the wider "find valuable information" perspective rather than the narrow "find faults" perspective of testing).
• If you're not stuck yet, starting with no particular hat and instead just add stuff wherever it fits in the beginning might be a more efficient way to start (possibly changes when you're more use to the hats).
• The hats were helpful to find more non functional aspects to test.

A few reactions to the format/execution itself:

• Generally people seemed to have liked the format a lot.
• We had some troubles understanding the app's usage/user. Using a known application (like MS paint) or object (like a chair) might had been better ways to understand the concept of the hats. On the contrary, using this app forced us to do some scouting and work with assumptions which broaden the ways the hats could be used.
• Like I said before, the webinar was a cool way to mix it up personally I missed the regular chatter while eating. Still very cool so a shorter webinar might be perfect.

Finally it was fun to just study my group during the hands-on part. Let's just say we had very different ways to attack the problem (relentless scouting, analyzing the input information or quickly getting a set of data to work with for instance).

Thanks!
Thanks to David Månsson, Aveso, who facilitated this meetup in a kick ass way! Also thanks to all the participant for sharing interesting thoughts. Looking forward to future experiments, this one was definitely a success in my book!

The year I became a passionate tester, part VI

December
The only (but really cool) event that occurred was Securitas Direct/Verisure's christmas party. It was hosted in their beautiful office in Malmö. Can't say I'm jealous, I mean, who wants a workspace with ocean view in three directions? Well, maybe, at least I got over it and had a great time with future colleagues, including one of the two guys who'll be on my dream team in Linköping (not putting pressure on anyone). The only new year's resolution I'll make by the way is coming dressed up next year (costume party).

Apart from that, December was mainly a month of reflection, Twitter and family life. Via Twitter I started to get in contact with some really cool testers like Jari Laakso, Kristoffer Nordström and Jean-Paul Varwijk. Via reflections I started to grasp/understand/better appreciate my progress as a tester this year (reason for this blog post series) as well as wrap up the work done by me and my colleague at Ericsson. Cool things that need separate post(s) to really do them justice.

Wrap up of 2012
So, 2012 was an amazing year, when it started I considered testing being an activity that mainly demanded endurance, patience and the ability very rigorously read technical documents (all skills/traits/knowledges I'm definitely not famous for, at least not in a good way). Now when 2012 has come to an end I value a whole bunch of other skills/traits/knowledges instead like observation, creativity, general system knowledge, analysis and communication. I now find testing adventurous and exciting rather than a repetitive routine work.

I've also met a ton of amazing people! Some have been thanked already but of course there are tons of you who I've not even mentioned. I will not attempt to list you all, instead THANKS TO ALL OF YOU WHO, IN ONE WAY OR ANOTHER, HAVE HELPED ME ON MY JOURNEY!

Some special mentions left to do:

EAST
EAST is a local open network (Linköping area) for testers, started by Johan Jonasson and Johan Åtting. When I started to look at its role in all this I realized:

• EAST was the place there I got convinced I needed to attend RST.
• EAST was the reason I picked up LinkedIn and without LinkedIn I would not had come in contact with Maria Kedemo (new job).
• Speaking about job, I met Johan Åtting via EAST, that was the other amazing job offer this year.
• EAST was one of the big reasons I started blogging (first test related post is about my first EAST meetup).
• Johan Jonasson, Johan Åtting, Joel Rydén and other EAST participants have all been role models and sources of inspiration, key to last year's events.
• EAST became the crucial link between the testing world existing at my work and the testing world existing in the rest of the world.

I could go on but let's just say I'm forever grateful for EAST and I hope I can inspire/help other participants to start similar journeys. Thanks to all who have participated or in other ways contributed!

Blogging
Starting 2012, blogging to me it was more or less just a poor narcissistic attempt to make something hopelessly uninteresting, interesting or it was something used by the top elite within a business to share their ultimate knowledge about something. At the end of 2012 I tell everyone who wants to progress to blog, not for anyone else's sake (that day will hopefully come) but for their own personal development. Blogging has taught me the value of reflection, greatly improved my ability to put thoughts into words (which is essential to understand, analyse and explain something), it has generated new perspectives, changed priorities or given me a more sensible view on some things, it has improved my English, my writing skills and my "technical storytelling".

Later when some of my blog posts became interesting to other testers it became a great way of getting in contact with other testers, getting feedback and acting as a portfolio. From my heart I urge you to try it out, not, to repeat myself, to become famous but to develop yourself!

Work
I undertook an amazing adventure at work that just didn't fit the format of this series. It didn't include dragons, fairies and elves but, considering how we traditionally have worked with testing, it sometimes felt just as exotic. Some day I'll blog about it but for now I just want to thank my other partner in crime, Saam Eriksson, a passionate, smart tester I hope will continue and further improve our work now when I leave Ericsson (3 working days left). You've meant a lot to me and my development this year Saam, thank you!

Everything comes with a price, dearie
24 hours a day, that's one of few hard constraints we have in life. During these hours we should rest, eat, take care of family and friends, work, take care of ourselves, develop/follow dreams, follow through on commitments, manage everyday activities (pay bills, clean up, get to and from work etc.)... and probably other things I've missed. This constrain is a huge pain in the butt, especially if you, like me, have very many things you love and want to explore.

A few thoughts and lessons from 2012 about managing this puzzle:

• If you have kids, make sure you put them in the center of the puzzle.
• The puzzle won't (in a good way) solve itself when there is an overflow of activities.
• Each piece can be optimized (value/quality per time unit) by observing, reflecting, analyzing and prioritizing, but you need a balance there as well (premature optimization is the root of all evil, you know).
• The usually extrovert me quickly becomes introvert (not in the positive way) when I don't feel I have enough "me-time" and that affects all parts of my life.
• It's easy to be blinded by your own passion but don't forget there are other things in life like friends, family and yourself.

I survived the end of the world, here I come 2013!
This year couldn't have come to a better start as my two fantastic boys got the most amazing little sister 11:10pm, January 1st.

Things I know will happen 2013:

• New amazing job at Securitas Direct/Verisure!
• Let's Test 2013!

Things I feel motivated to do now and thus might do during 2013:

• BBST Foundation course
• Reclaim my presentational skills
• Connect with more testers on Skype
• Figure out how to get more out of reading (or start prioritizing other learning activities over reading)
• Be a speaker at some testing conference
• Try Skype coaching (as a student, had a taste of it thanks to Peksi)

Things I aim to continue with:

• Be an active blogger
• Be active in EAST
• Practice/play/experiment with testing
• Experiment with my learning
• Meet more testers in person

Finally, and foremost, I will continue enjoying my life as a dad!

Blog series wrap up
Thank you for reading this, if nothing else it has inspired and taught me a lot! If you want to start a similar journey like mine, feel free to contact me for help, tips or mentoring using comments on this blog, Twitter (@brickuz) or any other way you figure out.

Finally there are two more people I need to thank:

First, my fiancée. Among the million reasons I have for that; thanks for supporting me, inspiring me and being an awesome mom to my kids! Thank you, thank you and thank you!

Second, myself. This was at times a rough ride where I had to stand up and take responsibility for my actions to be able to continue, make sacrifices, take risks and really challenge both my ego and fears to succeed. Thank... me... for this journey!

2013, here i come!

Previous (part V)
First (part I)

The year I became a passionate tester, part IV

October
I've covered January to September in three posts. October and November however were way too eventful to keep that tempo so this post will only cover October... just in case you're puzzled by the headings (they are not months in some ancient calender).

Work opportunities
With two days apart, immediately after I had made myself available to job offers, I was contacted by possibly the two most interesting companies I could think of (from what I could tell; great culture, interesting products, passionate testers, top notch test managers and the right location). First Maria Kedemo, test manager at Securitas Direct, asked me to consider a job opportunity they had announced several months before but not found a candidate for yet. Second, Johan Åtting, test manager at Sectra, and I had a discussion regarding my RST situation. Somewhere in that discussion he asked me to send an application. I was on cloud nine! I'll tell you how it turned out in part V...

Some thoughts on improving your chance of getting great job offers:

1. Learn to test
   Practice, practice, practice
   Explore, experiment, play
   Read, watch and listen to great testers
   Get a mentor or ask for coaching
   Ask for help when you need it
   Courses, webinars, books
2. Create a portfolio
   Start a test blog or website
   Share your story (or CV if you're boring like me)
   Share your work and experiences in whatever way you prefer
   Create a LinkedIn profile
   Create a Software Testing Club profile
3. Broaden your network
   Be active in your local test community
   Socialize with testers on Twitter
   Start connecting with testers on Skype
   Go to a conference
   Be open to receive mentoring, help or coaching
4. Get some reputation
   Be a presenter
   Accept challenges (like testing puzzles)
   Mentor or coach testers
   Answer questions on, for instance, test forums
   Make relevant comments on blog posts and articles
   Host a meetup, conference or similar

Course
Instead of the Rapid Software Testing course, my employer sent me to a centrally purchased course, arranged by test researchers from MDH. As I didn't share the course instructors' opinions about testing it provided a great opportunity to practice challenging ideas as well as arguing for my own. Some examples of things I challenged was that a model had to be an actual simulation (James Bach would go bananas if he met the instructor for that part of the course), how exploratory testing is presented in the agile testing quadrants (see picture below) and the idea of having automation as a goal. To give the course some credit, it did teach me the theory and formal names on some stuff I already used, like equivalence partitioning.

The agile testing quadrants, I stay skeptical to this...

In the end I got a certificate which I would have received even if I had sat quiet, understanding nothing, for four days (unrightfully it wasn't in endurance).

Some thoughts on how to get more value out of a (testing) course:

• Ask questions as soon as you don't understand something or how something is relevant
• Reflect on why you disagree with ideas presented and try to express it (challenge)
• Practice constructive feedback on the instructors
• In your mind, try applying the ideas presented to your own context, does it make sense? Why not? Can you think of a context where it does?
• If you have a colleague attending the course, reflect on its content together afterwards
• Experiment with the stuff you've learned to make it stick

My first hosted local meetup
I had joined all the EAST meetups since I first heard about the group in May but, apart from calling to a pub evening, I had not hosted a meetup. That changed in October as ~20 testers gathered in a conference room at Ericsson discussing testing in an agile context, CAST 2012 and various other topics. Apart from almost having to squeeze in 20 people in a room designed for 8 and giving everyone the wrong address, it all went smooth. Definitely something I would like to do again.

Some thoughts on facilitating a (local) test meetup

• Facility: restaurant/pub, talk to your employer, check for a sponsor
• Inform: colleagues, other contacts (use consultants), LinkedIn, Twitter, flyers
• It's always nice to have at least one friend/colleague you know will show up
• Use any existing group (if no test group is available use an agile, craftsmanship, developer or other similar group) to spread the news
• Scout: attend other meetups (test related or not) and conferences
• Content: some (emergency) discussion topics are nice
• Content: watch an online presentation together is an option to a live presentation
• Don't worry about what people will think. The initiative is more than enough to please most!
• Make things interesting by experimenting!

The blog post
To prepare myself for RST I did, as I often do, experiment with a way to practice what I wanted to learn. The big difference this time was I blogged about it (Practice: Note taking). I had not anticipated the response. People retweeted it, started following me on Twitter (well, some quit after a while but anyway .) and old posts suddenly had their number of reads doubled and tripled.

Some blog tips from a newbie (most based on other blogs I like rather than my own):

• Share your experiments
• Share your experiences
• Share your mistakes
• Share your problems and ask for help
• Share your insights
• Share your ideas, but putting them into practice first will probably be more appreciated
• Be brief
• Tell a compelling story
• Don't force-feed people with your posts, especially your not so great ones
• Ask yourself: How is this relevant to someone else?
• Ask yourself: Why is this important to me?
• Use pictures/visualizations to communicate more (I'm great at this when presenting, I suck at it in my blog)... it's also more fun.
• Uptight blog posts are shot on sight, relaaaax, it's sexy to be vulnerable. 
• A blog post is an efficient tool to help reflecting (this was an amazing experience for me)
• Use headings and lists to make stuff more readable / easier to get an overview

Pekka Marjamäki
James Bach praised "Peksi" during an RST course in Finland so I looked up his work, was impressed and started following him (blog and Twitter). Soon after he found my Why I've signed up for RST instead of buying a kick ass sofa and new computer post and he contacted me asking if I would like to try an exercise as a warm up for RST.

The exercise was about him claiming something (in this case "Programmers can't test their own code") and my work was to, by only using questions, convince him he was wrong. I didn't fare that well as the mission goes (I had a strategy, that he gave me credit for, but let's just say it wasn't efficient) but I learned tonnes! I am forever grateful for his help and I hope we can do something similar soon again!

Finally I think Peksi's initiative says a bit about the context driven testing community in general. If you want to develop as a tester, just reach out and people will help you! To me there seems to be more teachers than pupils so help out by asking for help.

A few ways to get in touch with great testers

• Twitter
• LinkedIn
• Local meetups
• Conferences
• Comment on blogs
• Write interesting stuff in your own blog
• Colleagues
• Software Testing Club
• Skype

Summary

October was in a sense a preparation step for the events in November, but as you've hopefully acknowledged by now: the journey is just as important as the end goal. See you in part V!

Starting level: Committed
Finishing level: Prepared

Previous (part III)
Next (part V)

The year I became a passionate tester, part II

Please read The year I became a passionate tester, part I before you read this post.

May - Reaching out
When I was young (about two years ago) I started a blog. It was in Swedish, the topic was "make me famous" and it was gaping empty. In May I decided to pick it up again so I started writing a few posts, cursed myself for not being a brilliant writer anymore and finally translated the least horrible parts to English. My hope was that writing would somehow magically improve me as a tester and make people love me (I keep presenting myself as the loneliest man on earth).

The latter didn't really work out, the former though, even with the lack of magic, was spot on!

• Putting thoughts into words is a crucial skill! I'll explain why when we get to November but for now, just shut up and believe me.
• Helps you spot gaps and problems in your reasoning.
• Helps you raise questions you previously weren't aware of.
• Great practice to become a better observer.
• Great practice to better present your results.
• The comments you get can be provide key insights.
• Helped me learn to write in a more concise way.
• When writing down a problem the solution has a tendency to just show up (a bit like when you ask someone for help and as you put the problem into words you realize the solution... but without the someone).
• A good blog is great to point at when applying for a job.
• Writing skills are always important.
• Helps you process things you've learned/experienced.
• Helps you realize you're progressing.
• Writing a post you feel really good about helps boosting motivation.
• Sharing your experiences will put you in contact with interesting testers.

A few links if you need more encouragement
Why Every Professional Should Consider Blogging
Writing a Technical Blog: Why to do it and what to write about
Why must you write a technical blog?
7 Reasons Why Blogging Is Still Important in 2012

But the blog was actually not the most important initiative in May...

I chickened out on Let's Test but thanks to that conference I started following Johan Jonasson. One day, late in May, he made a retweet that would completely change the rest of this year. The tweet was about an EAST meetup in June. I joined the LinkedIn group and signed up...

June - Meeting non-imaginary people
EAST is an open network for software testers in the region I live in (Östergötland, Sweden). Once a month they meet up to listen to presentations and discuss testing in general. Going there was amazing! For the first time I was surrounded by brilliant, passionate testers, just the kind I wanted to become myself. Even though they gave me serious Let's Test envy, not to mention Rapid Software Testing envy, I loved every second.

Taking the step to meet others weren't really intimidating to me but, since I'm aware I'm an extrovert, I imagine it would be the challenge of a lifetime to some. If it's any consolation I was greeted warmly and helped along the moment I stepped through the door and I'm sure that's what most meetups look like. If still intimidated, try getting a colleague to join as well. I can tell you, if you make it there, it will change the speed you progress and your motivation in ways you can't imagine! Even if you just go there and listen you'll pick up so many interesting insights just from how great testers talk about and approach testing. When you build confidence enough (or, as in my case, can't shut up) you'll also discover a great chance to get quality feedback on your own problems as well as the power of having your ideas tossed back an forth between smart people. Finally, making friends that have a great interest in what you do for several hours a day is kinda awesome.

... Ohh, one more thing I forgot to mention. Other testers will love to hear about what you do, what you've experienced and how you deal with testing at the company you work so don't worry about being the quiet one, no one turns attention to, people will (maybe that was more intimidating than encouraging).

Other meetups in Sweden (Please send more suggestions)
SAST, Stockholm, Göteborg, Malmö, Örebro, Värmland
Passion for testing, Gothenburg
ConTest, Malmö

Inspired by the meetup and a brilliant presentation by Tobbe Ryber (unfortunately the slides seems to have been removed from the Nordic Testing Days' homepage) I created my Skill Development List. First it was just a silly list to make me feel good about my accomplishments but soon it turned into a tremendous resource for motivation and direction. I really urge you to make a similar plan and keep it updated as you progress, it's valuable no matter what level you're currently at! (ignorant people are the only ones dumb enough to ever be done learning).

I'm kind of an eccentric person when I really put my mind into something (like that's not already obvious). So, since i couldn't wait for the summer to end, I tackled the fear of screwing up/be rejected and planned an EAST meetup myself. However I choose a pub instead of a conference room to up the odds of people forgetting any bad parts (worked by the way). It turned out just fine and was a great boost to my confidence! Most important lesson? It's not hard to arrange a meetup, it just takes some courage (the initiative itself is enough be appreciated, a great end result is just a bonus).

Mindset
Hey, mindset is not a month! Maybe not in your calender... Screw it, no it's not, but it's crucial.

My mindset about testing, learning and thinking has changed a lot during this year. Here are some key mindsets that have helped me tremendously:

• I demand certain standards and am ready to fight for and make sacrifices to uphold them. I no longer accept fake work, low quality efforts or unmotivated constraints.
• I'm responsible for the environment around me, I don't expect anyone else to fix it for me.
• I don't fake understanding. Even if a question might hurt my status I need to ask it if I don't understand, simply because I want to be a pro not make others believe I'm a pro.
• I accept challenges even when public humiliation is almost guaranteed because I know challenges can teach me so much.
• I always perform tasks the best I can, even when it's not demanded, because I want to be proud of my actions.
• I accept that, even though proud, I will never be fully satisfied with my results because I will always be on the lookout for improvements.
• I won't accept to save myself by using silly excuses, blame others or hide behind papers! When I've done a bad job I'm accountable for that.
• I will not limit myself by what's considered taboo. If I find great potential for improvement and no one can come up with a valid reasons not to I will practice "professional disobedience" if necessary (break rules, within reasonable limits, to allow going forward).
• I will not pretend I've done a good job just because someone else says so. If I feel I've faked something it's a personal failure, nothing can change that.
• I want to empower and inspire the people around me by helping out, drive ideas, be a role model, spread my knowledge and support good ethics.
• I listen to anyone interested in sharing their experiences and I try to help them build on those but the latter is secondarily to the former.

Most of them are far from second nature to me yet (I still fake understanding and make up excuses for instance) while other more or less are (most notably high standards, which I'm really proud of). When some of these start to become your most important guides all the things around like respect, knowledge, skill and motivation will come by itself and it won't even feel like you're putting in an effort, that's why this is so important.

Insights so far

• The scariest, most challenging actions often present the greatest reward.
• The initiatives you don't take are the ones that will haunt you forever (why didn't I sign up for Let's Test, why?!). Failures? If nothing else they make great stories.
• Share your experiences with others, it helps making valuable connections, get feedback/insights/new perspectives and it helps you learn to explain what you're doing.
• Blog, blog blog
• Great testers won't ignore you, they will embrace you!
• Plan a local testing meetup, it will be educational, earn you respect and is a great confidence booster.
• Passion, inspiration and motivation rubs off, meet passionate people to become passionate.
• The sooner you meet great testers the sooner you'll become one yourself.
• Mindset, mindset, mindset
• Get yourself a plan of what you want to do (Skill Development List) and how you want to act (the list of mindsets further up).
• <<all the items on the mindset list>>

Starting level: Knowledgeable but incompetent

Finishing level: Inspired

Previous (part I)
Next (part III)

EAST pub evening

Knowing that I sometimes rush into things and generally can become a bit over-engaged (worst case ruining the balance in a previously well working group), I was quite anxious after suggesting a pub evening for EAST just a month after finding the group/network. Luckily it turned out just fine with, once again, lots of ideas and inspiration to bring home.

Anyway, the evening started at six o'clock and ended (at least for me) four hours later. All and all we were 8 or 9 people and topics ranged from molecular gastronomy and parenthood to a wide range of software testing related subjects. Also quite a few comments were made regarding the different choices in beer (or in the single case of not choosing beer). As usual (always?) the majority of the participants were from Secra.

I intend to dig down a bit into some of the subjects we talked about when writing these summaries but I really need to get a notebook and make sure to bring it cause for some reason I don't remember too much about the specifics from yesterday (only two beers so shouldn't be that... I hope). I'm pretty sure though I'll go "ohh, yes, now I remember" the day I really need to.

Anyway, after the initial "who are you, where do you work, what do you do" questions, I and a former Ericsson colleague talked a bit about the problems we faced testing a humongous product, with huge simulators, stone age code base and no clear end user. We compared it a little bit with testing other products and also touched upon the automated testing subject both in this particular product as well as in the other companies represented. Don't have many conclusions from this but it was interesting laying out many of the problems.

Another subject we talked about was scrum and mainly the scrum master role. In one company the role were rotated and kept very light weight compared to a very team leader like role in another (with a third in between). We discussed the benefits and problems with rotating and, at least my, conclusion was that as soon as the scrum master role stops being very light weight it's hard to rotate and when the risk of making it a heavy weight team leader role is imminent. You could also turn it the other way around saying as long as the role is rotated the risk of making if heavy weight is less likely. We also talked about a company where scrum master was a full time job and one scrum master could be responsible for one to three teams depending on skill. The idea was interesting as in weird and something I hope never will happen at my own work. Finally we talked about the different approaches to being scrum master where some (not necessarily the participants) considered it a prestige role while others considered it an interruption in the daily work and also how it differed being scrum master as a consultant compared to an employee at the company.

To wrap up the subjects, we talked quite a lot about the responsibility for test, the interesting path of learning programming and testing quite simultaneous so you're neither a top grade programmer nor a top grade tester but a top grade "something in between", we talked about the danger when all responsibility for testing is put on testers (especially in programmer heavy organizations), we talked about how cognitive science is a valuable skill to all testers and how students in cognitive science with computer skills were highly sought after as software testers, especially by consultant firms. Well we talked about tons of other stuff (respect for test, lack of testing skill for newly graduated students, problems with experienced testers with very little testing knowledge etc. etc. etc. etc. etc.) but let's stop here for now.

Finally Bishop's Arms were a great place; quiet, spacious and great selection of beer. Credit to Johan Jonasson for suggesting Bishop's and to Frida Brantvall for discarding Johan's other suggestion. May be relevant to add that the level of noise apparently were a lot lower than usual thanks to the great weather (most people were sitting outside).

My first EAST meetup

Yesterday I attended my first EAST meetup here in Linköping, Sweden. I met some amazing people and left with loads of inspiration.

But first things first: What is EAST?
EAST is an open network for software testers in the Linköping area, focused on Context Driven Testing. The group's main forum is a LinkedIn group but they also have a Twitter account in case only knowing about the actual events is enough. Apart from the online presence the group arranges meetups roughly once a month with about 15-20 participants. The group consists of well known testers like Johan Jonasson and Johan Åtting as well as newly graduates.

Anyway, this post was about my own experiences so here we go. As soon as I entered I was warmly welcomed and discussions regarding what I and others did started. When everyone finally had arrived we ate together (ordered pizza, not more glamorous than that) and the discussions continued with subjects like values in testing, skills/education and how to spread the knowledge of what we do.

After the food Hanna Germundsson presented her master thesis (or rather results so far) on testing in an agile environment, with a long interesting discussion as the result. Both the presentation and discussion gave me lots of valuable insights and thoughts on subjects like how to educate testers, if it's possible to measure test progress in a useful way and if it's possible to estimate required test time/effort. I also signed up to participate in an open discussion Hanna would arrange to use for her master thesis, something I'm really looking forward to.

Finally the participants who attended Let's Test 2012 talked a bit about their experiences, memories and learned lessons from the conference. If I weren't enticed enough to attend Let's Test 2013 I definitely am now. Just keeping my fingers crossed that the education budget will allow it (not looking too promising, especially not if I, as I've already requested, get to attend RST with James Bach i November, but I'm sure it's possible to solve). Morgan also provided us with a great two minute summary of Rob Sabourin's  Just in time testning presentation on Let's Test.

To summarize; this was a great evening and today I felt really inspired when I left for work. I will definitely attend the next meetup if it doesn't conflict with something really important (with no more kids on the way I doubt that will happen). Hopefully I'll be able to bring a couple of curious colleagues with me as well.