How do I test?

Rought waters

2013-04-15T12:47:00.001+03:00

The next blog post is two-fold: the announcement for me attending the EuroSTAR Testing Conference as a speaker and the reasoning why I chose the topic.

So yes, I have been chosen as a speaker to EuroSTAR 2013 in Gothenburg. I thank everybody who has congratulated me so far and it is most likely that those people that have congratulated me have actually given me strength to keep on pushing and get my topic to be accepted. So, THANK YOU all who have supported me during these tumultuous times.

Some might be baffled why I talk about “supporting”, “strength” and “hard times”. That difficult time is the key to both my talk in EuroSTAR and to my life for the past few months. Here’s a summary about my future talk at EuroSTAR – Testing me:

During 2012 November I had a nervous breakdown: I was overwhelmed both professionally and personally. I did a job that I did not like too far from home. I wanted to be the most prominent star in the Testing scene. I wanted to be admired. But instead I burnt myself out. And I did it for the sake of my testing career. This is a story about hard decisions made to boost career over family and health.

I will tell how I felt before the melt down and what I did, the hard earned reputation and life-altering decisions about career, and how I started to buckle under the pressure. I will tell about the days I thought about quitting my job, what it took to get back to work after two months of sick leave.

This is “Testing me” - a reality check of the worst kind.

The topic is as personal a story as any. I didn’t speak much about my burnout to anyone mainly because I was afraid of their reaction. My closest family was aware of the situation to some extent but the full scale was revealed only after 3 or 4 weeks to my sick leave.

This talk is a therapeutic self-analysis on what went down during the burnout, and also a "come clean" kind of talk about why I was absent from all events and discussions lately. It is an experience sharing so that other people wouldn't have to go through what I did.

So, I encourage you to come and listen to what I have to say about my experience from stress, career and family, and the balance of those things. I don’t have the ultimate answer to all the questions about career moves, stress handling, etc. but I will share my thoughts on how I sailed through the rough waters. You might pick some pointers on what I did and how I handled different situations.

Even though the topic sounds distressing, I am now working full time and in a job that I enjoy doing. I also live closer to the office. The sky seems to clear a bit. A good sign, I think. I will also share what has happened during the time before the conference about my career, thoughts, etc. One could say I will try to make a full circle with the talk from the beginning of my career to the present day.

Anyway, hopefully I can manage a few blog posts about testing topics in near future to regain my status as a professional tester. ;)

Until next time,
Peksi

Reading Practice

2012-11-15T09:53:00.001+02:00

I’m reading currently a book called ”How to read a book?” by Mortimer J Adler and Charles van Doren. I have just started it but I talked about it in the office the other day. One of my colleagues said that one way to read a book is to first read the table of contents and the read the first page of every chapter. This post is an experience report on what can I learn by using a different reading strategy. This blog post will act also as platform for my thoughts when I read my target book. It was inspired by Erik Brickarp's blog post on taking notes.

The first pages of “How to read a book?” book states that there are two ways to learn from books: to illicit information, and to understand the book. My goal here is to run this exercise to illicit information. I choose a book called “Being logical” by D.Q. McInerny as my target book.

Preface

I decided to read the preface to be more in tune with what is going to be written about the subject. Forewords usually try to tell the reason behind why the book is written and to inspire the reader to go on. So when I got to the end of page 1, I decided to go on.

I had read the first paragraph of the book earlier (doesn’t count as cheating) and didn’t continue because of eldritch terms and words. Having read the preface, I the realized they will be explained. The book says it will concentrate to leave as little room for assumptions as possible thus trying to be explicit rather than implicit. Also it is not a text book for a class but a practical guide. This made me interested even more.

The preface addresses the structure of the book. It seems to be in five parts; each part building on the previous one. I’m interested if the parts contain what they were supposed to contain. The first part is told to be preparatory, the second one to lay the foundations, the third one to the meat and potatoes of thinking logically, fourth part discusses attitudes and fifth discusses fallacies. I know that I am fallacious, even more than regular people, so it is interesting to see what can I learn about myself while reading.

The table of contents

First thing that came to mind was that never before have I really read through the table of contents. This is the first time I really look into them. I usually skip the pages altogether to get cracking with the reading. Truth be told, I was quite excited to see how the table of contents was structured. It felt like a story was already told with the items on the list.

I pretty soon realized that every chapter had 8-30 sub chapters. Each chapter was about 1-5 pages long. I was starting to question my decision to read only first page from each chapter. For most of the sub chapters it would get the whole chapter done already. So I decided to read only the first *subchapter* of each chapter. They were, according to the table of content, almost always the introduction or foundation for the chapter.

Also I noticed that as for this book, it makes a great checklist for practicing critical thinking. By looking into the titles of each sub chapter, you would get a coherent guide to practice logical thinking. I could create a powerful mindmap out of those and print it on my cubicle wall. (And I will share it with you! Tadaa!)

Feel free to print this also!

Also this was a great stage to look for words and phrases you don’t understand that are essential to the understanding the content of the chapter. “Syllogistic”, “agnosticism”, “antecedent”, “equivocation”, “Post Hoc Ergo Propter Hoc” and “expediency” were new to me. Now that I checked them, I know better.

1st Part – Preparing the Mind for the Logic

I tackled it with my usual gusto; get cracking with it and read it again if I need to. And again I needed to read it twice for me to understand the message. I think I shouldn’t as this type of reading is just to get information. Sadly I didn’t /read/ it, I skimmed it. And after the second reading, I realized that the first sub chapter was exactly about that: Paying attention. And I had to pay, for it took my time and time is money. The book encourages you to listen instead of hearing, to see instead of looking. It gives great insight to the foundation of logical behavior.

The table of contents told that topics like “Effective Communication” and “Truth” were in latter parts of the chapter. This is the problem of this kind of quick reading, I see interesting stuff and I don’t want to stop reading. But I must refrain from reading more as I was to read this thing quickly, so on to the next chapter.

2nd Part – The Basic Principle of Logic

At this point, the technique I chose was beginning to bother me. I did read it fast, but this was only a glimpse of what it could have been. The principles could have been more thoroughly read but I chose to stick to my plan. The 1st subchapter was about the first principle of logic. Before the 1st subchapter was a brief piece of text regarding logic as three separate but linked entities; as science, as art and as skill. This did raise some questions, but I think they will be answered if I read the book with thought.

The first subchapter tries to focus on practical side of things. The theory will be discussed elsewhere, but I was intrigued by the the notion of reading even more about the theory of logic. This subchapter proved some examples which clarify the link between logic and human reasoning. Again I was tempted to read on, but managed to jump to the next chapter.

3rd part – Argument: The Language of Logic

The subchapter was about founding an argument. I did have some experience in the practical side of forming an argument, as I had been practicing that with Michael Bolton on Skype, so I knew the elements to build an argument. Those were “premise” and “conclusion”. With the help of examples the book showed some good uses of supporting and supported arguments, giving me a good ground to build upon – in fact just like the preface promised.

As this on itself might have been a good starting point to a person not knowing anything about logic and was just seeking a quick 15 minutes intense session on logic, this only made me hungrier to read through the whole chapter. I noticed that, if not the writing style or the content, my eagerness to read on was huge. I had to struggle every time to quit reading further.

4th part – The Sources of Illogical Thinking

I was a bit taken aback with the concept of writing about things that made you illogical. When writing about negative stuff some might absorb the “bad habits” instead of seeing them as negative. After reading the subchapter, I felt that it only made me stronger thinker and I was trying to spot those weaknesses – you might say - and try to find ways to mitigate them.

Skepticism was the topic of the first subchapter and it was really informative. It gave insight on selective skepticism and to behavioral skepticism – and gave some concrete examples. I began to think immediately about exercises I could to using skepticism in my coaching. I may have already done that but unintentionally. Not I could be even better at forming an argument. The book made some examples about damaging skepticism but tried to enforce the power of healthy doubt – doubt as a catalyst for learning.

5th part – The Principal Forms of Illogical Thinking

This 5th part was about fallacies. They were explained to be the typical patters people do/use to act illogically and to build illogical arguments. Usually fallacies appeal to emotions so they are more powerful than sound logic. Again by recognizing the patterns I might be better at building an argument that is based on sound logic.

The lure of using a fallacious argument is high, because it might be quicker and more effective than using sound logic. Even though you’re right and have a sound logic behind the conclusion, basing that on fallacious argument is almost never a good thing – it might bite you back when you least expect it. I had read something about the fallacies so this area in particular was really tempting.
Afterword
The afterword was a good reflection through the book. They stressed the concentration when arguing so you focus on using your logic in building an argument. I rarely read the afterword as I see no input to the meat and potatoes of the text. I did realize that the afterword did provide a fresh view to the book as a whole. It might even be effective to read the afterword /before/ starting to read the book itself as it can provide a fresh view to the book before trying to tackle the reading.

About the exercise

After having done the exercise, I feel it was a good practice. I might use it again but with a twist – I will write up questions about the first page/subchapter to a piece of paper and try to answer those questions as I read on. In that way not only will I illicit information, I will begin to understand the meaning of things.

The exercise was good fun as the text was close to my liking – it wasn’t a textbook but a guide, the topic was near to me, and it was short enough – so the exercise was a bit easy. It was good for a first experiment to this kind of reading, but I need to make this process more efficient. I might even learn more about this type of “stub skimming” (if there is no word for this type of reading, let it be that).

So right now the process goes like this:

Choose a book to your liking (any book will do)
Read the table of content
Read the preface
Read the first page of every chapter
Read the afterword

On every step, make notes and questions about the content
If there are fundamental questions about the content, read on and find the answer.

Thoughts

This is just one way to read. This is more like giving an indication of what the book is about. This is not used to understand to book but to have some knowledge of what there might be if you’d read on. This is a good way to tackle a book on before you read it thoroughly, because you already have questions about the content. On the time you re will systematically read it through (or parts of it) might be significantly faster and make it easier to understand.

Now I need to continue reading the book about reading a book. I think I will use this technique to give me a head start.

How to get anyone to do anything!

2012-11-13T08:06:00.001+02:00

This is how! Go ahead, read this post and you will find the keys to tapping into your or anyone's motivation. I will tell you how you can find motivation to do anything, or to motivate anyone to do anything! I will describe briefly the 6 steps that will make you find motivation to get things done, I will tell what is the force behind motivation and I will share some of my own experiences on success and “progress ongoing”.

Instant influence

I have written previously a post about what drives people to act. The Drive (written by Daniel Pink) has given many answers in how to motivate people in the modern society. For me, that lacked tangible examples, practical process and, odd enough, ways to motivate myself to be motivated.

I follow Daniel Pink on twitter and he posted a blogpost about something called Instant Influence. He just glanced the topic by asking two very powerful questions: “On a scale of 1 to 10, how willing are you to change?” and “Why didn’t you choose a lower number?” Immediately I started asking those questions on why I might want to do something. I began to defend the will to WANT to do something instead of finding excuses why I don’t want to do it.

The writer, Michael V. Pantalon has captured the essence of motivation in the book Instant Influence. It describes the process of asking questions from the “influencee” (he calls the participants of the motivation discussion “influencer” and “influencee”) and allowing her to find her own reasons to embark the road to change.

After I read the book I was in a motivational high and now I will share some of the secrets to you. I will urge you to grab a copy of the book and to read it yourself as this is but an excerpt from the book. The book has special ways to motivate yourself, change resistant people and coworkers, even strangers. There are ways to spot different kinds of indication of budding motivation on people that do not seem to be motivated. It’s quite quick to read and has plenty of practical examples on which to draw useful practices in real life.

The Instant Influence process is based on 3 cornerstones:

No one absolutely has to do anything; the choice is always yours
Everyone already has enough motivation
Focusing on any tiny bit of motivation works better than asking about resistance

Scare tactics don’t work! If you get bullied into doing something, you’re just as likely to choose not to do it. By saying things like “have to”, “should”, “must”, etc. just strengthen the barriers of resistance. Asking about “why might you choose to do it” is more important than telling the effects of not doing something.

6 steps to success

The book describes a process for finding the motivation. The process comprises of 6 steps. All individual steps are analyzed in the book and the power behind them is revealed for you to make the most use of the process. Every step has examples of different flavours on how to get the best out of the step with different people and situations. The process goes roughly like this:

Why might you change?
How willing are you to change?
Why aren’t you less willing to change?
Imagine you’ve changed. What positive might become of it?
Why are those reasons important to you?
What would be the next step, if any?

The first question is to allow the influencee to state the problem and to tell why she might want to commence the process of changing behavior. Asking “how might I change” may bring results but the reason behind the change could prove to be more important than thinking the actions. Trying to figure out how should one change can be overwhelming if not clear with the reasons behind the change.

