Reading Practice

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:

1. Choose a book to your liking (any book will do)
2. Read the table of content
3. Read the preface
4. Read the first page of every chapter
5. 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!

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:

1. No one absolutely has to do anything; the choice is always yours
2. Everyone already has enough motivation
3. 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:

1. Why might you change?
2. How willing are you to change?
3. Why aren’t you less willing to change?
4. Imagine you’ve changed. What positive might become of it?
5. Why are those reasons important to you?
6. 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

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?

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

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!

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)

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

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

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?

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.

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!

"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!

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

"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

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