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.

Jam session / Test session

I try to relate all sorts of different experiences and events that take place in everyday life to testing. It helps me remember and it lights up new perspectives on testing. Maybe most importantly I think it's a fun exercise to do. Keeps me thinking of testing, and other things, in new ways and that helps me stay creative and passionate about it. That's my opinion and it works for me.

One thing that comes up every now and then is jam sessions and performance or rehearsal of music. There are several things that relate to testing. The common way to stand/sit in a jam session is in i circle so that everyone can see each other. Body language, eye contact and, depending on if anyone cranked up his/her amplifier to 11, some spoken or shouted word. The most common use of the spoken word in communication during a jam session is usually changing key or moving to a new harmony progression. In these cases it's very short. "F" may be all that is said and when the next bar is reached everyone, hopefully, changes to F. You can change in the middle of a bar of course but changing at the start of the next bar is an example. Rhythm and speed may vary and usually starts with one or two persons picking up on each others playing and creating something new. new progressions may be created this way to. In a good jam there is evolution and learning happening. Is this starting to sound familiar? I think it was Miles Davies who said that he had only gotten better by always playing with musicians that were better than he was. Not extremely better but better. That way he pushed himself, learned more, and became better.

To me jam sessions has always been great opportunities to learn and develop my own skills as a musician. How does this relate to testing? I think a lot is pretty obvious to you by now. Working in a team will help testers to learn more, faster. Do pair testing to help less experienced tester learn from a more experienced tester. Like a good jam exploratory testing will make the tester learn and hone his/her skills during a testing session at the same time that he/she learns more about the software being tested. Change key or move to a new harmonic progression is the charter and it will give ideas for a charter for the next jam, the next session. Changes during a jam is exploring musically in the same way as we explore when we test. We see something that catches our attention or we apply a heuristic that we dig up that we believe is useful here and now. It's like coming up with a riff during a jam that may or may not work in the current context. I guess all musicians carry around an ever growing set of riffs and lick that have been picked up and developed over the years. It's the same thing we do as testers. We develop our tools every time we use them. We can do that if we are aware and think. We don't always have the luxury of being able to pair up with another tester but if you get the chance take it. Go for it! Grab the opportunity. You'll learn something and the other tester will learn from you.

Managing a jam session usually comes down to providing a place to be, maybe set up some amps, drums, keyboards and a PA. Making coffee, provide a sofa and some chairs are good things too. It's pretty much very basic facilitation that we're talking about. It's not about controlling every move of the participants, maybe throw in a first idea of a place to start. More experienced participants will come up with something on there own and agree to start off there. To me this relates very much to testing sessions and the test managers role. If you have the opportunity be a hands on guy and team up with one of your testers and learn something new and help your tester learn as well. Facilitate. Make sure the testers have what they need. Access to oracles identified before starting the session. Coffee! Make sure they get left to do there job and that they are not interrupted. As the test manager be a blocker and let the testers test.

The debriefing at a jam session is either non existent or it's very informal. Usually there will be a few words exchanged when a jam ends, at least if we've found something good and it has rocked in some way. The less successful attempts usually are ignored and you just sit down and let someone else play. That luxury is rarely available in a work situation with deadlines but sometimes it's a good idea to take an early lunch, just take a walk outside and think of something else or, one of my favorites from Brian Eno, "Do nothing for as long as possible." If you try it you'll find how hard it is to do absolutely nothing. It's a fun exercise and not as easy as it sounds.

The inspiration for this came from many discussions and talks at EuroSTAR 2010. Thanks to Lynn McKee, Michael Bolton, Rob Lambert, John Stevenson, Markus Gärtner and many more.

This is the first of my posts that were inspired at EuroSTAR 2010. There were many interesting discussions and a lot of ideas came out of various talks. I will be writing more soon.