When asking people “how willing they are to change” the question should be detailed to fit the situation. If I wanted to motivate myself to clean the apartment, I might ask myself: “How willing, on a scale on 1 to 10, might I be in clearing the living room table?” By breaking the task into smaller pieces and motivating oneself to do at least one of the smaller tasks, one can create a snowball effect and end up being motivated to clean the whole apartment and the garage! The number, which should be had in this question, is trivial but it creates a base for the next step.

Let’s say, I answered a “5” in the previous question. I might then ask, “Why didn’t I choose a 4 or a 3?” Then I will immediately start defending the reasons I MIGHT WANT to do the task at hand. This also gives you the opportunity to state the reasons, obvious or hidden, behind your budding motivation. Sometimes, questions 2 and 3 can give enough ground for the influencee to get motivated, but I always ask the influencee if she might be willing to answer more questions.

At the 4th step the influencee is allowed to imagine the world after the change. You can create a scenario where all the obstacles are cleared and the ultimate end result is reached, thus removing any negative influences that might arise at this stage. Focusing on the positive images might motivate the person to begin the journey to the destination, but remember to break the task into smaller goals to make the transition to being motivated easier. And I assure you, the smaller you make your goals on self motivation, the easier it is to start actually doing something.

When the influencee can identify the positive outcomes, she should be asked why those are important. Autonomy is the key here: “Why are these reasons important to *you*?” Drilling into the most deep and profound reasons might be intimidating, but after realizing that the deeper, most personal reasons are the ones that drive you to do things, you can get things done more easily and quicker.

The 6th step is important so that the influencee is clear on what she wants to do next in order to get gears turning. Again it is important to enforce the influencee’s autonomy and power to choose her actions. By asking “What might you do next?” instead of telling, can be the crucial element of finding the true motivation to do something. The action plan can be as simple as “I want to go to the living room and look at the coffee table.” or as detailed as necessary, verbal or written. But I encourage you to have an action plan. To make it even more powerful, state the reason why might you want to do it. “I want to clean the coffee table to make room for my coffee mug. I live my morning coffee when I watch the news and I don’t enjoy holding the cup on the sofa pillow.”

One thing to remember is to choose *active* actions in your action plan, that is to follow the “Dead man’s rule”: Never choose an action a dead man could do! “Don’t eat too much!” could be “Eat just enough to make you full but not too full.” “Don’t smoke!” could be “Smoke 2 cigarettes less a day for one single week.” Be active about the change, however small a change you’re aiming at.

Live exercise

This is an example of me using the instant influence on myself. I will be bith the influencee and the influencer. I will ask the questions and I will answer what is the first thing that comes to my mind – no later editing, but I will add some notes in brackets afterwards. I have a task that I want to do: I want to write a column to a testing magazine here in Finland. The due date is approaching (or went past already) and my brains are refusing to provide input to the task.

Influencee me: "I want to write a column, but it seems too hard."
Influencer me: "Why it seems too hard?" (I don’t fully understand what makes the writing so hard.)
Influencee me: "I can’t find anything meaningful to say. The ideas I have feel crappy and incoherent. I wish I could find a thread which I could then follow through the column." (I’m frustrated by the situation.)
Influencer me: "Seems like you struggle with a problem that feels too big. What is the smallest thing that you can do to get started writing the column?" (I try to scale things a bit and try to find some spark of motivation.)
Influencee me: "The smallest thing would be to… well… open Word and start typing." (I try to dodge the responsibility.)

Influencer me: "Seems reasonable enough. Why might you want to do it?" (I try to enforce autonomy. I also fell into sarcasm there, which is not good as I could have been more objective about the situation as a whole.)
Influencee me: "Like you asked, I want to get the column written."

Influencer me: "On a scale of 1 to 10, where ‘1’ meaning “not ready at all” and ‘10’ meaning “as ready as possible”, how ready would you be to open Word and start typing?" (I could have tried to push on the “why” with the reasons I want to get the column written, but I thought that I can always ask more about the deep reasons later.)
Influencee me: "To be honest, I’d say about a 7. I like seven, because it’s quite high but not nearly the highest as it could be. Ok. To be totally honest, I’d say 5." (When I really started to think about how motivated I am, I realized that my motivation is alarmingly low. The impact of really thinking about the number was quite important to me. It may not be to others, but knowing about the process, it felt really important to me. The number is arbitrary and is there just to form a base for the next question, but can create surprising effects.)

Influencer me: "Why didn’t you choose a smaller number?"
Influencee me: "Well… I do want to write the column, as I have promised to do so. I also want to share the thoughts I have on the subject as I think many other people are struggling with that kind of issues. It is also a good way to get my name out there to be seen as a writer. On a 4, I would be saying that I don’t want some of those things, but I do." (I started to defend my reasons. By this point I was ready to increase my number to 7, but didn’t. I already had some thread for the column formulating in my head.)

Influencer me: "Let’s say you have written the column. What would be the positive outcome of that?" (I created a happy, sunshine scenario where there is no evil and all columns are done within deadline.)
Influencee me: "I would get the appreciation of my peers. They have worked hard on their papers, and by completing mine I have shown the same dedication towards creating a good testing magazine." (I reflect my actions against others’ but it feels like a shallow reason.)

Influencer me: "Why is the appreciation important to you?"
Influencee me: "I feel that the status of testing professional needs constant visibility to the public and to the community. The appreciation feels like a materialization of the reputation in the community." (Here it started to get personal. I was thinking about stopping writing, because I had no idea where this talk would lead me.)
Influencer me: "Why is the reputation and more so the good reputation in the community important?" (Drilling into the most important reason.)
Influencee me: "Well… to be honest. I might feel that because I have no doctoral degree or the like to boast around, I must constantly prove myself to be worthy of the status I have achieved in the community. Or I think I have achieved it." (I’m constantly saying “to be honest”. I’m trying as hard as I can to be. As much as I want to succeed in the exercise and make it as authentic as possible, I want to get the column done in time.)
Influencer me: "Why do you feel that the status is important to you?"
Influencee me: "It makes me feel like I’m worthy."
Influencer me: "So, you might want to write the column because it might make you feel appreciated and worthy. Is that correct?" (Here I reflect what has been said and formulate them into a single sentence motivation statement. I also try to enforce the autonomy by checking that it is correct.)
Influencee me: "I guess so, yes - to feel worthy of the perceived good reputation."

Influencer me: "So what could be the next step that you’re willing to take, if any?" (I leave room for choosing not to perform any actions.)
Influencee me: "I guess I will reserve a 90 minutes brainstorming session using a mindmap to clear out my thoughts and to create a plan for the column. I will do it while in train to work as I have plenty of time then, but I will make a calendar appointment so I can remember it. That will help me to find the thread and inspiration for the column. I might even finish the text while I’m at it. If I can’t find a thread while doing so, I will write about not finding thread." (I made a plan that has a specific action, a reason to do it, and a situation to amplify the action. I also mention a next step, which I didn’t even thought I was planning. In addition to all that, I made a plan B if my initial effort fails to give results.)

Now we just have to see if I was able to finish the column in time. :)

---

PS. If you feel like trying this in real life, contact me through Skype and we can try to motivate you to do something that seems too hard for you to do.

Testgasm

2012-11-06T10:23:00.000+02:00

This is a blogpost to describe what was going on in the Rapid Software Testing class held by James Bach. This is not meant to be a comprehensive analysis on what happened or the lessons I learned but few highlights and hindsight analysis on what happened.

The dice game

...this is just a few of what we had...

Those that have been attending the dice game know that the initial exercise is hard. When one gets the idea on how the algorithm goes it’s easier to play variations on the game by group of friends or colleagues (not to say these are necessarily different). I (thanks to Michael Bolton’s course), Henri Hannuniemi and Sami Lehtonen (thanks to Antti Niittyviita) had played the game earlier and so we were grouped together and given a different algorithm than the others. I was so thrilled by the idea that I could use all the skills that I had learned to crack that nut open.

The game started and we were given a bunch of dice: a handful of regular, different colour/size dice; few D20 dice; few D10 hand drawn dice; a die that was in a transparent die; some “poker dice”, etc. We had so many variables that we became a bit confused. I started a list of different things that we could be analyzing. The size, the colour, dots or numbers, amount of dice, type of dice, arranging of dice, “zero is not zero” etc. We then arranged them so that there were different D6 coloured dice stacked together in different ways, five groups of five. James came to the table, we said “2” as a guess for every single dice pile and James replied “0”.

We had the miscellaneous dice lying in the stack nearby and I thought I ask a reply on that also. I said it “2” also and James replied “1”. A one? We had a huge number of different types of dice lying there. What could it be?

We proceeded to arrange the dice in a fashion that there were 2 or 3 special dice and regular dice bundled up so that all special dice were in use. All but one group ended up in a “0”. The one that was the “1” had the die where there was a dice within a dice. A frantic math calculation ensued. We tried to sum up the two dices together, but the result was always a “1”. So I took the die in hand and turned it so that James could see only “1” and a “2”, and we thought it was a “1”. The answer was “2”. Frustration!

Testgasm

We then analyzed the steps we took to get to that “2”. We had a couple of theories, but when the die was on the table, it was always a “1”. Heureka! We took five dice off the table and said “5”. And a five it was!

The thought process took 3 persons 20-25 minutes. The sparring between the team enabled us to try different even crazy-sounding ideas to good extent without exhausting our innovation. We simplified the data and made it more complex. We tried to look for changes in the output by varying the input. We used the different models of problem solving from our lives to figure out the pattern. We also solved a pattern composing of vocal input pattern (I save that for one of my exercise in the company) and one with a difficult mathematical pattern composing of differently grouped dice.

"Give me your hardest problem!"

Like James said, we were doing testing Kung-fu! Solving problems like matrial artists! Bonk! Blam! Thwaak! Zlott! Swoorsh! Phatam! Ka-pow! Like Batman fighting crime, we fought problems! (I’m getting a bit excited here, if you can’t read it from between the lines.) We all felt like we were invincible and we had the tools to crack every problem in the world! “Give me your hardest problem and I will solve it for you!”

The high after testgasm

After we got all the patterns solved we were all ecstatic about what we had done. We were in a problem-solving high! The word to describe the feeling would be “testgasm”. And truth be told, after a serious testing session where you find something awesome, something really important; you will get a testgasm. I’m not sure if other that testers understand the rush after a successful testing session; it is hard to explain. The joy of completing a hard task and feeling joyous about it in ways you never thought you could be. That feeling is something that testers all around are looking for when they test. Your face may light up and you yell “Yes! I got it!” and other people in the cubicle stare at you like you’re deranged.

Focus/Defocus

I had heard the concept of focusing/defocusing in Michael Bolton’s class before but I never truly understood the meaning behind it. ("If focusing is focusing, defocusing is the opposite of that") I tried to look for material online, but it was all vague and didn’t make an impact. The way that James described the method was simple: “When confused, focus; when frustrated, defocus.” Wow! When testing one sometimes loses momentum and struggles with a single piece of data for long time. Using input patterns that don’t find the problem may lead into frustration. I felt exactly that during an exercise about systematic testing.

James had us testing a piece of software that had a bug in it. We were asked to find the bug and then try to figure out why it fails. The input was a valid IP address. You know what I figured out? I have so strong built in mental models about meaningful number combinations that I was grinding my teeth and sweating to break that pattern. I had tried a pattern by testing the high and low numbers, duplicate numbers, you name it. Could I just be blind to the bug? Then James said “Look into your data. Can you see a pattern?” Yes I did. And lots of them! “Now try to find an input that is as different as possible from previous data.” And guess what IP address I used? “1.2.3.4” That’s right! I broke my pattern by trying “1.2.3.4”! What was I thinking?!?!

James was like “Dude! What the hell?” and I sat there frustrated and confused. Then I realized what he had meant. If I had drawn a line to represent my test data, it would have been like this:

I just needed to break the pattern and be more random and use data from between my clustered data pattern. And with first random IP address I put in, I found the bug. Later James explained why the program behaves like that, but I can’t remember the true root-cause of the bug, but I did learn a lot about focusing and defocusing.

Hung over (from learning)

It has now been two weeks since the course. After the class I was in a high that lasted through the weekend. I thought about giving a thorough analysis about the course but I see no need for that. I had the time to let the learning infuse to my spine and now I feel that the stuff I learned make even more difference. I did have an information hangover after the class and it was hard to get back to grips with non-testing work again. I was glad, however, that I could attend the Intensive course the next week so I wasn’t that bummed.

I recommend the class for everyone willing to improve their critical thinking, testing skills and/or argumentation skills. The exercises were good and to the point. The hot seat treatment James gave to some of us gave us experience to stand pressure and perform well when in a stressful situation. I also learned a lot about myself and the way I learn. It was also cool to hang out with great testers like Samuli Elomaa and Aleksis Tulonen.

