Let's Test is just around the corner!

If anyone missed it, or perhaps simply don't care, there's a great software testing conference in Stockholm next week. Let's Test 2012
Somehow I ended up in the role of conference chair or conference general or El Commendante ;)
(think I've used all of those titles in various places)
And now it's about that time!!! Let's Do It!

Maybe I should bring an old whistle and some sweat pants and shirt, my old clipboard and make some noise like back in my football coaching days ;)

Nah, think I'll come as myself today and not 20 years ago :)

For those of you missing this opportunity: Too bad! It's gonna rock like nothing has ever rocked before!

I'm looking forward to seeing all of you who are comming. I'm not gonna make this rock alone. It's all of you comming to the conference that will make this really rock!

Why do we test? - A bit more on the subject

I'm very happy with the response I got on my last post about the book project. I thought I'd stay on that subject and write some more about it.
My starting point for this project was the "Why" that seems to missing or at least very strange when you encounter some PM's and others that thinks that brush test off with: "Oh, that's getting to be too much. We don't need you. We don't need that much, better do it ourselves", and other similar comments. I'm trying not to get stunned and speechless when I encounter such ignorance, and I do believe that's exactly what it is, about test. This is of course an educational issue and sometimes you need a clever approach to be able to get the point across and teach these people about test. It is probably not easy and it is challenging. This is a good thing. When it is difficult and challenging it forces you to think about your craft and it forces you to work on your arguments and teaching tactics. Even if it's difficult to embrace the chance to learn and become better at our craft in a situation where you most probably is pretty upset and down right steaming mad, try to cool off and use it to your advantage if you can.
This "Why" depends on the context just like the other "Why"'s that I'll try to cover.

These are some of the different "Why"s that come to (my) mind:

• Why do we test? - on a general and perhaps abstract level that's related to non-testers attitude towards test, as a craft and as a service.
•  Why do we test? - on a personal level. Perhaps I test because I love to explore and enjoy discovering things, or I test because it's a nice job and it helps me pay my bills, or I'm not a tester I just do this because the PM told me I had to.
•  Why do we test? - in this particular project. It may be regulatory demands that needs to be fulfilled or it may be a business critical production system that has high availability or high security demands. The reasons on this level are not always as clear as they perhaps should be. Being clear about why we test on this level will help when decisions need to be made about how much effort and work is needed when designing tests or when designing automated checks. Communicating the reasons is also
•  Why do we test? - integrations. This is not as obvious when you think about it as it might look. Think about it.
• Why do we test? - performance, in this particular way or at all. This is also not as obvious as it first may seem.
• Why do we test at all? - Why not do automated checks and run those and be done with it? Why bother with testing? Do we need real human beings with brains and minds of their own testing this? 

I am far from done with this, I have only started to write and I will try to make use of the community to gather stories and experiences. There will be more on the blog as I write and I guess there will be one or two posts about writers block and distractions. It's only human, I hope!

Why do we test?

I recently started writing on what will be my first book. The title was the thing that came to me first together with the idea of subject. Why do we test? That's the title, at this point, and my intention is to gather up my own experiences and the experiences that are shared with me by colleagues and other testers around me. My hope is that it will be of some value to someone and most of all I view it as a great opportunity for myself to become a better writer. Writing is a large part of what I do as a tester and test manager. Strategies, plans, reports of different kinds are sometime too large a part of my job. I enjoy it so I shouldn't complain and I take every chance I can to make these thing more useful and usable and as short as possible. I'm sure I'm not the only one who have experienced that large documents never get used, never get read. They tend to collect dust on whatever disk space they occupy.
Back to the main question: Why do we test? The obvious answer would be: To learn. That's a correct answer but it's hard to convey why we test and what the value of test is with that short reply. It needs to be followed up, and backed up, with the reasons and arguments behind it. It is also different things to different people and that is one of the major challenges when communicating the Why. More than once have I seen test have its allocated time cut down and even completely scrapped in projects. Many times it has been obvious that the decision maker(s) have a very different view of what test really is and what test really does. More than once it has been too late to change the decision when I've gotten a chance to try to enlighten them about what test is and what test brings to the table but now, collecting and writing this book, I will build a nice collection, for myself and others, with experiences and arguments concerning why we do test.
I'll get back to this topic more as my work on the book continues.

