image credit: http://j.mp/y6XGfm

Many people have wanted to look in the future and see how things are going there. This is what I am about to do right now. I can tell you exactly how software testing will be in the year 2032. Want to hear more? Ok, here we go:

It will be different

I have to admit that this was kind of anticlimactic and maybe even a bit disappointing to the ones among you who are always keen to get all the nice little details served on a dinner plate and spoon-fed to your mouths. Sorry, I have to let you down. Well, to be honest, no, I am not really sorry.

Go back to 1992. Almost no internet. No smart phones. Very few testers. Mostly highly scripted test cases in waterfall processes. Who would have thought how today’s testing world would look like. Although, this video is kind of interesting. (As a side note: it also reflects the role thinking of 1969.)

Assuming that there is an acceleration in the development of new technology and a somewhat less speedy development on the human side it would be crazy for someone to “know” about the future. This highly dynamic and complex system is not very transparent for crystal ball predictions. So, don’t fool yourself into believing that is possible.

What is thinkable?
Computer science realizes that it is inherently a human and social science. Therefore a lot of thinking will go into how teams can collaborate better. The stereotype of the non-communicative nerd developer will eventually prove to be wrong.

Software development practices most certainly evolve in a direction that becomes even less error prone. Future compilation mechanisms will prevent many more of the errors from happening. Hence, less of the “stupid” sort of bugs. That means it will be more difficult to find bugs.

Testers on the other hand will have fully understood the concept of applied epistemology and will use a rich set of heuristics during every testing activity while having stopped completely to whine about their poor state of affair.

Hm, some spacey element is still missing here. Ahm, ok, let them all have a huge gadgetry of enhanced reality goggles and exoskeleton support with intelligence enhancing psycho pills implanted directly in the brain. And maybe find use for some of these, too. Or something the like.

What won’t happen?
Everybody who thinks there won’t be any testers in 20 years is indulging in crazy talk. No, we won’t have everything automated because thinking cannot be automated and therefore the design of automation needs human brains. Ideally, brains with a tester’s mindset. Running automated tests is checking, not testing.

Automation is important, too, but it is not everything that is needed for wholesome testing. And just think of it: Writing code in 2032 will still be a very, very manual process in the deepest sense of its meaning, assuming that developers still use their hands to write it.

What can we wish for?
I would wish that testers in general develop a pride for their craft. Whenever somebody with the title “tester” says she/he hasn’t read anything about testing it will be as if somebody was swearing filthily in a church while the pope himself is present. Unheard of.

So what is my message here?
I think it would make sense for all us testers to spend some time reflecting on where the journey is about to go. On the way we should all keep learning new stuff and keep our senses alert and our brains busy. Let’s learn new stuff every day.

This morning testing was somewhere, then the day passed and already now it has progressed to the next stage. I am very curious to know how it is going to be in the future.

What’s your view? How do you think software testing will evolve over the next 20 years? If you could influence it, what spin would you give to software testing? What is it you would like to see more? What less? Tell me more in the comments below.

tags: testing, future, skill, craftsman

Q1. Can I write a blog post that is inspired by a comment on a previous post?
Q2. Can I name the person whose comment inspired me?

Ethical questions these are. And fortunately they are quite straightforward to handle:

A1. Now that is the beauty of being in charge: I can do whatever I please here in my hood.
That would be a YES.
A2. This one’s trickier: If I had a comment by someone I know but who preferred to stay anonymous in her/his comment, then probably no. If the commenter has stated his real name, has a picture of himself as an avatar and will be stated as an example of asking a very good question, then with high probability YES.

Who is it? Who is it? What’s the question? What’s the question? It is my friend Jesper L. Ottosen from Denmark and his question on the previous post was:

Where is the semantic definition of the ">" operator, it seems it operates on "k" functions?  In layman's terms: how do you determine "more knowledge"?

First of all I would assume that within our context-driven family there is a consensus on that there is no such global thing as “more knowledge”. Let’s explore some dimensions:

People Skills/Supporting the Team
I put this first. Not just so, but because I believe that testers who do not have a sensorium for the necessity of interpersonal skills will never achieve anything of long term value in organizations that are inherently built on team work. And team work means - well - working together.

Test Techniques
Now, this might create the impression of being a parrot who is able to list the names of test techniques as they are requested by some multiple-choice questionnaires . That’s not what I mean. What I mean is the ability to approach a testing problem with the mental tools necessary to solve a problem. Which leads to the next dimension:

Problem Solving
There are (at least) two fundamentally different areas of problem solving. First: At school where the problem might be served as a well defined question and might sounds like this: “How long was the Thirty Years’ War?” The answer to that question would be: “30 years”. Problem solved. Second: “Test this!” Answer: Well, there is no answer to that. There are just many more questions that need to be asked. Or in other words: The problem field is only fuzzily defined. You need to find a way to make sense of it. And you don’t get 10 points for a correct answer neither.

Software Development Abilities
No, it is not a disadvantage if you know how to code. But that’s something you already know. And one shouldn’t use double negatives. They take more time to interpret and are error prone on the sense making side. [Refactoring the sentence]: Yes, It is an advantage if you know how to code.

Fast Learner
I was recently asking myself if there is a correlation between fast learning and general smartness and it took me virtually no time to decide that: Yes, there is a correlation. In what way does smartness help being a better tester? Well, if you learn fast, you may use your learned content faster to do testing. And if you do testing sooner, you start to find bugs sooner. Actually not only sooner, but you actually find them based on your knowledge you just acquired. If you’re not a fast learner, you might miss them completely.

Creativity/Lateral thinking
Get your lateral puzzles rockin’ your brain cells. It creates agility on your ability to come up with good tests. And good tests of course find good bugs. Obvious, isn’t it? Now, go and find instances where this is not true. Or only half true. Or something completely else. Turn it upside down and then back again. What do you have now? Did you follow me? If so, can you explain?

Good Observer
Some time back I bought new glasses. One of my testers immediately noticed. He was the only non-glasses-wearer who noticed. (People who wear glasses seem to notice more often if somebody else wears new glasses). He does not only notice glasses, he notices a whole lot of good bugs in our product. He is a good observer.

Explaining/Teaching others
That is an ability you should either have yourself or if you don’t have it, then you have to fly in James Bach or Michael Bolton.

Inspire others
This one goes very much with the first category, the people skills. Testers who are able to inspire other testers to become better at what they are doing, are very valuable team members.

Curiosity
Don’t click here.

Experience (Been in the business for some time)
Ever heard of the 10’000 hours rule? It states that if you deliberately exercise something for 10’000 hours you get really good at it. Ok then, let’s do some 10’000 hours of testing.

Reader of Books & Comics
Can it be that readers of books & comics are just better testers? Who knows, it might be true. And I am sure I have a scientific study somewhere here that confirms my theory - let’s see….hm, just cannot find it right now. I am sure it is somewhere.

Resistance to Stress
If you’re resistant to stress, your heart keeps on beating instead of attacking you in the middle of a test cycle. Having a heart attack makes testing really hard. I put this in the “knowledge” section because handling stress can be learned.

Resistance to Stupidity
You know it when you see it. My take on this is that humor helps a lot. People should nevertheless have a finely tuned bullshit barometer in order to detect it in a timely manner.

So, whenever you employ new members to your team, I would recommend to test them on the dimensions above. And please, tell me your dimensions in the comments below. Thanks.

tags: skill, knowledge, craftsman, education

In a book - I cannot remember which one - I read that if you print a math formula you will immediately lose 90% of your audience. I am free from worry here, because you - dear readers - are all nerds and number maniacs. So, I know you stay with me. And the ones who are about to leave soon, I’d like to offer some compassionate farewell words:

“Bye, Bye, and may you always remain unbothered and safe from formulas wherever you go .”

Ok, my dear socially awkwards, here we go. Something you often encounter in your tester life is the following:

k(a) > k(b)

whereby:
k = testing knowledge
a = e.g. Alice
b = e.g. Bob

let’s further define that “knowledge k” may consist but is not restricted to the following:

• number of books/articles about software testing or other useful topics read, understood and successfully applied in practice
• knowledge gained through collaboration with experienced masters
• empirically gained knowledge

let’s also further define that:

• Alice (a) and Bob (b) are human beings
• and more specifically testing human beings.

or to put it in simple words that wouldn’t have shied away 90% of the readers:

Alice knows more about software testing than Bob

So, both Alice and Bob work in your team. If your goal is to advance the knowledge of your people what would you do? And now comes the crucial question:

Who should teach whom?

Alice should teach Bob, of course, you might say. Now, let me tell you my dear friend that the gun shot answer to that question is wrong. Again, as you should know from your testing experience the obvious solution is at best incomplete. Same here. Of course Alice knows more about testing and can teach Bob quite a lot. But maybe Bob is a natural born coach and can therefore coach Alice. A coach is not somebody who knows more but somebody who can elicit self-learning in people.