I still have a long way to go and a lot of learning to do. (After James mentioned it) I began to think myself as a constant student, always learning. I promise James (and I will talk about this to Mr. Bolton) that I will try to compare the classes done by him and Michael. That way both of them could learn what could be done better or differently. That however will have to wait a few days (i.e. weeks) as I have a growing backlog of blog posts.

Are you part of the faceless masses?

2012-10-31T08:16:00.000+02:00

I was on my way home the other day when I happened to talk to a woman who works in HR in some consultancy company. We were talking about how to get oneself hired to a company and how to be one step ahead of the other applicants. With recent discussions with James Bach in my pocket I became challenging her claims about employing oneself and best practices thereof.

What she suggested was that by certifying one can have an advantage in the job market. If one is not certified there is no knowing what the person can or can’t do, right? Certification is the first gateway to rule out incompetent testers, right? I had some thoughts about this prior to talking to James but some of the arguments that I had been using were lacking momentum. James gave me some golden thoughts in how to be one step ahead of the cattle of unskilled certified testers (I believe that if skilled they will see that the certification will not get them employed).

Certified terminology

Certification by name certifies a certain characteristic of a person, object or organization. It is not comprehensive but directed to a specific area. It can be achieved by passing an audit, an examination, a course of some kind, to name a few. Certification is not to certify the skill of doing something but the knowledge of some fashion. It can be of terminology, syntax, operating system details, etc. None of these, however, point toward the skill of doing something.

The certification where you get certified by defining a set of terms is quite usual. You get the information from books and then you take the test, usually multiple-choice examination to ease the assessment process. You can basically get a certification by guessing the right row of answers, having a list of those answers achieved by cheating, or by memorizing a set of terms. Because the test doesn’t aim to assess the understanding of those terms the value of it is quite minimal.

As terminology changes from company to company, from context to context, we do not need to memorize a set of terms and apply them by force. We need to understand the meaning behind the terms we use and to explain them. Then, if conflicting with the other terms within that context, the use of terms must be adjusted. If you say “testing” and mean “systematic evaluation of the quality of the system using various techniques applicable to the context”, and the organization uses “uggabugga” for that same meaning and “testing” for coffee tasting, it might be good to adjust the use of terminology for that context. If you just keep using the term taught to you by some book somewhere, you will drive yourself unto a cul-de-sac of misunderstanding.

Proving skills and standing out

The testing certification provided by ISTQB is a good example on how certify a tester without any skills to actually test. It is a book examination, essentially. More so, there is a course aiming to pass the test. I’m not going to talk about the syllabus at all, but about the skills taught at the course, or the lack thereof. The certification doesn’t aim in proving skills of the tester. A tester with no experience in testing can go to the certification examination and pass before doing any testing at all.

A recruiter going through applications for a job look for something that might look for certifications as a proof of skill. When confronted by a certification that by nature does not measure skills but the knowledge of terminology (which obviously is the wrong way to go) the recruiter might confuse the person having skills. This is not to say that the applicant doesn’t have skills, they might very well have a huge set of skills, but they are not the characteristics that get you to the interview.

“If you don’t get to the interview then you cannot show your skills. That is why I use the certification to get to interviews!” I hear you. Read more.

Rising over the masses

The recruiters have a hard decision in determining who to call to interviews and who not. They look for something that stands out! You might think that a certification gets you the interview. Stop there for a moment. How many other applicants you think do the same thing? How many of the 500 applicants to a Test Engineer job have the exact thought of having a certification as a ticket to interview? 50? 100? 450? This obviously depends, but think this: The certification makes you part of a mass of people. By using a generic way to stand out, you’re “massifying” yourself – you become part of a gray mass that doesn’t stand out in any way.

Like I asked in the beginning, “Certification is the first gateway to rule out incompetent testers, right?” it actually is so. But it not a gateway only to rule out incompetent testers, it is there to rule out incompetent recruiters. A person without proper testing knowledge, skills and passion does not know how to recruit a good tester. He may know a little and thus relies on the magic of certification, at least a little. Even the most unqualified recruiter is looking for SOMETHING to make the call who to call to the interview. By having 90% of the applications look the same, they have a hard time deciding. The gateway works so that it rules out the certified testers and leaves those that have the spark, the passion and the skill. Do you want to be the one getting the interview or be ruled out because “you don’t have the spark”?

First thing recruiters see is the application. We are force-fed the template from recruitment agencies and we use that. We are afraid to be different and difference is what you should be aiming for! Instead of creating a dull list of what you can do and schools you’ve been to, do something else! Write a bug report where you describe your behavior and characteristics. Do an interview of yourself and post it like a newspaper column. Send them a video of you testing a product while explaining what you’re doing. I could go on and on! Be outrageous, but professional. The point is to make a statement. Send a filled template and you’re doomed.

Conclusions

When I had explained myself to the HR person on my way home, she said: “Well you’re obviously a guru, so you don’t need a certification.” That is not correct, although I briefly basked in admiration. I’m not a guru any more than the next guy. I have passion and I’m not afraid to show it! I have goals and I’m not afraid to tell them! I have a hard built reputation as a tester and I'm not afraid to promote it! (Maaret might say “He’s cute when he rambles.”)

Every single tester can be a professional, and they should. Every single tester can apply to a place where they want to work and get employed, and they should. Be ambitious, be excited, be passionate. And show it. Don’t fall into marketing trap and be part of the mass – be you!

And get refining that CV right now!

Flashback to Learning

2012-10-24T20:15:00.002+03:00

I rarely have the concentration span to write complex and analyzing posts. If I believe that the subject has more to it than I can scribble in 90 minutes, it will more likely become a candidate for an article and will be more fine tuned than a regular blog post. Now I thought I would write an update to my blog describing the second day at the Rapid Testing Course, but then I thought writing another a diary-like entry was not exciting enough - and I want my scribbling to be at least a bit exciting.

So why do I have to make a blog post about something that I’m not willing to investigate? I don't! That's the beauty of it! But I want to make a quick post on something interesting. In order to do a blog post from something that requires little to no research it could be about an experience that is worth sharing. This post is not from today’s class but from past but the topic was brought up today in the class.

James Bach and Michael Bolton use the Socratic Method to help learn stuff in their courses. To simplify, they ask a bunch of questions from a tester to squeeze out an answer - not possibly the right answer but one good enough. I got my share of the method in the class but I’m not going to talk about that. I’m going to talk about an event that happened 4 months ago. (Enter fairy bells tinkle and a wobbly picture to demonstrate a flashback...)

I wrote a white paper about six months ago about heuristic testing implementation that was discussed in a Peer testing session late last year. The article was about to be published in a testing magazine and it was fine tuned for couple of months by the editor and a couple of voluntary proofreaders. I still wanted to have a comment from James Bach and Michael Bolton as I have a respect for their opinion in all testing related issues. And so I sent a reviewed draft to them and waited for approval.

What then happened, I couldn't expect. I had high hopes on the content of my article as it had been reviewed multiple times by bunch of different people. I thought I was in a verge of a breakthrough and praises would that flying my way. Instead, James’ reply was simple:

“I'm completely opposed to this.”

What followed was an exchange of emails between me and James about the problems with the article. It concluded in a suggestion to remove the essential elements that I based the article on. I thought James had got it all wrong and I requested him to discuss the difference in views that we seemingly were having. Skype was the medium of choice.

We ended up talking for 90 minutes. First we were talking about the article itself and he clarified some points he had made earlier. Then James challenged some of the essential elements of the article and I tried to defend them as best I could. All the while doing so I thought better descriptions for the principles I was using. I was on hot coals during the conversation: if I had chosen a bad wording for my answer, he would grab it and ask the real meaning behind the words I was using.

The article did not survive, but I did. Later I was a happy to have endured the barrage and decided to hone the article so that I could later publish with pride and joy. I never really understood how much the discussion had given me, though. I had learned some very valuable lessons. The critique on the article was secondary compared to the practice I got performing under pressure and all the while holding to my beliefs. As James said in the course today, there is none worse than tester who is “pathetically complying”. I could have said “OK. I won’t publish! Just don’t yell at me.” and I would have lost all my credibility. I learned how to defend something even though I might be wrong. Ilari Henrik Aegerter gave me a coaching session once where we practiced exactly that: how to be able to defend your point. And so I became better at explaining myself and defending my point under pressure.

What I would have done differently is that I never really tried to sympathize to James’ point of view as I so aggressively tried to get mine across. I could have got more out of the conversation if I had listened more carefully and sought for meanings and advice that he gave between the lines.

Having shared this experience also enforced the learning that I experienced, for I was able to verbalize some of the stuff that I had thought only briefly. Next steps for me are to revisit the article bearing the real purpose of the article in mind, and try to make it better (if not perfect). The article is resting and collecting dust currently, but I will tackle the beast soon enough. I believe that the Rapid Software Testing course will give the inspiration boost that I need to get it done (although I think extrinsic motivation plays no part in this, as I already WANT to finish the article). Too bad I didn't sign in for the Let's Test! conference with the paper. ;)

One down two to go!

2012-10-23T18:59:00.003+03:00

And no, I will not link the King Diamond song here (even tho it’s cool). This blog post is about my experiences from the first (my second first day) at the Rapid Software Testing course by James Bach. I seem to be one of the lucky few who actually are able to have two goes at this amazing adventure to the deep dungeons of an exploratory testing mind.

Like I tweeted earlier, I fell into traps; the most obvious traps that can be set for a tester. I know I can do better so here’s a quick analysis on what happened and what could I have done better:

http://morningandotherstories.wordpress.com/2011/12/

Context: When I was confronted with a testing problem without a context, the first thing to do is to determine the context. Right? Here’s what I did: I thought I might sound too clever on asking and challenging, so I answered the question without determining the context. This lead into questioning my answer and making me realize that “we’re shooting live ammo here”. So I decided to sharpen up.

I could have done what I (try to) do every time I’m facing a problem: Understand the context, the people involved, the background, the current status, the mission, etc; communicate with the client, stakeholders, testers, etc. That could have brought the whole problem into a new light. I fell into a clever-trap.

Pattern and mental models: I had the advantage/disadvantage to see the formula for a pattern beforehand. The task was to determine what the pattern was. Those that have taken the RST course will remember this, right? I remember the point of this exercise being to break the assumption and to focus and defocus. Again, my previous knowledge bias struck in: I completely ignored testing the product and did some of the procedures I had seen done in previous classes. The pattern was the same, however, so basically I didn't lose anything…

…EXCEPT FOR EXPERIENCE! I could have spent the time testing in ways I had not tested before. Now I had the time to do something different. Instead I tried to look good by using Excel (like James Whitaker, I think) and I made a simple script to produce test data. I didn't even bother to check the logs, as I had checked them numerous times before. Should they have changed the behavior even a bit, I wouldn't have been able to identify the pattern. I fell into a showman-trap.

http://members.multimania.co.uk/mrmal13/saints/amardas.htm

Documenting: The task was simple: Write tests and justify all of them. James specifically asked everybody whether they had made a justification for ALL the test they were going to run. An exploratory tester documenting test cases and justifying them all with specific, detailed texts? Can you picture that? I could hear myself saying within my head “Yes, James” without even questioning my so obvious bias. I tried to be a good boy and wrote them cases and then feel pride.

The exercise was about justifying the testing but in a different way. My doing inexpensive testing and discovering something worth discovering, one can justify a more expensive testing. Like James said: “The cheap tests pave the way for the more expensive ones. They are the scouts that look for a good spot to place the artillery.” That comment alone is worth its own blog post. But instead of being inquisitive, exploratory tester, I became a test designer that is going to get fired. I fell to the guru-awe-trap.

So my first day was a success: more learning than I hoped for. I also thought that I had some form of advantage of knowing the stuff from previous, but it seems that I had misunderstood (or belittled) some basic principles of Rapid Testing. I felt some of the stuff explained more comprehensively, with sidetracks to bulk up the areas where I thought the content was thin (namely the modeling and project elements of Rapid Testing). I do wish James would have covered the modeling heuristics with more depth, but I will leave room for other areas for the next two days.

What I’m looking forward is the process of Rapid Testing itself. I somehow missed a whole lot on that subject when Michael Bolton was teaching the course. Also to hear more about the oracles would be nice. We scratched the surface today but we’re still to cover some of the mnemonics that I frequently use, like CIDTESTD, HICCUPPS, etc., but it was nice to see an update to SFDPOT with the Interface addition. I will be using that when I reinvigorate the workshop in near future.

The importance of the context

So as I’m heading home, I will share this one particularly funny event that happened in the beginning of the class. Here’s the story without context:

James Bach spit on Aleksis Tulonen.

