Passion-Driven Community

Roughly a week ago, I participated to my first testing conference. The conference was called Let’s Test and it was held in Runö, Sweden (30 minutes from Stockholm, with a taxi). If you want to know more about it, I suggest you go to their website: http://lets-test.com/

I knew in advance, that the conference would include many of the biggest names of our industry (e.g. James Bach, Michael Bolton, James Lyndsay, Johanna Rothman, Scott Barber, Pradeep Soundararajan, Fiona Charles, Griffin Jones, Julian Harty, Iain McCowatt). There were also a lot of people, that I had discussed with on Twitter, but had never met. In the end, many of these people held sessions, tutorials and keynotes.

If you are interested, I wrote a blog post before conference. There I experimented with Edward de Bono’s Six Thinking Hat approach to Let’s Test conference (especially the value I would gain out of it – and fear of not gaining value out of it). You can find the blog post here: https://flowoftesting.wordpress.com/2013/05/10/338/

Passion

I think the word passion describes extremely well, why I ended up in Runö with testers around the world. I have a passion for testing, which means, that I constantly seek for ways to evolve as a tester. I’m just guessing here, but I’d assume that people who came up with the idea of Let’s Test (Henrik, Johan and Ola – Ola sadly passed away in October 2012 and I never had the chance to meet him), were also thinking of ways to evolving our craft. What better way of doing, that than gathering many of the experts of our craft and arranging a place with spectacular nature, food and activities. Rest is magic.

It might be my subjective opinion, but I feel, that passion feeds passion. When I talk to people, who are as passionate (or more) as I am, it affects positively to my passion. Interacting with various people who shared my love to testing, left me a smile, that lasted even when I left Runö after the conference.

Who were these people you might ask? I’ll share few, that were special from my perspective

Monday

Seeing the people of our Context-Driven Testing community, started from the airport of Arlanda (unless you count meeting up with my colleague on Helsinki-Vantaa airport). In Arlanda I first met Ru Cindrea, whom we had agreed to share a taxi with. Ru is highly influential Romanian tester at Finland, that is evolving to Test Lab expert (she might already be there actually). I’ve met her few times before, and if there’s someone out there, that I believe can walk the walk, that’s her.