Furthermore, they could together form a study group where the dynamics of the group helps them both to advance. And certainly advance more than if they had studied alone.

There are also some dysfunctional learning devices, such as:

• criticism: “I don’t like that you don’t know it better”
• demanding: “I want you to know that! Now!”
• ex-cathedra lecturing: “Test Plan, bla, bla, bla, bla, important, bla, bla, bla,….”

Let’s wrap up:
If your team wants to become really good at software testing it helps to constantly keep on learning. There are many possible paths to advance the groups knowledge. Choose the right paths. And: Just because you don’t like something (e.g. a formula) you shouldn’t give up right away. Be open for new experiences. There is no place for narrow-mindedness in software testing.

tags: coaching, teaching, skill, craftsman

I assume you are a professional software tester. If that is true, then it means you are good at at least two things. You ask good questions and you are an excellent observer. So, here is a small puzzle. You’re ready? Ok, you’ve got 5 seconds time to come up with the answer. Below are two images of knots.

What - in your opinion - is the single most dramatic difference between the two?

1…2…3…Go!

Here’s one

and here’s another one

Time is up! Did you notice the difference?

No, the most significant difference is not that the first image has rougher string edges, that is just because I am not such a good photoshopper and because I was a bit sloppy with the magic wand when I synchronized the color hues of the two knots. I decided to leave this small flaw in the image to mislead some of you.

The proficient observers among you have of course immediately noticed the different path the string takes:
1. Over-under-over-under-over-under
2. Over-under-over-over-under-over

The first knot is a so called granny knot and the second one is one that is called a reef knot.

And now comes the important part: Although both knots look almost the same, the first one (granny knot) is much inferior to the second one (reef knot) when it comes to the strength of the knot. The granny knot easily becomes undone if you pull on the strings. Or, in other words, if you challenge the knot, it falls apart.

Hah! And now it is easy to make the connection to software testing. There is a lot of testing that looks like testing but isn’t. It is just playing testing and not the real thing. These are the granny knots of software testing.

Some examples:

• Calling something exploratory testing that is actually only mindless clicking about
• Rigorously following the steps in test cases without switching on the brain
• Any record and playback test automation
• Reporting tons of metrics that fail to answer any meaningful questions
• Talking about 100% coverage without answering: “Referring to what?”
• [your own example here]

If anything, please, be aware of your testing granny knots. Examine your testing practices thoroughly in order to identify areas where you only superficially test or where your practice is simply wrong. Stop doing them or, if possible, correct them.

BTW: Are you somebody who is constantly re-tying your shoe laces because they undo themselves? The reason for that could be that you use a granny knot instead of a reef knot. Have a look at this instructional video to find out.

tags: disfunctionalities, review

image credit: http://j.mp/zgdpTY

Shall we open our philosophy bag and draw out three beautiful, albeit difficult sounding words? Yes? Ok, here they are:

• Episteme
• Phronesis
• Techne

Given you are not a philosophy-historian-tester I assume that you are currently thinking: “Gee, what the heck does that have to do with testing?” The brief and crisp answer is: nothing and everything.

None of the three concepts is related to software testing directly but they are all very relevant when doing software testing.

Let’s clarify: Episteme, Phronesis and Techne are three different forms of knowledge.

1. Episteme is what is commonly known as knowledge you can e.g. read in books, or what is known as propositional knowledge
2. Phronesis is the knowledge of familiarity or practical wisdom
3. Techne is the knowledge of application or craftsmanship

For the sake of honesty: I am pretending here a slight bit as I have not read the primary source itself which is The Nicomachean Ethics by Aristotle. (Although I have ordered the book and it should be delivered to me soon)

Let’s say you read a book about software testing. The writer is a nice and knowledgeable person who really well describes the most fascinating testing techniques. At the end of the book and after having highlighted the key parts with a highlighter you close the book. What has happened inside you? How is your brain re-wired now? Can you actually have your hands do what you have read about? Could you teach it to others?

Now, this is the beauty of software testing. You need to do it in order to become good at it. It is not sufficient to only read about it no matter how much material you work through. The portion of tacit knowledge is huge with an experienced and skilled tester.

And this is for all the certification sectarians among you:

Scribbling a check mark at the answer some insignificant people with an outdated view on software testing have claimed to be correct in a multiple choice questionnaire is the lowest and most useless form of proving knowledge.