If you add context, here’s what really happened: Some poor fellow was getting given the “Socrates treatment” by James and he had an act prepared for the response the guy was going to give. He asked a question and set a trap onto that question. He knew the answer would be something “horrifying”. So he took a sip of water after asking the question. When the poor fellow answered James theatrically spit the water from his mouth as if being so stupefied by the answer that he just couldn't bare it. Unfortunately the aim of the jet of water was a bit off. Aleksis, who happened to sit in the front row next to me, was a victim of the poor aim. Aleksis’ phone and computer got some droplets on them as collateral victim of this splendid act. Hopefully tomorrow’s newspaper doesn't have a title “A testing consultant got spit on by a guru”.

What it going on in my head? (Before the Rapid Software Testing course)

2012-10-23T08:10:00.001+03:00

Today begins the Rapid Software Testing course here in Helsinki. The course is mastered by none other than James Bach.

Anyhow, this blog post is a vent of my thoughts before the event and to explain some of my goals and expectations towards the course.

It has been some time when I previously talked to James Bach in Twitter or Skype, and to be honest I'm a bit intimidated. Not because of his status but mine. As a chairman to the Finnish Association of Software Testing I should pose some status as a testing professional. Not say I don't do testing but there's a chance that me not being able to do hands on testing regularly might decrease the status.

Also I found that as I didn't have any innovative things to say (due to being a bit isolated from the presence of other testers) I have failed to register as a speaker to some of the most expected conferences. Namely the Let's test! 2013. I hope that this course in addition to the like-minded people attending will wake up the sleeping beast within me to get cracking on the testing stuff again.

As for the course, me having attended it once before, I feel I'm in a different position than ones that haven't attended the course. I feel I have to know all the stuff better than any. But instead of being disheartened, I believe I can turn this into an asset. To have some distance to the subject might even make the event better for me. I have had the time to challenge the previous stuff and to filter out what doesn't fit into my daily work.

I mentioned that I haven't done hands on testing for few months. That doesn't mean that I have not used the exploratory testing principles to guide my work. As a maintenance manager I need to be able to grasp the concept of the issue really quickly to determine the proper course of actions to take. I have used the heuristic approach and namely the CIDTESTD-heuristics to guide through the first parts of the case analysis. Also as I need to know what goes out of the company, I need to sometimes do some testing for the implementation done by the developers. They are usually tested thoroughly but this is to give me a grasp of what has been done and how it actually works.

So I believe that when James invited me to join the course, it was the best thing that could happen to me even though the learning doesn't directly support my testing. More so I'm really expecting to have good chats with the James and other attendees of the course. I know at least that Aleksis is coming and it's great to see them both in person! This is gonna be a ride to remember! :)

Like I mentioned in Twitter: A gallon of coffee and some pastry should get the man ticking.

When in a rush, stop and look around

2012-09-06T08:19:00.000+03:00

This is a little recap of what happened during the summer and early fall.

I have had a quite summer. In addition my wife getting a great job from an esteemed Finnish restaurant and the scheduling followed by that, I have been busy trying to build my career within the company. The career building alone was enough to suck the juices out of me (deputing my boss, making connections, etc.) I found my previously hibernating hobby, miniature painting and modeling.

All that compared to my lack of self discipline to edit my workshop video (which became a hurdle I came to dread) resulted in a complete inability to update my blog or tweet about stuff happening around me, all the while feeling guilty about not getting stuff done.

However, all my networking, deputing and the effort spent within the company resulted in a promotion. The “deal” is finalized during the next month which will lead into senior position in F-secure in addition to receiving the responsibility of all platform maintenance handling in Finland (excluding some separate items). Being able to breathe a while and get to start rebuilding my focus, I decided to write this update post to get some sizzle going on in the blog.

I’m also glad that my wife (Love you, baby!) has been able to handle the restaurant manager job with such awesomeness that I almost envy her passion towards the domain. With all scheduling problems and prioritizing we were able to pull it together and now it pays itself back. A week’s beach holiday is ahead of us and we are to discuss about the move to the Helsinki area, which will drastically decrease my commute time (which is 5 hrs/day every day).

I was so empowered by Santhosh Tuppad’s blog post about highlights of the year I decided to write some of my own highlights from the past 12 months. These are all as in what I remember and may be incorrect, but this is how I view the world 12 months ago:

September 2011: I came to contact with F-secure’s awesome people when I applied for an exploratory testing role model position. I did not get the position, however, but they contacted me with a little different job description. They offered me a position as a second maintenance manager and a quality engineer.
October 2011: I got a role as a testing expert in Itella Corporation’s quality board (I don’t know exactly what the group was called, but we talked about testing and outsourcing) and came to contact with some very talented people. Although with somewhat different views I was able to suck in few good tips as a test manager on the way.
November 2011: I started working at F-secure. Also I got my first contact with teaching testing to a larger group. That sparked a flame for more workshops.
December 2011: The beautiful Maldives! A ten-day honeymoon at a 5-star hotel with my dear wife recharged my batteries for the busy year 2012.
January 2012: I got to try my wings in a feature team at F-secure testing client software. Great times with great people!
February 2012: I wrote the first draft of the Heuristics Testing Qualification which was evolved into a monster. By the summer I had talked with James Bach about the concept and I decided to rewrite the basic structure of the qualification. That is still on the drawing board but the first draft pushed a stone down the hill and it has began to “land-slidify”.
March 2012: I have no clue what happened on March, but maybe that’s a good thing. The highlight of March is that nothing worth mentioning happened.
April 2012: I had a workshop at my previous company, Logia Software Oy, where I… learned a lot about how to hold a workshop and how to arrange my presentation. Hard knock life, if that’s the correct expression, but ever so necessary.
May 2012: Turku Agile Days 2012! Testing with the stars! I met Anssi Lehtelä, Sergey Moshnikov, Lisa Crispin, Elisabeth Hendrickson, and lot of friends from Scandinavia and the Globe. I’m looking forward to having another go at Testing with the Stars as soon as possible (I might even want to judge one, if possible).
June 2012: The Nordic Testing Days 2012! What more can be said? Sami Söderblom as my trusted wing man (he'll hate me for saying that), all the great Estonian testers, the beautiful city of Tallinn. Ten out of ten. Also I got the chairmanship (actually it’s called Community facilitator) of the Finnish Association of Software Testing. In addition to all that, I met Rex Black and had some good conversations with him.
July 2012: Deputing my boss, Harri, as a maintenance manager. Almost the toughest four weeks in my life. That really helped me to understand the systems we have in more depth and the people behind the beating heart of F-secure.
August 2012: “Laatu ja testaus”, a Finnish testing magazine was published and I was able to sneak in a column of my own “Pekka kirjoittaa lehteen” which is “”Pekka writes into a magazine” (original, huh?)
September 2012: There is a number of weeks left until I go into to the to-be team as a maintenance manager and also I’m looking forward to getting my presentation for the October’s Tampere Goes Agile (there’s a twist involved, right Anssi?) and my University guest lecture about how REAL testing is done.

I do realize that almost all of these are career or work related highlights and that sums my year pretty much up. I have worked like crazy and during the summer I was so tired I couldn’t finish my reading assignment I had agreed with Aleksis Tulonen, the editing of my workshop video, and many other things left to the table by the hectic spring and the early summer. The two months I gathered strength have proved invaluable to me and I can start pushing forward with new spirit. I was in a rush to get somewhere, but I was wise enough to stop and took a breather (thanks to Pirita for saying that all over again to me during the summer).

I want to thank Santhosh for making such an inspiring blog post. That was the push I needed to get back on the horse and start blogging and tweeting with such gusto like none before.

New winds blow! The horizon is the goal! … I’m going sailing!! (I mean "I'll do more blogging”)

The magic medallion of testing - summary of a keynote by Rex Black

2012-07-04T11:54:00.001+03:00

This is a summary about Rex Black’s keynote about Testing and Quality management at Nordic Testing Days 2012. This was the first keynote on the second day. People were still tired from the evening activities and some even skipped the keynote altogether. I was keen to see Rex’s track as I had some… opinions about ISTQB and the certification system as a whole. So, to be there and be able to challenge him was an opportunity I didn’t want to miss.

On Monday we had "argued" with Rex about metrics and coverage. Rex commented Sami Söderbloms statement about not measuring coverage by giving an example. The discussion went something like this: “With all things being equal, the first tester returns his test report with 90% coverage and another with 15% coverage. Which one would you trust more?” Rex commented. I raised my hand (the inner voice screaming "Me, me, me! Let me answer!". Sami then said that I could answer the question. I tried to question the true coverage by asking about what has been found. Rex replied by pleading to the all-things-being-equal statement. All things that were found were supposed to be equal (so as important bugs, issues, etc.) “But all things are never equal in software testing”, I said. Later I realized that if all things were equal, how can there be a difference in the coverage?

If we have all things equal, isn’t the coverage supposed to be equal too? If two clone testers are put to test a product in exactly the same way, don’t they both produce the same amount of coverage in any way you measure? Change anything and all things are not equal. So if in an all-things-being-equal-situation we have difference in coverage, our model to measure testing might be faulty, the person interpreting the results may be biased, etc. So how can one make an example from a situation that is faulty by default?

Rex "the Scorpion Smacker" Black

The keynote however began with Rex warning about using the c-word (coverage) and the m-word (metrics). I immediately knew this wasn’t going to be pretty. ;)

Rex gave a few cases where a manager was oblivious about the need for skilled testers. One manager had supposedly said something like this: “The requirements of a tester: heartbeat, respiration.” That struck home right then. I knew these managers and product owners exist! I had been in a project where the solution to testing was “ask people around if they have the time”. I then asked around and gathered as good a bunch of people I could find… and I tried to train them to be adequate testers. Some became good testers, some didn’t, but I had a team.

Feels like the requirements for a tester in fact are the aforementioned heartbeat and respiration. In some cases, though, also a certification might be squeezed. If we find a tester with a certification, one has to be a good tester! Right? Rex mentioned in the talk (which I already knew from previous experience with the ISTQB) that people who certify themselves with the foundation level certification do not need any skills from testing before the certification. It is “an entry-level certification”, Rex says. So how come people with no skills are certified as testing professionals? This leads to a situation where unskilled, untalented testers that look better to managers than people with REAL skills and attitude towards testing. I that what it is suppose to be doing?

The certification thing got me so winded up that I almost missed the rest of the keynote while trying to douse my building rage. (Just kidding! ;) ) Rex had some good thoughts about how to veer the Agile testing more towards intelligent testing – away from “Unit testing + Acceptance testing = Proper testing” an more towards testing throughout the life cycle. Automated testing is there only to support manual testing*. Usually Agile testing is a Waterfall within the Agile cycle where testing is done at the end of the cycle (if we have the time). Testing earlier, reviewing the deliverables in time and early enough, challenging designs, etc. – not just automating unit tests.

Rex also talked about the cost of bugs, but there was no ground breaking new information about that. I have read that from the ISTQB syllabus a while ago. And I still believe that counting bugs and measuring them against each other will lead into biased view that “all bugs are equal”. James Bach said it well once that “bugs should be thought as unicorns” How many unicorns fit into a cubicle? Two?) How many bugs are in a product? I know this is generalization from Rex’s part but I think it dangerous to make such claims as (like I mentioned earlier about the decision-making skills of a manager**) people WILL make the tools out of the metrics to compare PEOPLE against each other. "I found 4 bugs and he only found 3. I'm better, right?"

Rex also talked about the quality management. He mentioned that good testing doesn’t make good quality in its own. I agree. We need to be able to start making good quality from the top, starting with directors. We also need to be able to improve the processes, tools, skills and communication to make better quality. We can do it all the time while we work by challenging bad behavior and encouraging good behavior.

The Badge of Knighthood of Software Testing

Anyway, I feel that the foundation level certification is not currently building the community towards good testing. It has become a magic medallion that is bought from the wandering gipsy saleswoman. And when the kings and queens see the medallion they say “This must be a skillful knight as he has the Badge of Knighthood”. And yes, the medallion is bought, not earned. The training courses for the foundation level solely aim to give answers to the exam questions. They do not encourage people to learn, but to memorize (the worst thing is that they might say that one doesn’t need this information in practice). Rex said that when his consultancy company holds these courses they focus on practical use of the things trained. I wish I could once attend one of his company’s courses to see how it is done.*** The whole certification issue might need a blogpost of it's own, but it will have to wait. Some people have already covered that for me.****

You might get a message that I didn’t like Rex or his keynote. I did in fact, and I encourage all of you to read Rex’s blog and the books he has written. I don’t say I agree with all he writes but they give you a lot to think about. Rex as a person is (to me) "a happy giant"*****. What I liked most about him is that he really listens to what you have to say. We had inspiring conversation with Rex after the keynote although I challenged him about the ISTQB. I hope to hear him talk again at some other event. And I was bummed that he couldn't join my workshop... :(