We had also agreed to meet Kristoffer Nordström on Arlanda. Kristoffer was also one of the people I knew the most through Twitter. We had agreed to participate to LetsTest Lab with Jari Laakso and Geir Gulbrandsen. Kristoffer currently works as a test developer and he had also helped me earlier (by creating a python script for tailing a log file in Unix). I had not met him before, but his talk on Lean Tribe Gathering 12 (http://www.youtube.com/watch?v=Iclr1MZzC-s) gave me the impression, that he’s a passionate tester. After struggling with finding each other, we finally met Kristoffer and took the taxi to Runö. There was funny incident with the navigation software, on the taxi we picked. You can see it from this picture (took by Kristoffer):

20130520_075119

When we arrived to Runö, we were welcomed by Ilari Henrik Aegerter and Huib Schoots (knew both from Twitter, but not met before). Ilari greeted me in Finnish (he’s originally from Finland), which was a surprise. Not because he could speak it, but because he could speak it so well. Ilari is a manager on eBay and lives on Zurich. He has been focusing on observing, for a while now. I became familiar with it, when he held his CAST 2012 talk Observational Proficiency: How Sharpening Your Everyday Awareness Makes You a Better TesterHuib on the other hand is quite a character, whom I knew from Twitter, his blog and recently a talk from TestBash 2.0. He talked about social sciences, and what testers can learn from it. I already knew, that he was a sparkly person. Now, after the conference, my opinion has not changed at all.

I had to rush to first keynote, as I had about 15 minutes, for taking a shower and eating a breakfast. Before James Bach’s keynote, there was an emotional talk from Henrik Andersson. He talked about how Ola had affected a lot the program of the conference, and how several companies (and people) helped with arranging it. You could see, that it was emotionally hard for Henrik, to step into that stage. He did well in those circumstances. Paul Holland continued by introducing James Bach. I knew Paul in some level in advance. I had watched his CAST talk from last year How to Report Test Progress and Paul had also helped me in Skype with an oracle problem I had in my current project. If you were going to drink a beer, and you had to choose one person to drink it with, Paul would probably be that. Extremely approachable and wide knowledge about testing.

James (Bach) on the other hand, was only one from the world wide known experts, that I had met before the conference. I participated to James’s RST course on October 2012. I wrote a blog post then, where I described my impressions about him. So, I knew he from there and Twitter, where we’ve discussed about testing several times. Often I agree with what James is saying, but we also have had disagreements. James has not though run away my questions ever, and that is where he has earned my respect. In Let’s Test, James talked about How Do I Know I’m Context-Driven? I’m not going to summarize the talk here, as you can find details about it in other blog posts. I will say though, that it meant to me a lot when James declared, that I belong to the center of the community (you understand more, if the talk is published later).

After the talk, I met Geir Gulbrandsen and Martin Hynie, . If Markus Gärtner is the only tester in Germany, then Geir Gulbrandsen is the only tester in Norway. He’s a passionate guy, who has for example passed all the AST BBST courses (this is a major achievement), and writes a blog. I know him mainly from Twitter, where we’ve had many valuable discussions about testing. Martin Hynie on the other hand, is an extremely sharp guy from Canada. I initially got to know him on Twitter, but we got more familiar with each other, when he reviewed an article of mine. His review varied from others, as it included e.g. expressing emotions. I talked with him few times on Let’s Test, and I want to say, that you need to pay attention to this guy. He has a lot to say, and it’s worth listening.

Rest of the first day went with James Bach’s tutorial “In-depth look at the art of reporting”. Before the tutorial started, I managed to meet Jari Laakso and Helena Jeret-Mäe. I knew both of them fairly well in advance, from Twitter and Skype. Both of them had also reviewed the article I mentioned earlier. Jari Laakso is a Finnish tester, who is living in Romania. I’ve learned to know, that he has extremely critical mind. We’ve had several conversations where questions just keep flying. I’ve also noticed, that there’s interesting diversity in our thinking, as we often approach things from different angles. Helena Jeret-Mäe comes from Estonia, writes a blog, and has an amazingly wonderful way of thinking. I’ve learned about her thinking in our several conversations. She’s definitely a person, that should share more her thoughts for our community.

During the tutorial I met John Stevenson and Peter Schrijver. I did not knew John Stevenson that well in advance. I only knew him from Twitter and from his brilliant blog posts. He turned out to be a passionate fellow with deep knowledge about telecommunication (and testing of course). Peter on the other hand I know from 5 Blogs and of course from Twitter. I knew, that he is highly involved with DEWT (Dutch Exploratory Workshop in Testing) and just attended PSL course. I got an impression from our discussions during the tutorial, that he has a lot of experience and good ability to describe his approach to testing.

In the evening we participated to LetsTest Lab with Jari Laakso, Geir Gulbrandsen and Kristoffer Nordström. We arrived there though quite late, and struggled with connectivity to a server. Eventually it was quite a catastrophe, as we couldn’t come up with anything useful, to report about. I actually went after the Test Lab (approximately 22pm), to sleep. I had woke up 4 am and slept 4 hours on previous night, which affected a lot to this.

Tuesday

After Johanna Rothman’s Kick-Ass keynote, I headed for Duncan Nisbet’s session “The Typo In Testing – Let’s Taste!”. I knew Duncan a bit in advance from Twitter, where we’ve discussed. My impression was, that he was a passionate guy, who had also attended PSL course. Later I heard, that he had sold his car to get to the course. I think that describes the level of commitment to becoming a better tester. Duncan is also a really laid back guy, so you get along with him easily. That’s valuable attribute for a tester.

My second session was supposed to be Pete Houghton’s “That’s a bit random! Using randomness to help you test“, but I noticed my colleague (Samuli – @samuliel) was there already. We had agreed, that we would record the sessions with voice recorder. So I headed for Dawn Haynes’s session “Talking To Triangles”. Afterwards thinking, I’m glad I did. Dawn turned out to be an interesting person, with a lot of experience from our industry. She works at PerfTestPlus, and is an advocate of performance testing.  At some point she mentioned, that she is like a pit bull sometimes. If there’s uncertainty about something, and she wants to know more about it, she will not stop before receiving answers. I could totally imagine that, as she seemed a person with a lot of courage.

The final session of the day was Tobias Fors’s “Systems Thinking For The Rest Of Us“. Last year I wrote a blog post about Russell Ackoff, whom I respect a lot. Therefore I was really interested of participating on Tobias’s session. I did not know him in advance, but I had seen his talk in Oredev 2011. I thought it was great, and figured, that the session would be good opportunity for discussing about systems thinking. Session itself was extremely interactive, but after it came the exciting part. We discussed with few others about e.g. reasons why systems thinking has not spread more widely. Tobias also pointed me to an article by Ackoff – A BRIEF GUIDE TO INTERACTIVE PLANNING AND IDEALIZED DESIGN. I ended up also meeting Michael Bolton (I think he does not need an introduction. In case you don’t know him, check: http://www.developsense.com/blog/). We discussed (I mainly ended up listening) after that about a model, that was shown during the session. Michael gave some feedback about it and eventually the conversation led to Deep Blue.

During lunches and dinner, I managed to meet also few other people, that I had hoped to meet. These were Iain McCowatt, Simon Morley and Julian Harty. Iain is working for CGI, and lives in Canada. If I remember correctly, he is though from UK. I first got to know Iain through his blog posts about regression testing (Rethinking Regression). I thought they were brilliant. After, that I witnessed how he constantly expressed thoughtful approach to testing, on Twitter. Lately there’s been several fascinating discussions between James Bach, Michael Bolton, Iain McCowatt and Jesse Thomas Alford. There’s also an interesting video, where Iain talks about lessons we can learn from medical professionals and how testers think on “CAST Live”. Those lessons learned from medical professionals, was actually one of the topics we discussed while eating.

Simon Morley was even less familiar, than Iain, to me. I knew him mainly from Twitter (like most of the others). I also knew about his blog, which contained a lot of thoughtful posts about testing. Eventually we had really interesting discussions with Simon, and I found out, that he is a sharp minded tester. One of the topics we talked, was Griffin Jones’s session. It had raised some thoughts in Simon’s mind. Even though I did not participated to it, I found similarities with, what Cem Kaner discussed about in BBST Bug Advocacy course lectures (he talked there about credibility of proof and how it affects lawyers credibility).

I’m not now entirely sure, but I think I met Julian Harty on Tuesday. Anyway, I joined a queue, that led to dinner or lunch. I noticed Julian there and introduced myself. He knew me, because I had made him a question about Six Thinking Hats. I became familiar with Julian, when I found his talk from 2011 Starwest. There he talked how he has applied Edward de Bono’s Six Thinking Hat’s to problems in his work. I liked a lot the talk, and have seen it several times. I even ended up experimenting with the method, and did a blog post about it (I mentioned it already earlier). We talked with Julian for the whole time we were on the queue. He recommended to me, Ken Hudson’s book, that includes 60 techniques for solving problems. He didn’t mention the name, but I figured out, that it was The Idea Accelerator: How To Solve Problems Faster Using Speed ThinkingI already ordered that one. Other book, that Julian recommended was Sam Kaner’s (Cem Kaner’s brother apparently) Facilitator’s Guide to Participatory Decision-Making. Rest of the time, we talked about using the Six Thinking Hats method.

I decided on Tuesday, that I would go again to Test Lab, as I was not satisfied with how Monday went there. We had a team with Jari, Geir and Kristoffer, but I figured out, that they probably wanted to confer instead of Test Lab. I noticed them, that I was going and didn’t want to force them there. On the Test Lab, I formed a team with Michael, who was a Swiss tester with test automation background. There was also third person in our team, who was Daniel (if I remember correctly). Considering, that he spoke Swedish, I figured out he was from Sweden. We ended up testing Mumble. We didn’t have headphones, which restricted our scope quite a bit, as Mumble is an open source voice communication software. It wasn’t that bad though, as there was still a lot to explore. After struggling a bit with note taking, we ended up making our notes to Mindomo. There we could simultaneously add notes about our testing.

20130521_225047

Mind map by Zeger van Hese’s group on Test Lab (Beside Zeger, there were Ruud Cox, Ilari Henrik Aegerter, Peter Duelen and Levente Balint)

Test Lab was incredible experience. After roughly 1,5 hours of testing, we reported the information we had revealed. Before us, there was people like Zeger van Hese (whose group created that awesome mind map, you see above), Michael Bolton, Richard Robinson and Pradeep Soundararajan, reporting their findings (I think that’s a true mark of an expert, that you can also show, that you can walk the walk). It was almost 11pm on Tuesday evening, and the room was full of people. People were testing, explaining their findings, discussing about testing and learning(!). This is what every testing conference should include! I told about this, at work after I came back. I said I was on testing conference, and colleague (not same company) asked if we tested. I said “Sure.” He said after that, that it was a joke. Then he asked “Did you really test?” Where I replied “Yes. Of course! It’s a testing conference!” After that he asked the name of the conference. I said “Let’s Test!” I think that it fit well into that conversation.

After the Test Lab, I finally had time to talk with Pradeep Soundararajan. As with many others, I think I first heard about him on Twitter, where I’ve followed him. Lately I’ve been also watching a lot of Oredev videos, and I’ve seen several talks by Pradeep. One interesting talk, is for example a talk How I wish users knew how I help them through context driven testing, where he talked about being a context-driven tester, and the obstacles he has faced. I also saw Gojko Adzic’s talk Sleeping With The Enemy from Oredev 2011. There Pradeep and Gojko were discussing quite intensively, and continued the discussion afterwards on whiteboard. We sat down after Test Lab, because I wanted to hear how the whiteboard discussion went. It was a good story, and I was also interested about it, because I’ll go to Gojko’s Specification by Example workshop this Autumn in Helsinki. Based on everything I saw on Let’s Test, Pradeep seems like man with a big heart. He was constantly asking questions on keynotes and sessions, and also showed that he can walk the walk (brilliant test reporting on Test Lab). I look forward seeing him again.

The night was not over for me on Tuesday. I still managed to discuss with two awesome testers. Those were Jean-Paul Varwijk and Henrik Andersson. I knew Jean-Paul before the conference (had not met him face-to-face though). We had a Skype session, where he helped me with finding Session-Based Exploratory Testing approach for HP Quality Center (Sami Söderblom also helped me a lot). I was able to come up with a workable solution after our discussions. Besides that, we’ve discussed several times on Twitter and I’ve also seen his great webinar, where he answered very thoroughly my question in the end. Jean-Paul talked to me about concurrent testing approach, that they are using currently. I’m not going to open up the details here, but I can say, that I really enjoyed the discussion we had.

Henrik Andersson was one of those testers, that I had heard about often, but never actually discussed with. I had the impression, that basically whole community knew him. From the moment we introduced ourselves, I realized this man has a lot of passion inside of him.  I also learned, that he had asked from reception if I had arrived on Monday. Just to check, that I had actually arrived. Amazing.

As I did not knew him that well, I asked about his background. He told about it very thoroughly, and I enjoyed it from the beginning to the end. I have no idea how long we discussed, but the time just flew. It was a good way to end the conversations on Tuesday (or maybe it was Wednesday already). Luckily I was able to meet Henrik again before I left the conference. Looking forward the next time, we’ll meet.

Wednesday

On Wednesday I was still fortunate to meet people, that I had not met earlier (face-to-face).  First one was Ruud Cox from The Netherlands, whom I met at Mark Micallef’s session. We didn’t have much time to talk, but he recommended me the book about sketchnoting. If you’ve been lately on Twitter, you’ve probably noticed the awesome sketchnotes, that Ruud has made. Few examples of those can be found from his blog. I also heard positive words about Ruud from James Bach. I think James talked about it on his tutorial, but not sure. Nevertheless, Ruud is definitely a tester, that people should know of.

Another tester, that impressed me, was Zeger van Hese, from Belgium. I was blown away by Zeger, when I saw the video of his talk at Oredev 2011. He mentioned on Let’s Test, that his voice was a bit gone on the video, because of being sick. I did not know that, when I was watching the video. I think, that the peaceful voice fit perfectly to that specific talk. It’s one of the most memorable talks I’ve seen of testing. We discussed a bit after his great session, and went through some of the things he had talked about during the session. Like The Noteboard, Coffitivity and of course his talk at Oredev. Zeger is definitely a fresh air in our community. He has a unique kind of artful, and scientific approach to testing.

After Scott Barber’s passionate keynote, it was time for goodbyes. There I met most of the people, that I wrote about here, and also managed to throw glass of water over Jean-Paul (I’m still sorry about that ;). People were saying goodbye, but there was no need for it.  We will meet again in some future conference, and continue discussing about testing on Twitter, Skype, blogs and so on.

It’s about people!

You might wonder (those of you, that are still here), why I didn’t talked about the content of the sessions nearly anything. That’s because, that is only a portion of what Let’s Test was. I wanted you to understand, that this conference was full of unique, skillful and passionate testers, from all over the world. The real magic happened, when these people started discussing after being inspired by the sessions.

By Testers for Testers – Because People Matter

I want to thank from the bottom of my heart, all the people who made Let’s Test 2013 possible. The way in which the whole conference was designed, and executed, was like a masterfully played symphony. You could see how well, the value of conferring was understood. Test Lab was also pure awesomeness. Thanks Martin and James.

Rest of you, I’ll see in the future.

Applying Six Thinking Hats to Let’s Test Conference

Recently I’ve been listening a lot of videos, while driving to work, and back from work to home. Among tens of videos I’ve listened, one has rose above others. That video is Julian Harty’s talk from StarWest 2008. The title of the talk is “Six Thinking Hats for Software Testers” and you can watch it here. It’s good to know, that the talk is based on Edward de Bono’s book about Six Thinking Hats.

Wikipedia describes the underlying principle like this:

The premise of the method is that the human brain thinks in a number of distinct ways which can be deliberately challenged, and hence planned for use in a structured way allowing one to develop tactics for thinking about particular issues.

De Bono identifies six distinct directions in which the brain can be challenged. In each of these directions the brain will identify and bring into conscious thought certain aspects of issues being considered (e.g. gut instinct, pessimistic judgement, neutral facts).

So, you have six hats, which all have different colors, that represent different directions in which the brain can be challenged. It’s good to open up a bit these directions (taken from Wikipedia article, that was referred earlier):

  • Information: (White) – considering purely what information is available, what are the facts?
  • Emotions (Red) – intuitive or instinctive gut reactions or statements of emotional feeling (but not any justification)
  • Discernment (Black) – logic applied to identifying reasons to be cautious and conservative
  • Optimistic response (Yellow) – logic applied to identifying benefits, seeking harmony
  • Creativity (Green) – statements of provocation and investigation, seeing where a thought goes

You probably noticed, that there is only five directions here. The sixth one is Blue:

Sequences always begin and end with a blue hat; the group agrees together how they will think, then they do the thinking, then they evaluate the outcomes of that thinking and what they should do next.

In his talk, Julian Harty recommended starting also with the Blue hat, then moving on to Yellow, White, Black and Red hats. After those came the Green hat, and finally Blue hat was used for deciding what you should do next.

I’ve listened several times Julian’s talk and wanted to try the method myself. As I am going to Let’s Test conference next week, I thought I could try to apply the Six Thinking Hats to it. I haven’t read the book, so this might be inconsistent with book.

Let’s apply Six Thinking Hats to Let’s Test Conference

blue_hat

  • Testing conference for Context Driven testers.
  • A lot of sessions, tutorials and Test Lab activity. Lots of prioritizing.
  • A lot of skillful and passionate testers.
  • Aiming at giving us opportunities to learn from each other.
  • A bit isolated location, that gives us more opportunities to confer with each other.

yellow_hat

  • Meeting a lot of new people.
  • Becoming a better tester.
  • Learning new skills (e.g. test reporting, python, systems thinking)
  • Enjoying the venue.
  • Being afterward more part of the Context Driven Testing community.
  • I will be seen as a good tester.
  • People remember me afterwards.
  • Gaining more understanding of Context Driven Testing.

red_hat

  • Excitement.
  • Scared.
  • Happiness.
  • Friendship.
  • Socializing.
  • Sadness (when it’s over).
  • Opportunity to grow.

white_hat

  • 3 days
  • 3 keynotes
  • 28 sessions (possible to participate 7 of them, will miss 21 of them)
  • 13 tutorials (possible to participate 1 or 2 of them, will miss 11 or 12 of them)
  • 33 speakers (from which I know in some level – mainly twitter and blogs – 24)
  • 16 hours 40 minutes (sessions, tutorials and keynotes)
  • XX hours XX minutes Test Lab (done during evening activities?)
  • 2 hours 45 minutes in total (breaks)
  • 3 hours (lunches)
  • 4 hours (dinners)
  • 4 hours (evening activities)
  • 7 hours (bar and music)
  • In total:  37 hours 25 minutes + sleeping time + registration + welcome + morning remarks
  • Time to sleep 8 hours, if going to sleep 01:30am

black_hat

  • I will stress too much and become sick, and miss the whole conference.
  • I will drink too much beer and become “that guy who drank to much beer”
  • I will realize, that majority of the people on the conference are bunch of idiots
  • People think I’m an idiot.
  • I will not learn anything.
  • Because of poor notes, I will forget most of the information about the conference.
  • I will make a fool out of myself, by participating into discussions I have no clue about.
  • Weather will be awful.
  • I will focus too much on sessions, talks, tutorials, test lab and therefore miss all the conferring.
  • I will focus too much on conferring and miss all the sessions, talks, tutorials and test lab.

green_hat

  • Gain information about those 21 sessions and 12 tutorials I will miss. Like changing notes, taking pictures of other people’s notes, asking from people about the sessions or reading blogs afterwards.
  • Combine notes with the slides, that are likely published later on.
  • Instead of discussing with people, I will only listen.
  • Use the voice recorder (mobile phone app), where appropriate, and useful.
  • Notes will be taken automatically (Wishful Thinking)
  • I will learn to know everyone, that is attending the conference (Wishful Thinking)
  • Afterwards I can easily return to notes about discussions I’ve had in Let’s Test (Wishful Thinking)

blue_hat

  • Don’t stress too much about the conference. Believe in yourself, and consider it more like a place, where you will meet friends.
  • Take notes, but also reserve time for just listening. Ask in advance if you can get a copy of someone else’s notes, from a session you’re only listening. Consider using a voice recorder, but make sure, that everyone agrees with it.
  • Use a lot opportunities to introduce yourself to others. Don’t let interesting conversations end without knowing, who you were talking with.
  • Store all the notes, links and additional material to for example Evernote, or DropBox.
  • Talk about the conference for your colleagues. This way you need to go through the notes, and you will gain more understanding about the the topic you will talk about.
  • Write a blog post after the conference and try to provide value with it to others. Like concentrate only on conferring or Test Lab.
  • There’s lots of time reserved for breaks, lunches and dinners. Use those for learning to know people, and discussing about testing.
  • Apply things, that you’ve learned at work. Try at least one thing from every session you attended.

Conclusion

Six Thinking Hats can be a powerful method for generating ideas about difficult problems. I found it useful for approaching a problem. I would assume, that involving people with high variety in thinking styles, boosts the outcome of the method. On the other hand it seems to work well on its own.

I need to read the book, to gain more understanding about the method. Otherwise I will definitely use it on the future to testing related problems, and for that matter any problems I will find it being useful.

I also encourage you to try it, and if you have tried it already, let me know your thoughts.

Visibility of Our Work

It’s been a while from my previous blog post. I’ve been busy with my current project which is actually my first as a consultant. This means that I’m learning all the time a lot and my thoughts around testing are evolving. When I activated on studying testing on March, 2012, I had a clear goal of becoming a software testing expert. Since then I’ve been for example on BBST Foundation and Rapid Software Testing courses. My knowledge about testing has increased hugely from what it was one year ago. I have though run into a problem. The problem is the visibility of our work. In other words, to whom and how much should we transfer our knowledge as testers?

Testing provides information

Question

Image via (Marco Bellucci – Flickr)

I like the idea of testing providing information. It sounds natural for my current context that does not have any outside pressure affecting the way we test our system. Reporting bugs is the common way of delivering my knowledge about the system, but I can do more. At least I am trying to come up with different ways of being more valuable as a tester in my project. Basically that means thinking of to whom and how I could give information about the system I test. This can mean informing developers about the condition of the release or providing my opinion about the state of the system to product owner. Both are something that I have done in my current project.

With information comes responsibility

The information itself is rarely valuable to us only so we have to share it. I’ve experienced moments when filing every bug would have damaged a lot my relationship with the developers. James Bach has talked about Sympathetic Testing on his blog and how that is most often a way to start when facing highly unstable product. In other words not putting too much pressure on the product but more like trying to find out what it can do instead of what it can’t do.

3479598520_4b10c80fff_z

Image via (fresh_photo – Flickr)

So we have to consider what information we provide and when. Especially this is highlighted when you are sharing information about your understanding to people that do not necessarily understand testing. These people might be for example from upper management or product owners. I reported some time ago my opinion about the overall status of the system I was testing. So, basically I just had to describe how I see the status of the system from tester’s perspective. I reported my opinion to several people across the project in one email and I had to make an extra note about how my opinion should not be viewed as final truth. That is why I think we should remember the impact that our information sharing can create. We are responsible for our words and should remember this all the time we talk about our opinion about the system under testing.

When we understand our responsibility we can make a change

The information we have about the system is by no means the truth. It is fallible and biased, but still a result of thought process that is often valuable to stakeholders. When we understand these aspects of our testing – and remember our responsibility toward our information sharing – we can share our knowledge in a way that will benefit the project more than solely relying on bug reports could achieve.

Image via (ForestWander - Flickr)

Image via (ForestWander – Flickr)

I also believe that in information sharing and visibility of our work lies the answer to changing the public opinion about testing. The better we evolve in explaining what we do, what we have found out or what we are about to do, the more people see the effort we have put to become a skilled tester. This requires though improving our way of explaining problems, clarifying our messages and treating for example every email or document as one that can be forwarded to any stakeholder on a project. I’ve seen the benefit in this when I have put a bit more effort in explaining things as simply and professionally as I can. And when my explanations are bouncing across the project, I can rest assure that it’s piece of my work like any other testing artifact I have produced (e.g. notes, bug reports).

What, Who and How

I do believe – based on my short experience – that the information we reveal via testing can be shared in various useful ways, but the challenge and my original problem is the ‘What, Who and How‘. What do we share (e.g. overall opinion about the system, opinion about a specific feature or functionality)? Who do we share (e.g. all the stakeholders, development team, upper management, product owner)? How do we share (e.g. email, mind map, meeting)? This is also one of those matters that is highly affected by the context, so there is no “One size fits all” -answer for this.

I will continue experimenting with the ‘What, Who and How’ -problem. I also hope I will be able to create conversation around this subject as it’s a lot linked to test reporting itself. Both are my main themes for year 2013 and if everything goes well, at the end of the year I can write “Part 2” post for this one with more wisdom behind it.

Three Days of Kobayashi Maru

Those of you that have not watched Star Trek, are not probably familiar with Kobayashi Maru. Wikipedia defines it like this

It is a Starfleet training exercise designed to test the character of cadets in the command track at Starfleet Academy.

Rescuing the civilian vessel Kobayashi Maru is the notional primary goal in a simulated battle with the Klingons. The disabled ship is located in the Klingon Neutral Zone, and any Starfleet ship entering the zone would be in violation of the Organian Peace Treaty.

The approaching cadet crew must decide whether or not to attempt rescue of the Kobayashi Maru crew – endangering their own ship and lives – or leave the Kobayashi Maru to certain destruction.

Overall you will be put into a situation where you have – seemingly – no-win scenario ahead of you. Test will test how you will handle the situation. As there is no one right solution and you are under pressure, your actions will reveal your weaknesses (and strengths).

My personal Kobayashi Maru (a.k.a. Rapid Software Testing -course)

Last week I spent three days at Rapid Software Testing -course held by James Bach at Helsinki. After the course I realized that the course was like Kobayashi Maru. Lots of different challenging tests that had us go through situations that didn’t have one right solution. We didn’t have to sacrifice our crews, but we had to figure out how we can test our products as well as we can with our given resources.

The tests (or challenges) also revealed a lot about ourselves. At least it did in my case. I was lucky to have some sort of reputation which led to James knowing me in advance. This on the other hand led to me being given more challenges than perhaps anyone else on the course. Someone might see this as a negative side, but I thought (and still do) I was privileged to participate to those. So what did those challenges reveal about myself? At least these things:

  • I can control myself rather well when being questioned and criticized (to certain degree)
  • Even under pressure I can solve problems
  • I’m able to listen other peoples suggestions (by colleagues for example) about solving the problem
  • I need to have deeper knowledge of testing techniques (in a level that is available even under pressure)
  • I have a habit of forgetting details under pressure so I need to make sure I have resources that help me coping with my weaknesses (e.g. screen recording and notes)
  • I need more experience of different testing problems
  • I need to create (or find) heuristics that help me perform under pressure and when dealing unfamiliar subject
  • I especially need to develop my ability to ask questions that help me perform the task given (this is related to previous one)
  • I need to stop making assumptions! (About things that matter)

Assumptions

Photo by Jacob Bøtter. Used under the Creative Commons license.

If there is one thing I want to raise out of the course, that is definitely making assumptions. The problem that I faced again, again and again during my challenges.

I kept thinking about it and especially why I ended up in that assumption trap several times.   First I realized that when we are under pressure, we are not thinking logically always about the situation. I mean stopping for a minute and think what we are being asked of. The challenges that I was given – and face in my job on daily basis – ask me to solve something. Before you can move into solving the tasks, you need to be rather confident about the fact that you have understood the given assignment as the one who gave it understands it.

If someone asks you to “test this door”, you need to be sure that the door you are going to test is the one you were being asked to test to. Secondly you want know what the person who asked you to test the door really wants. What sort of information is he interested of? Does he want that through that door needs to be accessed 24 hours 7 days a week? Or that it is enough secure to keep people from breaking in? If you just jump into testing the door, you will make assumptions on the purpose of your testing and the needs of the person asking for the testing.

In the end assumptions are a tempting and easy way of doing your job. It’s so tempting to just go with your assumption instead of having the trouble of asking the questions that will test your assumption. But as testers it is our responsibility to test our assumptions. Because if we don’t do that, who will? How can we held our heads high and look back with confidence if we haven’t saw trouble of testing our assumptions? Think about it the next time you discover you have been following an assumption that led you into trouble. What question should you have asked and what point?

Impossible is possible

McFadden, Strauss, Eddy & Irwin (public relations firm) for Desilu Productions.

Wikipedia tells about James T. Kirk’s attempts to beat the Kobayashi Maru:

James T. Kirk‘s back-story defines that he took the test three times while at Starfleet Academy. Prior to his third attempt, Kirk surreptitiously reprogrammed the simulator so that it was possible to rescue the freighter.

This fact finally comes out in Star Trek II: The Wrath of Khan, as Kirk, Saavik and others appear marooned, near death. Saavik’s response is, “Then you never faced that situation…faced death.” Kirk replies, “I don’t believe in the no-win scenario.” Despite having cheated, Kirk had been awarded a commendation for “original thinking.”

Kirk doesn’t believe in no-win scenario and therefore he will find a way to solve a problem, no matter what. As a tester I want piece of that mentality. We have to respect the laws and act ethically, but otherwise there is a lot room for creativity and bending the rules. Even as simple as asking the programmer if he can provide us a logging functionality for a product. An act that can help our testing a lot but is not an option for several people. Or they don’t see it as an option (“it’s impossible” / “he will never do that!”).

During the RST-course I had several moments where I did not use all my resources. I was too busy trying to figure out the solution inside my head. When instead I should have considered how I can get the answer without figuring it from scratch myself? Who has the information? Who can help me? Asking for help is not sign of weakness (to a certain degree). Not being able to ask for help IS a sign of weakness.

I also gave too much respect on my thoughts about what I can do and can’t do. Who is stopping you to do whatever you prefer (with respect to laws and ethics) to solve the problem in hand? And if you are being stopped, at least you have tried and learned something.

De-Focus!

Last thing I wanted to mention from the course is de-focusing. I’ve found it to be rather powerful technique for varying your testing. First of all frustration is the emotion that

Creative Commons Attribution

triggers de-focusing. When you are frustrated and don’t see progress in your testing, you rely on de-focusing. Find pattern in your previous tests and then violate that pattern as much as you can. Prefer MFAT (Multiple Factors At a Time) and vary your observations as well. Observe for sections that you previously did not. Imagination is the limit here.

I witnessed several times during the course that de-focusing helped to solve a problem and will use it on my work also. It can be as simple as using random numbers or help of a colleague, but breaking the pattern is the point.

Few words about James Bach

I’d like to end my post by saying few words about James Bach. I had heard a lot of things about James and knew his reputation as an aggressive and difficult person. At least that’s the impression I had. Before the course started I had a hunch though that James can’t be as bad as his reputation is. I mean, who would hire him as a consultant?

And my hunch was correct. I felt that James was probably the best teacher I’ve had. Amazing amount of knowledge and experience of our field and also entertaining, but demanding style of teaching. I talk about teaching, but he actually enabled me to learn. I had my hard times on being pressured by him but accepted it as a way to learn more. And, boy did I learn. Still have those moments of hard questioning by him clear in my mind. Because of those experiences I was able to find immediately after the course few critical bugs in my current project.

I hope I’ll meet James again at Let’s Test 2013 along with all the other great testers. All these people like James show me the journey I still have ahead of me as a tester, but also motivate me to surpass them.

Interested in books?

It’s been a while.

After finishing BBST Foundations -course I’ve been reading a lot. First I finished the beta version of Elisabeth Hendrickson’s new book: ‘Explore it!’. After that came ‘Perfect Software: And Other Illusions about Testing’ by Gerald M. Weinberg. Now I’m reading ‘Lessons Learned in Software Testing’ which is written by Cem Kaner, James Bach and Bret Pettichord. One of the main reasons why I’m reading in quick pace books now, is that I’m participating Rapid Software Testing -course in few weeks (23-25th of October) and I want to gain more understanding of context-driven testing. I hope that by gaining more knowledge about it, I will also face things that trouble me and I will have good opportunity to ask about them at the course.

I noticed while reading ‘Lessons Learned in Software Testing’ that there is a lot of interesting book recommendations. They fall under many different categories (e.g. epistemology, negotiation, disciplined exploration or reproducing nonproduciple bugs). While seeing all these recommendations, it came to my mind: “Why don’t I do a mind map of these book recommendations?”. And here it is:

I haven’t reviewed it a lot, so there might be mistakes or few books missing. Also some of the books are under few topics, as their content is fitting more than one topic. Personally I have not read almost any of these books, so there is a lot for me to dive in for. Considering my current Amazon Wishlist – which contains 30 books – reading all of these books will take years. But that’s allright. I’ve got time. This is my career. This is my life.

Ut tensio, sic vis

Preface

British physicist Robert Hooke published Latin anagram in year 1660:

ceiiinosssttuv

No one managed to though figure out what it meant and therefore it took 18 years (1678) until he revealed the solution to it:

Ut tensio, sic vis

Which can be translated as: As the extension, so the force. 

Hooke’s law is a law of elasticity and Britannica for example defines it like this:

For relatively small deformations of an object, the displacement or the size of the deformation is directly proportional to the deforming force or load.

At this point some of you might be wondering why I am explaining the law of elasticity here. The reason is, that I think it is a great methaphor for an online course I just attended. The course is BBST Foundations and it is held by the Association for Software Testing. It lasted one month and I’m still waiting for my final grade (pass/fail) for it.

In my opinion, the course was like a spring. The more I put effort on studying and interaction with other students, the more the course gave back to me (and hopefully to others as well). I can also assure that I was far from reaching the elastic limit of the course.

Via Dolorosa
Before I move on to explaining all the things I loved about the course and what I’ve learned, I want to say few words about the journey and especially how hard it was for me.

Few months ago I tried to google information about this course, and especially the amount of time it will take, but I did not find much specific details about it. Sure I found estimations that said it will take 10-40 hours per week, but those were just numbers to me then. I want to bring up how it was for me and not just numbers, but also pure examples from daily live of mine.

(Photo: Creative Commons / Stuartpilbrow)

I knew that the course would be challenging as I have family (fiancee and less than 2 years old son) and a job that requires, at the moment, early wake ups. I did not still estimate well enough the impact that the course would have on my daily life. Because I did not want it to take away time from my son, I did not do the course when he was awake (09AM-09PM). When you add the fact that I had to get up to work every morning 0445AM, you will notice that there was not much room for the course.

I was fortunate to go with a bus to work as I could do the assignments there. Then I also used the weekend mornings (got up 05AM, when others woke up 09AM) and during evenings when son had gone sleeping. But this took quite a lot of the time away from me and my fiancee, which I found troublesome.

In the end I was sleeping on the average 4-6 hours per night and it started to eat me inside. Actually now that I had first Monday since the course ended, I overslept 4,5 hours this morning and I thought if my body just decided to take the sleep debt I had kept building.

You might be also thinking why I participated to the course. But I can assure you, that it was still worth it. I had such a strict constraints in my life that it made the course more challenging to me than it did for other people. I still believe though that I managed to make it an experience that gave me and others a lot. I feel more capable as a tester now than I did before the course.

Evolution
Previous part went through the pain I had to go through in order to evolve. This part goes through about how I have evolved as a tester because of the BBST Foundations -course.

First of all, BBST Foundations requires you to participate into thinking practical and difficult software testing problems. Besides that it also requires you to participating into discussions about these practical problems. I noticed through the course that participating into the discussions was perhaps the most fruitful way of learning.

This photo belongs to: Smithsonian Astrophysical Observatory

Other thing that strike me on the course, was that there were so many problems and assignments that seemed in first glance rather simple, but after a moment they grew out to be anything but simple. I thought though that it was a sign of a important skill, noticing things. Specifically noticing problems that are hiding behind assumptions.

I also learned how effective diversity can be for facing problems. When there are people with different backgrounds and thinking, you will receive several interesting varying approaches besides your own. George Dinwiddie once tweeted that

The roof don’t leak because the holes in each layer don’t line up with each other.

This came after we asked about ways of managing confirmation bias. He referred to having people with different backgrounds. I noticed that with my own eyes while discussing about difficult problems during the course. Solutions to problems vary as much as the people who you ask them from vary with their backgrounds. But more importantly the opinions about what actually is the problem vary to the same degree. This is the power of diversity.

The course also had five fundamental topics that serve long time as pilars for my knowledge about testing. These were: Information objectives drive the testing mission and strategy – Oracles are heuristic – Coverage is a multidimensional problem – Complete testing is impossible – Measurement is important, but hard. They cover a vast amount of information and I have not yet finished all the material we were either required or recommended during the course. My plan is to do that in the near future. That will take time though as recommended readings included several books.

Summary
I think I could sum up things that I personally learned from the course. I want to though highlight that these learnings are based on my experiences. They might change when time goes on, as I will go through the material again. My learnings are also probably different from other students and even from the learning goals of the course.

Before I list things I learned, I want to mention that I highly recommend the BBST Foundations -course. It will require you to give a lot, but in exhange you will evolve as a tester relatively to the amount of effort you have invested on it.

What I learned from BBST Foundations -course:

  • Diversity is a good thing.
  • Challenge assumptions.
  • Five fundamental topics (Information objectives drive the testing mission and strategy – Oracles are heuristic – Coverage is a multidimensional problem – Complete testing is impossible – Measurement is important, but hard) and vast amount of knowledge under them.
  • Interaction and discussion are powerful methods for dealing problems and defining what the problem actually is.
  • Facing practical testing problems is mandatory for evolvement as a tester.
  • Context defines our testing strategy.
  • Express myself in a more effective way and think the content of my writings through outline.
  • Testing is never perfect. I am never perfect (nor I should aim at perfection). Outcome is a compromise made under the constraints we have.

How to rid the world of all bugs

…And Now for Something Completely Different…

How to rid the world of all bugs? It’s easy!

1. Become acknowledged software testing expert

2. Develop a new method for finding bugs

3. Wait until the software testing world really starts to take notice of you

4. Jolly well tell them what to do

5. Make sure they get everything right (processes, standards)

6. There will never be bugs any more!

Bye-Bye,

P.S. Monty Python – How to do it