A special thanks you to Mike Sutton for helping get off my lazy behind and write a blog post! He is writing to, here.

I may call it the Bolton heuristic

This is jolted down rather quickly and I will revisit it and edit it later. It's one in the morning here so it is what it is. This is an idea and we'll see where  it goes.

Michael Bolton tweeted about how he discovered that he had missed out on how his mother had been promoting the use of mind mapping for years. These things happen, and they probably happen to most of us sometime. I started to relate this to test and saw how it could help me see things I might otherwise miss. This is how my thinking goes. I like to look at the big picture and remind myself of looking up and try seeing a bit further. This is a good thing, I believe, since at least I need to be reminded of this every now and then. A problem might be that I forget to look right in front me and assess whatever it is that is close, right there. So what do I mean by close and right in front of me? Well, I call it close if one aspect is close. For example it may be close emotionally but far away physically or it might be close physically but emotionally distant or intellectually close but emotionally and physically distant. This way I get several ways to look at close and several ways to assess the close things. It will also be helpful to me to shift focus from the larger picture and scale to the near and close. This is just the first thoughts on what I right now call the Bolton heuristic and I'm sure I'll get back to re-work it later. It's inspired by Michael Bolton and without him I would not have thought about this at this time or in this way, so thank you Mr. Bolton.

Off-Shore? What?

Today I more or less lost it when I got tired of hearing people referring to off-shore. Yes, I know what they mean and I know that money talks and I understand that. But we’re not talking about some undefined place or undefined people. Of course the ones talking about off-shore here and off-shore that generally don’t talk about people either. It’s all about resources to them. 

I don’t use the word resources about people. I think it’s disrespectful and I feel like live stock or office furniture or a server rack when people call me a resource. It can get worse, and it does occasionally, and you are referred to as unit. Well, people, I am not a resource, I can be resourceful but that’s something else, and I’m definitely not a unit! I am, believe it or not, a human being, a person, a tester. So, can I do anything about it? Can you? Yes we can, as someone said. We can stop referring to people as resources and we can stop referring to India, the Philippines and other places as off-shore. We are talking about countries and people in those countries. Sure it’s easy to keep going until some new buzz word shows up but like a wise man said: You must be the change you want to see in the world. He was an off-shore resource in philosophical and political thought.

I will not use off-shore anymore; I will say India, Estonia, the Philippines or whatever country I mean.  I can do it if I remind myself often enough to do it and make it a habit. That’s a change I want to see.

As a student of psychology I don’t think it’s strange in any way that we do this, use a label that gives us a bit of distance from the complexities of dealing with other people. It’s a very natural thing to do. That doesn’t make it right, in an ethical sense, and it also leads us towards stereotyping. That’s also an easy trap to fall into and I haven’t seen anything good come out of that behavior either. Yes, I am opinionated and I believe in my convictions and I will let you test them if you please.

Does it really matter what words we use? Of course it does. We are human beings all of us and emotional and sapient beings. I described earlier one kind of reaction to being called a unit or a resource. I tend to get mad also. I respond emotionally to the words used to describe me. Since I don’t think I’m all that different from other people I will not refer to them as units or resources either. If it hurts me it may hurt them to. It also serves another purpose. It’s a way for me to try and describe the complexity of the world. It’s easier to make it look easy and simple when you just use vague description like “off-shore”. It’s easy to forget and be blind to the fact that working with distributed teams has its own set of challenges and they are a bit different than the challenges of working with a team where everyone is in the same building. I enjoy working in distributed teams because I like working in new constellations and I learn a lot from working with new people. There are all sorts of good things that can come from working in teams that distributed around the world just as a lot of good things can come from forming a great team where everyone is situated in one place. It all comes down to people and how we interact. I believe that using the right names for people and places is a good start to getting a good start when forming teams. It’s easier to get off on the right foot, as it where, if we start with this pretty easy way of showing each other some respect.

These are my opinions and I stand by them. You may disagree and that's fine to, it means you also have strong opinions and that's a good thing in itself. It's when we don't care that we stop learning and stop evolving.


(This post was also published on the EuroSTAR blog)

The certification experience

I have always taken pride in the fact that I have no degrees and no certifications since leaving high school many years ago. I must confess that it hurt my self image and my rebel heart when I agreed to get a certification. My manager, who ranks at the very top as far as managers I've had goes, wanted me to get the ISTQB Foundation certificate. I agreed to do it. Why? There are several reasons for this decision.