*) And to build confidence, some say. But, like Michael Bolton said in the Rapid Software Testing course: “Were not in the confidence building industry – we’re in the false confidence demolition industry!”
**) Says a guy who spent two years as a test manager and is currently a maintenance manager deputy.
***) Do you dare to invite me to a course, Rex? ;)
****) Jari Laakso's post http://jarilaakso.blogspot.fi/2012/02/test-is-dead-vs-istqb-kills-people.html
*****) He's like 7 feet tall.

High Six!

2012-06-15T23:33:00.004+03:00

"What happens in Tallinn stays in Tallinn."

That is not the case here as I will share some of the cool stuff that happened after the official Nordic Testing Days conference program. I had the grand master-plan to go into to the room and do some blogging, but obviously I chose to confer with my fellow testers.

The special event was at the 7th floor of the beautiful Meriton Grand Conference & Spa Hotel from where you could see the walls of the old town of Tallinn. The scenery was beautiful, the snack food was great, and plethora of beverages to suit the tastebuds of every mouth. More so, the place was loaded with thinking, breathing testers (which at one point demanded to go to the balcony to look at the great scenery). The opportunities to confer were limitless.

The conference organizers had invented this “speed dating” conferring game where a person had the opportunity to get to know another in 3 minutes. After 3 minutes the partner changed. Or that was how it was supposed to go. The people were so interesting so after 3 minutes the talking continued and the organizers had to go push people to switch partners. I met awesome people from Skype, Swedbank, Asa Quality services, and many other companies. The good thing was that they all had business cards. The bad thing was that I didn’t. Mental note: “Ask HR to get me some. In fact I DO meet people outside F-secure.”.

I had good conversations with Sami Söderblom, Jari Mäkeläinen and Rex Black about testing, economics and Jujitsu. Also Ainars Galvans, Helena Jeret-Mäe, Tobbe Ryber, Raimond Sinivee, and the guys from Playtech! I really appreciate all the insights that I got from you about test automation and Model-based testing!

The hotel staff then ushered us out of the building and we went to a German restaurant to have some refreshment. The Estonian-Finnish-Swedish group ended up talking about how to improve one’s career. All in all the discussions after official program was just as good as the tracks and workshops. It was nice to share thoughts with other like-minded. And it was cool to see the pictures from the evening activities! :D

A little more than a week after the conference, I’m still feeling uplifted by the good people of Nordic Testing Days at Tallinn, Estonia. I was in the train a few days ago and I saw something that once again brought all the memories back to my head: High-Six!

What happens when you put Estonian, Swedish and Finnish people in a German restaurant? -High 6!

Be the best known if not the best!

2012-06-15T21:31:00.000+03:00

This blog post is a summary and might not justify the zeal, the enthusiasm, and the humor the original keynote had. Again, this is my view about the track. There might be something that I have misunderstood, so challenge me. The first day's last keynote at Nordic Testing Days was done by Torbjörn “Tobbe” Ryber, a Swede with great sense of humor* and huge talent in speaking about testing**. I was never heard of this guy before although I had a book written by him in my bag!

Torbjörn "Tobbe" Ryber

I had expectations*** that we were going to receive a rant about getting oneself certified and perfecting the art of writing test cases, or something of that general direction. Little did I know that this was going to be one of those life changing experiences. Before the keynote I had some views about my own testing career and the direction I was trying to go, but the insights Tobbe would give. The track was called "How to become a really great tester"

The presentation started with simple introduction to what kind of career Tobbe had earlier, and ended into this magnificently inspiring talk about building a software testing career. From year 1995 he had been reading testing books and doing testing to some extent. If I remember correctly he was appalled by the bad quality of something their company was developing and he was thrown to test it. He had different experiences and events that affected the career choices he had made, but he tried to get as much information about testing as possible. Around year 2000 Tobbe decided that he was going to be the best known tester if not the best. Also there were no suitable classes for him, so he started to teach testing.

So, this guy decides that he wants to be a tester, and to be a good one. Can we just decide that we want to be something and then get it? Obviously we can. This reflects to my own career as a tester. If Tobbe started his career in 1995, mine began at 2007 by getting thrown into the deep end of software testing. I was assigned to do test planning, design and execution to a mail/parcel logistics software project. Having no experience of testing theory or practices, I began to search every single Finnish testing blog, book, and/or expert from which I could illicit information. I said to my boss that “I want to be the best tester in this company”, which was fairly easy as I was the only one.**** Nonetheless I had similar start on my career as Tobbe had; we made a decision and we started acting on it.

Back to the business! Tobbe describes his career in three acts: the second one beginning around 2000 and trying to float in the IT-crisis. He fought the situation by getting certified, by joining the Swedish Association of Software Testing, and by contributing to the community by teaching testing and applying his accumulated knowledge to his work. This all seems like an easy job, but I can assure you that while trying to do the best job at the office and simultaneously trying to gather as much knowledge and skills as possible is not a walk in the park. He started to build his fame by writing about testing, joining peer workshops and all kinds of activities. Eventually he published a book about Software test design and thus building even harder foundations to his career.

So if you want to be well-known in the community, you might consider the following:

Have something to say*****
Go and talk to other testers within your community
Hold workshops, trainings, tracks, experience reports******
Write about what you do and what you would like to do

I started my career first by reading blogs and articles. Then I went where other testers were and started conferring with them. I got my first testing connection by sending an email to Maaret Pyhäjärvi and asking does can I have some of her training slide sets. Then I started going to events and trainings to get more connections and eventually started holding workshops on my own. I also started writing a blog about testing, first I wanted to challenge the community to be more loud about itself and then about what I did and what I wanted to do. So basically I started to spread my network, and gathering experiences and connection.

Tobbe had achieved his status in the community by doing all kinds of activities that supported his career, skills, job opportunities and familiarity to others. He chose to do things that he liked and not to do things he didn't like (thereby making testing more FUN). He wanted to enjoy testing. During the keynote he never said “certify yourself, “do this” or “read this book”, he stressed the freedom of choice for people to develop their own career to the way they choose. One thing he stressed, though. Everyone should have a plan how to develop oneself. The route chosen is one’s own business, but without a plan the route is hard to be travelled. The plan may get changed during the travel – even the destination might change – but that’s a part of growing and developing. Nobody knows everything, but one could consider planning it ahead.

When	What	How	Why
2012	Have a public presentation	Search for conferences near Helsinki and propose a track or a workshop.	To gain confidence in performing and to gain familiarity
2012	Publish an article	Search for a suitable publisher and offer an original article about something testing related	To gain familiarity and to establish a base of references for myself or others
2013	Take the BBST exam	Talk to people who have done it and find out how, when, where it can be done, and WHY	...

I made my 5-year plan a year ago. I have almost achieved the goal in the first year, but I still have a long way to go. And I have also made a 10-year plan to complement the first. I have had a lot of sidetracks on my plan, but the overall direction has been the same all the way. I think Tobbe had had his share of sidetracks and obstacles during his career, but he is the best known Swede testing expert to me.

Just like Tobbe asked after his keynote, I will ask you: “What is YOUR Plan?” How are you going to become a great tester?

The first step is the easiest: Want it.

PS. My plan looks like this:

*) A Finn saying a Swede has a sense of humor means that he has an enormous sense of humor to the rest of you.
**) I haven’t seen him test so I cannot say he has a talent in testing. ;) I assume that he has some talent, but again this Finn-Swede-competition-thing might mean that he also has a huge talent in actually doing the testing.
***) Yes, I’m still a Finn. ;)
****) Later I rephrased it to be "I want to be the best in the company in testing" and later "I want to be the best known tester in the Finland".
*****) If you don’t have something to say you could start by challenging someone who has something to say. A good place is to challenge those whose blogs, papers, book you read. Even though the challenge might be Devil’s advocate –kind of challenge, it usually generates conversation and thus give you something to say (and you might learn something new).
******) You could start at your own office to get familiar with speaking out loud and to face challenging. You can then join peer conferences and share what you have already done to your colleagues. Eventually you can proceed to talk in conferences and events, if you feel like it.

Bringing flavor to the functional testing

2012-06-14T12:20:00.002+03:00

"Yo! Let's bring som flava to tha functional testin'!"

I had made a plan to attend at least one workshop on the first day. So instead of going to the Beta-testing workshop I decided to build my skills in the NFT-side. To me, non-functional testing is performance testing, security testing, conformance testing, etc. Things that measure the quality criteria of the product (how fast it is, how secure is it, etc.). As I am a mostly a black box tester, I usually try to focus on the behavior of the functionalities and what the product does. This doesn’t exclude the other approaches, but that’s just my main focus.

The workshop was Non-functional testing on mobile devices by Nikolai Pavlov. I was thrilled that I would be able to test mobile devices with an expert, so I was prepared to be blown away. Sadly, my expectations were not fully fulfilled. I will describe the session and what I thought about it.

First of all, I really liked the approach that compared functional and non-functional testing, the What and the How. I have been doing functional testing and some non-functional testing, but Nikolai was able to bring out the essential in both testing approaches. I did however disagree with the test-case based approach to the functional testing, but I did not challenge him for that. I was there to focus on the NFT.

Nikolai used simple but effective examples to describe the non functional testing as a complementary approach to the functional testing. “User MUST be able to sign in (functional), and Sign-in time should be equal or less than 5 seconds (non-functional)”. So basically the NFT can bring more flavor to the functional testing and thus make it more efficient and deeper.

One aspect of non-functional testing is to keep things simple. There is a vast jungle of non-functional requirements out there, so we should focus on the ones that bring most value to the product and to the users. At Skype (Nikolai Pavlov is a Mobile QE Lead at Skype) their main focus was on 5 things: application size, start-Up time, responsiveness, memory footprint, and battery life. Some of those things had never even occurred to me as a non-functional requirement, so I was really looking forward to the hands-on-part of the workshop.

Nikolai then presented ways to test those different aspects of the product. They had really cool tools and methods to test and measure the NFR. I was really impressed by the battery-life testing tool. Also the aspect of integrating start-up time measuring to you automate tests was a really cool idea. However after the theory part was finished, the workshop ended. “No hands-on?” the inner voice in me screamed.

The workshop would have been more efficient if Nikolai would have cut out some of the theory and would have given something to tests during/after his theory part so we attendant would have brought more substance to the workshop. I’m still thinking how I could test my Android-phone the “non-functional way”, but I have no place to start as we had no hands-on testing in the workshop. I wish Nikolai will do some adjustments to the presentation and offer some hands-on testing in the next session. But all things put together, the track was inspiring and got me thinking different ways to implement to my daily work. Maybe I could focus my effort on the memory consumption, threads and stuff… What about the conformance? Can I use fuzzing to make the apps crash? ...

The Adventures of Exploratory Monkey

2012-06-13T11:59:00.002+03:00

This is a summary of Sami Söderblom’s track about exploratory testing and finding the inner adventurer. He presented this at the Nordic Testing Days 2012 in Tallinn. I found this track one of the most interesting ones as this cuts to the core of testing by stripping the excess and unnecessary activities away and focuses on the essence of truly good software testing.

Before I start ripping the track apart (well actually quite the opposite), I want to mention that this is somewhat in line with James Whitaker’s views* about exploring the software. After watching a video about large scale exploratory testing** I saw great many similarities in Sami’s track. I wonder how much of an influence has James Whitaker been to this track…

Sami had some great stuff going on in the track about exploratory testing. Great to me, because he tackled some of the issues that I’m struggling with when I try to explain exploratory testing to people new to the concept. The loop of Design, Execution, Observe, Learn and Adapting was the kind of thing people should be familiar with. By removing some action from the testing, we will result in a cumbersome approach that hinders the effective testing that we are trying to achieve with exploring. Also it was great thing for others so that they can get a firm grasp of what exploratory testing is in its most fundamental level. Sami had great examples using the Battleship metaphor, the Great explorers of different domains, and the way of surviving with as little documentation as possible.

We have all played battleship game, right? B4 and c8, hit, destroyed, and so on, you know the drill. Some people think testing like the Battleship game and rely that if we cover all the grids by test cases we will find bugs. But the bugs don’t play by the rules! There are ships outside the grid! There are ducks instead of ships! There are mines within the grid! Why should we play by the rules? Why not do everything it takes to find all the ships? Use hammers instead of “C4” (or even real C4). Use a vacuum cleaner to suck in all the ships. Use an umbrella over the mine so you won’t break the environment by accident (and thus hinder your testing effort). Use whatever tools and techniques you have to get the job done! Cheating is allowed in software testing!