And it is skyrocketing on the stupidity scale. How dare these people speak about professionalism in testing when in fact they are a greedy bunch of money makers selling their overpriced pretentious courses and at the same time do not have the slightest clue about what software testing is.

OOOOOk, cool down again. I get heated up by this subject a bit too easily but it is one I simply fail to ignore because of its damage it does to our profession. May Techne be our guardian angel to protect us from ignorance.

Whenever you start applying knowledge you have just read you feel clumsy and insecure. This for many people would be a reason to not pursue it any further. Just embrace the feeling because in order to ever master anything you need to overcome this first dip. Milk, honey and chocolate await you at the other end.

tags: philosophy, knowledge, craftsman, certification

CURRENTLY ON HOLD - NO COACHING SESSIONS AT THE MOMENT


During the past few months I had Skype coaching sessions with James Bach on a regular basis. Recently, we started to reverse our roles (I was the coach and he was the tester asking for coaching). I have gained a bit of experience in coaching testers. Now, I would like to sharpen my saw and that is why I have this offer for you:



How does it work?

• You contact me and we try to find a date and time (my Skype-ID: ilarihenrik)
• We use the messaging system of Skype
• We’ll work on what you are interested in. If there is nothing specific I will come up with something on my own
• I will do this by the use of the socratic method. That means I will try to keep your brain busy by asking demanding questions
• This offer is without obligation for neither part
• As already mentioned: it only costs your time; not your money
• You allow me to use the coaching transcript for my purposes

Here is some feedback from participants:

Thanks a lot Ilari Henrik for the session and pointers to communication model.
If that is the case then I would like to give feedback on the session.
1. Very interactive
2. showed patience
3. Very well received because I was little nervous
4. built good repo
5. Helpful
6. Encouraging
Looking forward to make a difference...
Thanks,
Savita
http://savitamunde.wordpress.com

tags: coaching

You lean back in your expensive executive leather chair puffing your H. Upmann cigar smoke in the face of your subservient employees and then you laugh far too loudly while lifting your legs and placing your expensive bespoke brogues on your desk.

You have successfully changed sides. Yesterday you were a tester, now you are a manager of testers. Great, isn’t it? And while you indulge in complacency in your splendid new corner office, what might soon happen to your testing skills shall be exemplified with the following image:

image credit: http://j.mp/wHvCiA

It was in November 2007 when I was promoted line manager of my test team. We have four different roles: Testers, Test Engineers, Software Developers in Test and Test Managers. The size of the team has always been between 13 to 19 Testers. My team is great, I love them all. And being a line manager is very rewarding.

If somebody asked me I would say that I follow the Servant Leadership style. I am familiar with DISC (myself being a strong I and D with a significant share of C) and Process Communication Model (Base: Workaholic, Phase: Rebel). I concentrate on the “what” and I am agnostic about the “how”, “when” and “where”. I constantly try to keep on learning; currently I am an avid listener of the Manager Tools Podcast.

So, where is the problem?

There is a fundamental difference between being a tester and being a manager of testers. Given the size of your team is big enough, the line manager part of your job becomes a full time activity. Now, what does that mean? Well, if it is a full time job, then obviously you are no longer testing that much yourself, are you?

And what happens if you do not practice anymore? You become fat and ugly.

I don’t want to be fat and ugly. In the same fashion as many people start jogging after Christmas gluttony, I decided to start my own little jogging program. Only dwelling in propositional knowledge won’t make you better at all. These are some of the things I have started:

• Regular Skype coaching sessions with James Bach (next session: tonight)
• Registered with uTest.com and started testing to reeducate myself (And they even pay you but I think I am going to donate the money to charity)
• Challenge my brain with Lumosity, Khan Academy and Code Academy
• Vowed I will submit session proposals to at least 3 conferences this year
• Try to learn from testers who are active on Twitter
• This blog is actually a result of my reasoning about testing (writing == reading your own thoughts)

Here’s an invitation: If you are from Switzerland and you are serious about testing, please read on. And by “serious” I mean:

• You regard testing as an intellectually demanding activity
• You are context driven
• You strive to become really good at software testing
• You value honest feedback
• You sneer at useless certifications

PLEASE do contact me, I want to talk to YOU. Let’s form a context driven school of software testing group in Switzerland. Let’s get better at Exploratory Testing. Let’s solve puzzles. Let’s challenge each other. Let’s become world class together.

tags: skill, management, craftsman, learning