• I felt that it was OK to agree to it since I only started at this job a few months ago. But I also let my manager know that she'll owe me for this.
• I was curious about how this would be taught and what exactly was in the test.
• I wanted first hand experience so that I could criticize it and know what I'm talking about when I do.
• I'd get a chance to meet some more people working in test. Networking is always a priority for me.
• Probably the most important reason was this: I saw an opportunity to question the stuff being taught and hopefully that would get the other participants thinking and questioning as well.

There are many reasons for doing this but as you may have noticed I didn't expect any amazing revelations and I didn't expect to learn some new amazing skill I could use in testing. That would have been to naive I think.

The first day of the three day course started interestingly since the teacher agreed with me that there are no best practices. I liked hearing that but throughout the three days there were many occasions when I could see and hear how he tried hard to stay away from the best practice traps I tried to lay. I questioned a lot of process stuff and asked if one step was deemed better and more valuable than others. The material implied that the more "formal" a technique was, according to the syllabus, the more valuable it was and the better it was. I questioned this and pointed out this implication and the fact that this could easily overturn your test effort. I didn't get an answer about whether more "formal" was better or not, or considered better. I could see the teacher, or ISTQB-dude as I referred to him while tweeting about it, biting his lip and try hard not to fall in that "best practice trap".

It was obvious that what ISTQB called more formal meant better, to ISTQB. The problem here is that when ISTQB says more formal it includes heaps of documentation and meetings and in my world that means less time to actually test. It also, in most cases, contradict my belief that in order to discover things we need to explore and we cannot predict what we will learn. We cannot identify risks without first considering the context, or rather contexts. Without identifying the risks, and contexts, we cannot make any form of decision about what to test first or where to put in the biggest test effort. In order to succeed I must start with context in order to determine the proper course of actions.

I did manage to get the teacher to admit that we were learning this stuff for the exam. He did say exactly that. Sure, we do learn this for the exam and that means that since there is very little substantial stuff that can be useful in practice that statement in it self meant that three days doing this was truly a waste of out time. Personally I learn more useful stuff any three days of any year than I did doing this.

Models? Oh yes, there were many models presented to us. No new revolutionary models, I didn't expect that anyway, but some well known ones like state transition models etc. Now personally I don't have any problems with models and I think models can be useful. In the right context. With the right information to the people the models are presented to. The primary piece of information, for me, is the reminder that a model is just a model. It's not the whole picture and it never can be. It's just a model. When using a model it's imperative that all that are presented with the model are aware that it is just that. A model. It can be useful to spark new test ideas. Any state transition model would likely give you many new test ideas. The same goes for equivalence partitioning. It can show you a small part of what needs to be tested in an area of the system but don't fool yourself that it will provide you with all data you need to test that area. It's just a model. It can give you ideas about what to test and how to test. In many cases, in my experience, creating a model may take more time to do than simply consulting my own experience and thinking. Many times that will produce the same test ideas that a model will and it will do it faster. Sometimes starting on a model may be all that is needed to get the test ideas. If that helps, do it! To me there is no value in completing a model unless I intend to use it for communication or I believe it will help me get more test ideas. Simply completing it for its own sake has no value to me.

The main thing I will remember about this experience is when the teacher, the ISTQB-dude, admitted that we learn this for the exam and thereby implying that it's not learning to be better testers that is the point. I knew that going in but it's nice to hear a "believer" admit that it is so.

SWET2 - A great way to spend a weekend

Back home again, tired and inspired, after a weekend of test talk outside Göteborg. The second installment of SWET, SWET2, with 15 testers. This was my first peer conference and I hope there'll be more to come. The format was great and we had some very inspired, and inspiring, discussions. I come back with a bunch of new thoughts and ideas that I will try to mold into something I can use, when the opportunity arises.

Thanks to Rikard, Martin and Henrik for arranging a great gathering.

The delegates were: Christin Wiedemann, Torbjörn Ryber, Azin Bergman, Fredrik Scheja, Henrik Andersson, Johan Jonasson, Ola Hyltén, Sigge Birgisson, Simon Morley, Rikard Edgren, Henrik Emilsson, Martin Jansson, Steve Öberg, Robert Bergqvist, Saam Koororian. All contributed to a great weekend!

The tweets from SWET2 might tell you something about the discussions that went on