Sami introduced a few cool people from real world and from fictional world as his favorite explorers. Dr. House is an explorer, there’s no doubt about that. He tries all things he knows and utilizes all possible resources, techniques, tools, medicine, etc. to get the problem solved. He might try things that don’t necessarily cure the illness but that uncover more information about the problem. Sami also told about Sherlock Holmes, Gordon Ramsay and Jeremy Clarkson, and made cool examples how they solve problems or challenging tasks. This made me want to read more about this Sherlock Holmes, and I already started recording the House tv-series from the 1st season.

He talked also about reporting bugs. This is quite contradicting to the track made by Ainars Galvans, as Sami sees that everything must be reported as they might be a manifestation of something more severe. The root-cause is what matters! So if we don't know the root-cause, we might miss a terrible bug by thinking it's trivial.

All in all Sami managed to bring new information about the world of exploratory testing to the audience and about the building blocks of quality. I’m happy that he showed the Venn-diagram that had "testing" and "verification" in separate circles AND emphasizing that both of them need the other to be at their most effective.

I recommend reading Sami’s blog about exploratory testing. He has great thoughts about testing and quality. He will eventually write report of the conference, so follow the blog and hear his thoughts about his own performance and of others.

"All testing is exploratory!" -Sami Söderblom

*) “Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design” by James A. Whitaker
**) YouTube video about large scale exploratory testing by James Whitaker

The branch that you’re sitting on is getting cut

2012-06-11T18:11:00.001+03:00

The third track at Nordic Testing Days 2012 was a multiple case study or an experiment report from Kristjan Karmo from ASA Quality Services Oü. There were 5 cases that Kristjan introduced in his track, all real scenarios with some data changed to protect the privacy (also some figures exaggerated to make them more dramatic). They were all entertaining but each of them had a punch-line that summarized the case to a lesson learned. In the end all projects had one fundamental flaw that affected the results. Read through and see what it was.

The process is a tool - a fool with a tool is still a fool. Communication is the key!

The first case study one was a company called Wolf Inc., a company that wanted to change name and become Strawberry Inc. The task was supposed to simple: Find-and- replace and go to production. Simple, fast, infallible. No testing required. What happened was exactly the opposite. “Wolf” as a word changes in different situations: wolves, wolf’s, and even more if in a different language. Also all the logos, brochures, documents, templates, etc. were affected. All this was to be avoided by asking questions about the task, by listening to the people making the change. It was all about communication.

The second case was a “CRM on steroids” by a company called Fields & Co. There were lots of people involved, lots of locations, lots of documentation and interpretation thereof. The most catastrophic mistake was a misinterpretation of a date. The date was THOUGHT to be the “ready for testing” –date but it turned out to be the “ready for LIVE” –date. 1 hour session of critical exploratory testing on the product by all parties involved. Group effort and commitment to the end product saved the day this time.

The third case was a company called Forever Ltd. where testers were doing the best they could and producing bug reports. These reports ended up on the developer’s desk and were returned with a stamp “works on my machine”. The system consisted of multiple integrations of different products so the all the contractors said that the problem was on the other contractor’s court. The solution was to meet with all the parties and talk it through. People were negotiating about their defects and issues and then he proper stakeholder would claim the bug and fix it.

The fourth case was Pepper plc., a company that had a testing team of end-users. When the testers were introduced to the project, all testing done by the developers stopped. The problem was solved introducing a few experienced experts to the team and mandating the train testers to make more effective bug reports and testing was done using the exploratory approach. The lesson here would have been the experience and the structure the testers brought to the team.

The fifth case was a company called BadCom Corporation. The requirements for performance had been made early because the system was performance dependent. The product that came to testing was 200 times slower than the requirements stated. So the team did an effort to increase the performance and they managed to get it to be 10 times faster. That was still not enough, as the system still took lots of time to respond. An assumption was made that the 20 times slower would still be good enough. The reality was far worse at the performance rendered the system inoperable and useless.

So here’s what I think:

In the Wolf-case the work group didn’t know what they were doing or they were blindly taking orders. No-one questioned the orders by looking at the id-tag hanging from their necks, etc. So questions that needed to be asked were not asked, thus creating a situation where a consultant firm was called to douse the fire.
In the second case there were project management and consensus problems. Floor-level did not know enough about the scheduling thus making interpretations about them. What lacked was communication between stakeholders. The last minute exploratory testing show might have been a confidence boost, but feels like a show more than productive effort. Don’t know, but feels like it.
Third case is a typical multi contractor problem. Everyone’s interested on part made by them and will not think of others because they’re not paid to think about them. The more bugs the other contractor has, the better we look. So there was no big picture or team in this case and everybody tried to cover their own asses. Again communication and challenging could have done the trick and much earlier.
The fourth case was a basic bottleneck-situation, where the developers thought that they can now concentrate on their job and leave the testing to the test team. The problem was solved by amping up the test team, which was a good solution, but not what I’d had done. I would have talked to the developers and convinced them to do more testing and would have shown them the results if they did the testing.
The fifth one was burned even though a consulting agency did their best to get things better. Here the issue was realized so late in the product life cycle that the fix was almost impossible. The performance would have been the top priority regarding testing if it was a performance ciritcal system.

So, all in all, all cases were doomed because of the lack of conversation and the critical thinking of a professional tester. By outsourcing testing you outsource thinking, and might lead into these situations all over again. So think before ending in a situation where the branch that you’re sitting on is getting cut. Use challenging, questioning, feedback, workshops, to raise communication in within the project.

Communication is the key to success.

Making a requirements pie

2012-06-11T12:31:00.001+03:00

This is a summary of the track by Ainars Galvans at Nordic Testing Days 2012 and how I viewed the subject. The topic was “Care for quality, not for bugs! Do you know the difference?“.

I met Ainars the day before the conference at the hotel and we discussed about bugs and quality. We are on the same line with the overall quality but I disagree with some points he made. So here is what happened and how I saw it and some thought about challenging the claims.

“The best tester isn’t the one who finds the most bugs or embarrasses the most programmers. The best tester is the one who gets the most bugs fixed.” –Cem Kaner

See the difference?

True and true. Ainars had great thoughts about increasing the value of the bugs. By focusing on the bugs that had a story that compelled to the developer (and the triage of people deciding which to fix), you will get more out of the bugs that you find. When I think of myself as a tester, I tend to get as much information about the product and thus uncover as much bugs as I can. I know that by doing so I learn about the product, the risks, the critical areas, the things that people making decisions value the most. When Ainars said “don’t report the bugs that aren’t getting fixed”, I was shocked. Am I doing it the wrong way? I may have a huge amount of rejected bugs, but it’s my way of learning. What if I uncover some minor looking manifestation of a bug that turns out to be a showstopper? I don’t know if I don’t ask and communicate.

Usually when you start communicating with the developer about a bug that seems like a show stopper, he will immediately see that it should be fixed immediately. If he can pinpoint the problem, you won’t need to make a bug report if the problem is sufficiently communicated onwards. So this is where I disagree with Ainars; I will make bug reports but I get the important ones fixed.

Ainars had great thoughts about prioritizing testing. He said that he’s not going to spend his time on testing something he KNOWS is going to pass, so he tests something he doesn’t know that will pass. He saves time doing so and can focus on the important areas of testing. So you should always do the most important testing at the every moment.

How do you know what is important? Ask! I ask if there is some area that is valued by the product owner and I focus on that. Then I ask what the next valuable thing is and focus on that. By time I get some testing done I can start formulate my own view about the importance of different things. So Ainars had a good thing going on there, as he knew the product so good he was able to guide his own testing prioritization using his knowledge of the product. The knowledge acquired by learning and testing the product.

Picking up requirements.

Ainars also introduced a cool way to do exploratory testing. He called it “Requirements driven exploratory testing”. They were almost like test cases but more like missions or topics, which were then tested. They were measured using traffic lights: Green (good enough testing AND good enough quality),Yellow (not started) and Red (not good enough testing OR not good enough quality). I challenged the concept as the testing team was focusing on only documented requirements, and I still do! There is a need to test also things that the client takes for granted and things that are discussed but not documented. I also challenged the fact that requirements are usually ambiguous, and that “requirements are not items to be gathered”. They're not like apples that you can get into your basket and bake a testing pie out of them. Ainars could clarify that if he can. From the presentation I did not get an answer to that.

As a summary, I got a lot out of the track as it provoked me to think about how I do my testing, but also I got a chance to challenge the speaker. I feel that Ainars has a lot to say about this and I will be checking his blog as often as I can. I hope he has a way to address my concerns about the requirements and “not-important” bugs.

How to cope with few end-user-testers in a testing project?

2012-06-11T07:55:00.000+03:00

This is a summary about the 2nd track of the first day at Nordic Testing Days 2012, how I interpreted the process presented and what learning from that track. The track focused on building skills for the Business end-users to be able to test the system under test properly and as quickly as possible.

The track was performed by Maili Markvardt and was called “Testing: saved by the end-users”. I wasn’t expecting much out of it (I wonder why? Was I biased somehow?), but what eventually went down was very inspiring. Personally I have been in situations where the testing budget is so small that all guns must be brought to bearing. I thought this was one of those rants that “we didn’t have enough time” or “the client was behaving like child” kind of situations. Luckily it was not.

She started the track by presenting the situation: a total makeover of all information systems in a company, 7 large systems with ~90 interfaces, integrated in a “big bang” fashion. Immediately she got my attention, I’d been in a situation like that in my previous company (although not that bad, but similar on many levels). The system was done by many contractors and had about ~250 people involved. No professional testers and 1 test manager, Maili.

The problem was being solved by giving her a bunch of business people – people with no testing skills apart from some IT-skills acquired from previous life. So there was the lack of skills that needed to be taken care of.

How she handled the situation? Well, she trained the testers. The truth is that you can’t train people to become testers without them having enough time and motivation to be trained, or it can be very difficult. What she did was tackle the source of the problem: get a written mandate from the manager of these business people to be available as tester the promised amount of time. And holding them to that promise was (if I interpreted it correctly) an uphill battle. The business people obviously had their own work to take care of.

The would-be testers had little to none experience in testing. What Maili trained to them was the basic testing skills; mindset, test analysis and bug reporting. The approach was test case driven and governed by the test manager. Some challenges started to immerge at early points of testing; the business process was still unclear and under constant change, documentation was too complex, test cases too generalized, and people lacked the base knowledge to execute the test cases.

This is where I started thinking the possibilities of doing the testing the exploratory way. Could they have utilized the Rapid software testing approach to maximize learning and be more responsive to change? As the testers face these kinds of problems, strict and over-documented processes tend to fail due to lack of flexibility. I immediately reflected this to my own work and saw that we had the advantage to use RST to our advantage and benefit from the learning. Sure we also had problems, but the way we communicated with the stakeholders enabled us to make our testing more “to the point” and we uncovered lots of information that the stakeholders didn’t know they needed.

The ugly world of constant change took its toll on testing. Lots of bugs were found and not all of them were reporting real issues. The bug tracking process required the test manager to be a filter that would channel the bugs to correct stakeholders. Due to ambiguous documentation and knowledge about the interfaces (the testing for some of them was postponed to very late stages of testing), testing was difficult and the systems suffered from poor quality, and thus led into postponing the “Go LIVE” three times. The testing might have been the best quality available in that situation, but the amount of work forced the prioritization to ignore some areas until the very last days of testing.

All this put aside, Maili was able to create a process which involved described the process of training business people as testers. The process feels very sturdy and practical, but simple enough to be implemented by all test managers trying to cope with little resources. I hope people got as much out of the track as I did even though I didn’t expect much. Eventually I learned a lot about using what resources you have and to make most out of them. It’s the context driven way, I think: “Throw in whatever you have and the kitchen sink” to get the work done. To my view, Maili succeeded in the task that was very difficult to begin with.

Kudos!

The tired travelling man (with no business-cards to share at the event)

2012-06-06T00:24:00.000+03:00

The last day came and went at the Nordic Testing Days 2012 -conference and feeling a bit sentimental. I feel like I left a whole bunch of new friends behind the pond: Raivo Päts, Kaspar Loog and Kristjan Karmo to name a few. The last day as a milestone for me also as I held my first conference talk which was a workshop about Heuristic testing using Mind maps. I have video and slides about the workshop, and also some pictures when I get my hands on them. Main thing was that I had a blast and I got the impression that at least some people got something out of the workshop too.

So today didn't go as planned but I feel I made the right choices overall. I saw Mr. Rex Black talk about Quality management (which I will be doing a minor post later), I held my exhausting workshop (which I will analyse with more depth and because I like to talk about myself ;) ) and a long hands-on exploratory testing workshop by Mart Toom (a great guy with a knack for ET - I'll write a good analysis fattened with constructive feedback). I was planning to take the shorter workshop and attend the tracks, but I felt that I would get/share (the experience) more if I was able to participate in the workshop.

I have all my notes in mind maps. I will try to get them online as soon as possible for all the tracks. Some are less extensive than the others but I will write posts of the most interesting ones (not to say the others were not interesting but I may not have enough to share about those.

So, tomorrow I will be heading to Technical University of Tampere to join the Testauspäivät ("Testing days") and to have a lightning talk about mind maps and exploratory testing. Let's see how that event turns out... ;) Hopefully even more friends and peers to talk about testing with! :D

- Peksi, the tired travelling man with no business-cards to share at the event

The morning after (The second day of NTD2012)

2012-06-05T08:48:00.002+03:00

Rise and shine!

10 minutes until the event starts so I need to be quick about my writing.

I have the workshop in the morning so I'm a bit nervous right now, but that will pass after I get my slides up and the people to testing.

The Pekka's Choice for the Day 2 is the following (goes with the same formula as the yesterday's choises):

Keynote: "Test Management and Quality Management" - Rex Black (USA)
Workshop - Testing Real-Time IP Video Communication at Skype by Pierre Gronlier & Antonio Campos Domínguez & Marios Mpasoukos & Oksana Dementsova from Skype
"Testing in Agile methodologies – easier or more difficult?" by Lucjan Stapp (POL) Warsaw University of Technology
Keynote: Software stores our wisdom by Jaan Priisalu (EST)

Now I got to run to catch the Keynote by Rex Black! I'll be back!

- Peksi

Testing at Skype -track by Tiit Paananen

2012-06-04T13:42:00.001+03:00

Lunch == Toss the food into your voice hole and write summaries about the conference talks.

First was about the testing done at Skype by Tiit Paananen. The talk was inspiring at the least and below are my notes on that session. :D

One thing that I liked about the show was the concept of testing maps. Testing maps are developed to increase visualization of the testing process. People can choose the media that they present it but they must visualize the effort that they will put into the testing.

I will update on the other tracks as soon as I can, but the time between the tracks is so short and I also have to confer – that what this is about!

- Peksi, a guy willing to borrow an iPad as this fragging laptop is so hot it makes me sweat like a pig!

The wings of procrastination

2012-06-04T08:55:00.003+03:00

The morning came and went in the wings of procrastination. ”If I don’t go to gym I can sleep for 20 minutes longer. (Snooze!)” Now that I have rested and “broken fast” (I got that one from Game of Thrones), I can enjoy the conference fully.

Soon I will get to see the Skype keynote and see how things are done here in Tallinn. It has come to my attention that this is the first Nordic testing days –conference. The facilitation has been awesome here and hopefully the content is as good as the facilities. Stay tuned 'cause I'll be updating the blog throughout the session.

- - Pekka at 8:55 waiting for the conference to start.

Integer != Natural number (night before NTD2012)

2012-06-04T00:40:00.000+03:00

This is a blog post about my feeling on the night before the Nordic Testing Days 2012 conference.

I just came from the restaurant of Meriton Grand Conference & SPA Hotel. I was there chatting with Ainars Galvans, a Latvian tester that I met the first time today but has great ideas about testing, bugs and test management. We ended up talking about bugs and reporting them in a valuable way (by the way he’s going to do a track about bugs tomorrow here in the conference). He had a good example about interpretation of a specification. It went like this (sorry Ainars if I misinterpreted it somehow):

The testers were testing a random generator that had 2 input fields – “from” and “to” – and some basic GUI elements; buttons, checkboxes, whatnot. The application gave an output of random number between the numbers in the input fields. Simple enough. The number was supposed to be either integer or floating point (chosen with the checkbox). The application threw an error on negative numbers.

Isn’t integer allowed to be negative? I hope to hear more stories from him about bugs and specifications. That leads me to the agenda of today:

What is going to happen tomorrow and on Tuesday?

On Monday there’s the “How do we test at Skype” –keynote which I’m really looking forward to. With tens of millionsof users the quality of a product is very important. Sometimes even business critical. The other keynote for that day is the "How to become a really great tester" which is also sounds pretty interesting. That is after all why I am here – to become a better tester.

I decided to choose 1 session that I really look forward, 1 that I never thought I would find interesting and 1 workshop. Obviously this strategy allows me to attend more than just those, but I believe that I will get my mind expanded by the tracks and workshops. I feel awful to miss Kari Kakkonen's track, but if there'll be a webcast, I'll check that out later. Also the Behaviour driven development and test automation with Cucumber -workshop would have been great, but I have to choose.

So here’s my list for Monday:
- Testing, saved by the end-users, by Maili Markvardt
- Care for quality, not for bugs! Do you know the difference?, by Ainars Galvans
- The anatomy of testing- ASA emergency room practices, by Kristjan Karmo
- Exploratory Testing – find you inner adventurer, by Sami Söderblom
- Non-functional testing on mobile devices –workshop, by Nikolai Pavlov

Caffeine + entusiast tester = Blogging at 1:00am

After the first day I will have my head full of juicy information about quality, testing and bugs! And guess what! There’s the other day also! How great is that?!?

So, now I got to get some sleep as I hiked through the city to find the hotel. I was exploratory… hmmm… exploring of the beautiful city of Tallinn. Note to self: No coffee after 10pm. But <enter adult beverage> is still allowed...

Comparing love to eight - A response to a blogpost

2012-05-30T08:36:00.001+03:00

This is a response to a writing by Natalya Bosatskaya at Intexsoft.com’s blog. The blog post was named Scripted testing vs. Exploratory testing. This post tackles every paragraph individually and tries to raise some thoughts to people thinking the same way as Natalya in this post. She did a great job by trying to explain her points of view, but I felt some of them were off mark. I felt the need to write a longer response to her as the limited space of the comment field did not allow me to get my thoughts out correctly.

In this post, I will attempt to compare Scripted and Exploratory styles of software testing. On the third hand, scripted testing is seemed as a strict and serious process and exploratory one is seemed free and easy. But each test style has own swings and roundabouts. Let's look at them from different points and try defining appropriate conditions to use first one and second one.

It is a common mistake to think exploratory testing as “free or easy”. Exploratory testing (when done correctly) is a cycle of learning, testing and test designing. It is structured but can be as free as it needs to be. It doesn’t limit thinking but provokes it. Exploratory testing focuses on the cognitive process of testing, the lateral thinking and critical analysis of the product in testing. By referring as free, you might mean that it is guided by other things than documented test plans and scripts. Exploratory testing is guided by documents, checklists, feelings, heuristics, questioning, data, functions, missions – whichever is the most suitable way to steer testing in a context and in the situation at hand. Usually the exploratory testing focuses to test the most interesting/important/risk prone area of the product at any given time.

Scripted testing usually supposes two roles: test-designer and tester. Test-designer creates test scenarios beforehand: and then tester executes these test scenarios. Test-designer is a high skilled specialist and tester is a beginner at software testing.

It is true that scripted testing requires two roles. Why is that? Why not have the skills and the insight about the product in one person? That would make it cheaper, right? A beginner tester should learn about the product as much as possible so that he/she would not be a beginner. By learning about testing, about the context, about the product, about techniques, about tools, the tester gathers more knowledge that trying to reproduce scenarios written beforehand.

What happens when the scenario changes? Do we need the test designer to re-write the case? What if there is no time to run the test case that the designer wrote? Is that considered value?

Exploratory testing doesn't divide activities by roles and time. Tester thinks up test cases himself, executes them at once and according to the test results, he creates new test cases. It's obviously, that such tester must be an experienced specialist.

It is true that exploratory testing doesn’t have fixed roles. Exploratory testing does have roles. A person may possess certain amount of business knowledge and in a testing session he might take a role of transferring the knowledge to the other testers during the testing. He may have another role in a different session. There is no waste of time or effort by making written test cases beforehand, although they might use existing test cases as guide and information to learn more about the product AND the about the testing done using those scripts.

Exploratory testing is an approach, not a technique that you use to test a product. It is a mindset to explore the product using the skills that one already has and developing more skills during the testing by learning about the product thus being able to more accurately design future tests. A person that has no experience in exploratory testing needs to start doing testing the exploratory way in order to become an expert. No-one is expert in every context but they may form skills to be good enough in a context.

A test designer taken from the bushes is just as clueless as the beginning tester. But do you know how the test designer starts to design the tests? He explores the product, reads the documentation, questions the stakeholders, and looks for clues. He does exploratory testing but wastes the effort on writing the things down so that a “beginner” can then interpret what he has learned and try to replicate the thought behind the test case.

In case of scripted testing, your test team can consist of one high skilled test-designer (costly employee) and several beginners (low-paid workers). You will economize resources, new testers (even low skilled) can start working rapidly enough. Exploratory testing depends on qualification a lot. If tester has low qualification, he will use ad hoc testing in the guise of exploratory one.

Now you are saying that testing as an activity is a low paid job. Sounds like an artificial pay gap to me. A software designer should be a highly paid person who understands the product and the programmers should be low-paid workers. I'd like to think software testers as skilled group of engineers that in collaboration with the stakeholders (developers, project managers, customer) aim to deliver a quality product using techniques like questioning, testing, challenging, coaching, etc. I think the testers are as important part of a software project as a developer, although you might have a tester integrated into a team and have other roles also (but that's a whole other matter).

I do agree that a tester without a mindset and the structure might veer towards ad hoc. A skilled manager however understands the possibility of a new unskilled tester and guides the person towards structured, mission based exploratory testing. A person that has no knowledge about the product should be given the opportunity to learn about the product and to give ideas about how to test the product better.

You might say that a person without the skills to do exploratory testing is an exploratory tester. Given a chance to explore the product one might become more familiar with techniques, skills and tools required in testing the product efficiently. A person without testing skills forced to perform a task that is scripted eliminates the chance to learn and doesn’t give room to become more efficient.

Scripted testing gives you facilities of high planning and predictability. If we have ready test scenarios, we can estimate efforts on tests executing precisely enough. In case of exploratory style, planning is very difficult or impossible at all. There's no guaranty, too, that tester will execute all needed tests and not forget anything.

It is true that planning gives you predictability. That is why there are so many different ways to manage testing. Take Session-Based Test Management (SBTM); it is a documented way to plan testing in order to respond to the situation at hand AND take into account the future testing activities also. It is rarely so that things go as planned. Scripted testing is rarely able to respond to changes in the software. Let’s say a bug is found. We might need to take a little more time to execute some confirming testing around the problem, even do a another test or three. When the bug is fixed, it may require some additional testing. Might even happen that the fix uncovers other bugs. A set of carefully planned activities start falling like a dominos.

What happens when a test designer forgets something? What happens if the requirements analyst forgets something? What happens if the programmers forget something? Is the scripted testing able to respond to this situation? What happens if we run out of time and we have tests to run? Money that has gone into developing those tests that are not run goes to waste thus making scripted testing even more expensive (and you don't get to learn). Exploratory testing has no such waste.

Exploratory testing management techniques can tackle these things with predefined processes. When something is considered more important than something else, exploratory testing can change focus on the fly and focus on the newly important part of the product.

Scripted tester can give qualitative documentation. At least he can give test scenarios and reports about execution of this scenarios. Exploratory testers often have complications with reports. How can tester report what he has tested and how many tests still remain? How can manager show to customer what has been tested?

Test cases (just like bugs) are not objects of same size. It’s like counting 3 cars, 2 buses and a train – 6 things that move people. How many people are moved? How many things (that move) fit into a car park? Test cases are counted but how much is tested? One way to measure testing is the time spent on testing an area. An hour is an hour in every place in the world (OK, there may be some exceptions) so only qualitative measure should be time. An exploratory testing session takes 90 minutes so 2 persons doing testing for 2 sessions count as 6 hours of testing. How many test cases fits into 6 hours? 3? 300? You can’t tell, but I can tell that in 6 hours I can test an area (or areas) for six hours. Simple, isn't it?

An exploratory session might have a precise mission but allows distracting from the mission if it seems appropriate. Using the SBTM to guide testing you will always get a report of what was tested, that ideas came up during the testing, what bugs were found, what issues arose. A mission might be a user scenario or several of those. A mission might be to learn about “what does the menu bar do” by exploring the product, documentation and eliciting information from stakeholders. Documentation may be as simple as verbal description or as detailed as a screen-cap recording with Rapid reporter log files.

Using sessions as guide to what needs to be covered, we can adjust the plan as we go so that we add more sessions on a given area. At any moment we know what the current situation is with the information we currently hold. A manager should always interview the testers so that he/she can form a testing story which can be supported with gathered metrics (hours/functions, sessions/area, etc.).

So according to reasoning above, scripted testing comes to the fore. Let's find a few advantages of exploratory style.

In this part I disagree strongly. Let’s look at what kind of knowledge about exploratory testing puts scripted testing as the superior approach. However as my examples before were “to the point” and aimed to address the text only, some things about exploratory testing do take somewhat scripted approach while retaining the essence of exploration – learning, testing, and designing simultaneously though stressing different aspects at different times.

Exploratory testing is flexible and adaptive to changes unlike scripted one. If something changes in the application, test-designer must alter test scenarios, otherwise tester can't execute tests. Exploratory tester has test suits in own mind, so he can change them as fast as needed.

Even if we think the most scripted exploratory testing, it still has the advantage of exploring. Exploratory testers don’t need to keep everything memorized as we can use memos, checklists, heuristics, and post-it notes. The documentation fits the context and the need of the current testing situation. All unnecessary documentation should be shunned. Use the documentation as a tool for testing instead of the purpose or the product of testing.

Basic work of scripted tester is boring and monotonous. Exploratory tester has interesting and creative tasks. He does different kind of work, he is designer and executor, so his work is not routine.

Exploratory testing can be monotonous, but the an intelligent exploratory tester finds clues in the monotonous parts of testing to learn more, improve testing techniques and to design better test ideas. If a scripted test becomes monotonous, that could be a hint that it should be automated to give more time to actual testing. Exploratory testing utilizes lots of tools, automation scripts, basically everything that supports the testing and makes it faster. “Throw everything and the kitchen sink” analogy is good to describe the thought behind utilizing resources in exploratory testing.

And exploratory testing can become a routine task, but a good exploratory tester changes focus, de-focuses, makes assumptions and tries to see behind inference, look closer and look at the bigger picture. Exploratory tester turns the routine into his advantage!

In case of exploratory style, tests are created and executed almost simultaneously, so it lets starting tests execution and uncovering bugs earlier.

True. Why shouldn’t scripted testing start earlier? What’s stopping you? Is it the test design part that’s taking so long a time? You have the designer doing (what seems to me) exploration so that he can design the tests. By not putting all the time into writing the testing can begin earlier and can achieve much more learning in doing the testing. And why force the “beginner testers” to wait? Let them dig in also and learn as they go forward. The test designer can still make documentation as in missions for the testers, but retain the exploratory approach and put his skills into good use.

In the end, I will cast one more disadvantage of scripted testing. It's the pesticide paradox. If the same tests are repeated over and over again, eventually they will no longer find any new bugs.

That is why a test getting repeated several times should be considered to be automated and the effort can be put to exploration of the parts that the automation doesn’t cover. Automated tests can check the product and the parts that already work and leave the testing to the testers.

Repeating tests is like repeating the same question all over again. Does that bring value to the tesing (sic)? Does that bring value to the tesing (sic)? Does that bring value to the tesing (sic)? Does that bring value to the tesing (sic)? There might even be a bug in the test itself thus leaving some important areas untested or poorly tested. Automated testing requires also analyzing and exploring (they’re code after all).

In my opinion, it's not correct to consider that one test style is better than another. Each style can be suitable or not in dependance of goals, test process organization, customer requirements and other reasons. And what do you think?

You are correct again. One approach does not supersede others. They are all context dependant. However I see that in every context there is a need to improve. So why not try learning while testing? By forcing people to do testing and NOT learn is a style that is should not be considered suitable in any context.

We may do harm to the community by comparing two different concepts to each other. Like comparing a dog to a blue, or a love to eight (which by the way in a certain context is possible -> love=zero). I do however see that there are too many misconceptions about exploratory testing and that false knowledge must be corrected. Exploratory testing is just like driving a car: we respond to stimuli to adjust our thinking, bearing, or speed. We learn while we go into situations from the behavior of others, the car, and the environment and will determine the right approach as we get the grasp of what is going on. We do not stop the car at every situation and check the car driving manual to give us instructions how to handle the situation. Why do we think that testing requires us to rely on scripts that (in best case) are interpretation of someone else in some different time and context (or entirely obsolete)?

Porridge is bad for you!

2012-05-21T10:01:00.000+03:00

"What?! What is he talking about?" This blog post is about challenging one's criticism and trying to make it more effective using simple methods. This post is about moving away from unhealthy criticism into constructive critique and feedback. This is about finding the right mind-set.

Why do people criticize?

"You're doing it all wrong!" "Your tie is hideous." You've seen it. You've heard it. Probably you've even done it. I know I have. And in most occasions I have let my self-criticism be clouded by someone else’s opinion about the same subject. By not having a concrete opinion of one's own it's easy to adapt to criticism of someone else.

Let's take an example of a guru that has strict criticism against one subject - a porridge (seems like a neutral enough). We all know that porridge is good for us, right? What if a nutrition guru says that porridge is bad? What do we do? If we have huge respect on that guru's thoughts and doings, might we blind our own judgment with the upward gaze towards the guru? We might just take the guru's opinion granted and start proclaiming that porridge is bad for you.

One way out of this bad equation is to step back and challenge one’s own critique. Is it justified? Are you making an assumption? (Great blog post about defeating assumptions by Ilari Henrik Aegerter) What if the guru was wrong? After making sense of what do YOU think, then you should back the critique up with facts, not opinions. By finding the facts, you might be looking for biased facts, but at least you have something to back it up. It's obvious (to some) that a biased opinion should stay as an opinion, but they rarely do. Instead of being opinions they become statements supported by chosen facts.

Doing basic critique, source checking, challenging, context projecting, you can find the root cause of the guru's opinion about the porridge. Does he (our guru is a he today) have an agenda of his own? Are there hidden meanings in the critique itself? Does it provoke thinking instead of criticizing the product?

How do people criticize?

"When giving feedback, do it like so: Always give good feedback in public and be precise about what was done well. Always give negative feedback in private and be precise. Try to find the solution instead of the one to blame." This was said by my father who has decades of experience in management and leading people. I have always thought this as the fundamental guideline of critique. I think most people know this and agree with this, but how come most people don't act accordingly?

Let's say that the guru had discovered some facts that "Ye olde bran porridge" has all sort of chemicals in it that disable some growth hormones on a child. Obviously that's a statement to be told to the public, right? And as we hold the guru in high regard, he is mandated to present his opinion (possibly supported by facts) in some public media. There are channels in which you can present a complaint about food (health inspector or some kind of an agency) and they will take the necessary precautions to tell the public that "porridge is bad for you". Possibly they have first discussed with the porridge company, who might have taken the product off the market.

The guru might give criticism about porridge in public and have the wrath of the porridge company on his shoulders. He might not care as he's a nutrition guru and has an agenda of his own (hoes he?). Is the guru doing the right thing expressing his opinion so loudly in public? Is the guru promoting himself instead of giving critique? Was the bad thing in the porridge, in the chemical, or in the company making the porridge?

Where's the difference in the approach between the two models of critique? Was the guru able to achieve the goal of his criticism through a public channel (which ever the goal might have been)? Was the "behind closed doors" critique more efficient than the "in your face" critique? They all depend on the context, obviously. What was the goal of the critique?

Feed-forward

Some people think critique is feedback. Well it kinda is in some extent. Feedback however can be constructive even when the feedback is negative. Feedback is given when someone asks for it; critique is given when ever. Feedback is not trying to make one feel happy/sad but to make them improve; critique is about making a statement. When giving feedback don't sugarcoat it, instead say what YOU like and you'd like to see improved. "I liked the taste of porridge and how my stomach feels afterwards. To make it even more healthy I would not put in the chemicals that prohibit my growth."

As the feedback is a kind of a thing to be asked for, critique is the kind of a thing you just blurb out. Feedback has a purpose and it is meant to improve the one receiving the feedback. Critique has the tendency to provoke something. Conversation, debate, hatred, etc. Challenging can be more effective a way than critique. Challenging the critique itself can become the most valuable feedback there is!

Is the content self-justifying or do we need to empathize to support the critique?

There are tons of guides in how to give feedback without being critical. I know a dozen occasions where I have let my judgment be clouded by numerous things that have lead into bad critique and undesired results. Here's one:

I try to promote intelligent testing and intelligent approach to quality in general. I also believe that certifications that focus on the certificate itself are no good. A certificate that focuses on skills in a field that requires skills is a good thing; artificial certificate concentrating on a narrow view about best-practices (and only knowledge thereof) is a bad thing. This is what I thought and still think. I was having a discussion with people I think highly of about “what is your opinion about ISTQB-provided series of certificates”. By making a comment that the certificate looks good on paper (with some unflattering spices), I provoked a series of questions about “how do I back up my statement” and "do you even know what you're speaking of".

The questions stuck home and I started to think of how I really thought about the issue. The fundamental thought behind the issue remains the same, but as I have not delved deep enough into the syllabus, the history thereof, the initial goal behind the syllabus. Am I eligible to make claims about the issue? Was I repeating what the other people were saying and them making myself feel important about myself by making a rash claim? Does my opinion really matter in this case and could I do some good without being so loud about it? Is there a possibility to raise conversation about the issue within the certificate organization without sounding like a zealot?

With the comment I made (which was criticism at its worst) I thought the content of the comment was self-justifying. "Obviously all the people were thinking the same so I just said it out loud." Even though some of them were, they rightfully challenged my comment and forced me to think about it. What was my goal when stating something like that? What was the desired outcome? Praises to me? More Twitter followers? To raise conversation? To sound like a dumb-ass?

What I did achieve with the comment was for me to be able to criticize my own behavior and claims. I once claimed (in Finnish) that one way to achieve the best quality of an end-product is to "Murder you darlings" - by finding the most direct route from the current point into the desired point. By removing all the excess and self-promotion from the content. To go directly towards results. In making the comment I a was focusing on "sounding cool" instead of trying to use the words as a tool to achieve a goal (which apparently was shrouded).

Did I hurt someone in the process? Can't tell. Not directly, I assume (Pekka, you're assuming things).

Did I achieve the goal? Can't tell. I wasn't aware that there was a goal.

Did I learn something? Oh boy, did I!? ;)

I don't know

2012-05-18T14:40:00.005+03:00

What's this post about?

I don't know. That's right; it's about "not knowing".

I spend the two days at a coaching course by TNM Coaching and we had a great time there. There were really good conversations about topics regarding coaching and I will delve more deeply into the ones that had most impact on me. Before I go deeper I will share some insights that I learned at the course about questions and the answer "I don't know".

The fact of not knowing

We all get asked questions that we may not have the answer. Some questions are just too complex for us to understand or we may not have the skills to answer that question. For example someone asks you about the amount of stars on the Northern sky, so you'll probably answer "I don't know". In this case you may not have acquired the necessary knowledge base on the topic and thus lack the ability to know the answer.

Could you answer differently?

When we answer by saying "I don't know" we subconsciously diminish ourselves. We give ourselves the impression that the knowledge is required to be "something" and by lacking the knowledge we are lacking as humans. It's a human behavior thingy of some kind, I think, and it comes naturally if we don't have the answer thought up.

If we could spend some time to think about the answer we might be able to avoid the "not knowing -trap". A difficult question requires a bit of analyzing. Do I need that knowledge right now? Could I check it up somewhere? Is there a reason why I have now acquired the required knowledge to answer this question? Do I possess the knowledge already but effectively forgotten it? By answering a question with a question (be it mental or verbal) you may find a better answer than "I don't know".

I don't know if I want to answer this question

There are different situations where you answer a question with an "I don't know". Sometimes the answer is to avoid answering truthfully. In a coaching session when another person asks questions and helps you solve your problem the answer "I don't know" may come in up. This poses interesting issue with the coach as there may be answers behind the "I don't know".

At this moment comes a point where the situation needs to be evaluated. Is it reasonable to try to find the answer behind the dodge or is it better to let it be. If you decide to let the issue untouched it should be stated. You may agree to speak of the topic at later times.

If you however mutually agree to go deeper behind the dodge, one good way is to eliminate the psychic lock (a Jedi Mind trick) by a simple question: "If you knew the answer, what would it be?" or "If a situation presents itself, what would you or someone else do to solve the situation?" The wording reaches behind the barrier and encourages the person to use the capabilities he or she has and start seeing the solutions. This may not however work always, but it is one part of the probing and facilitating the coachee to be able to verbalize his or hers issues and find the solutions.

More coaching stuff coming up!

This is my insight onto the subject of "not knowing". I got the inspiration to this from the coaching coach Vivienne Ladommatou who spent two days with us at F-secure to help us be better coaches. I really admire her wisdom about Genuine Interest and I think that could be the next post regarding the coaching.

I will be making at least some kind of a blog post series about coaching, especially the things that matter to me the most in coaching. I will do some practicing to hone my skills so if someone is interested to help me with my quest to become a better coach, feel free to contact me and we'll figure out some time slot and issue that we start discussing about using the coaching process.

So just tweet or Skype me, or comment under here, and I'll arrange a coaching session that best suits the context. When will be a good time to coach? Well... I don't know. ;)