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

There's hope for the future

Yesterday I was talking to my oldest daughter, 9 years old, when we were driving home from her school, like I do every day, and she told me they'd had a test/exam during the day. Nothing strange in that since they are in the middle of a period when they have their first "real test/exams". It's a set of national tests that all 3'rd graders take in Sweden. I was curious about how she had experienced that and what the test was about. I've hear her teacher talk about how it works and they do some things in groups and some individual tasks and not everything at once but it can start one afternoon one week and be continued next week or the next day. Some of the tests are connected so that the results, and learnings, from one test is the starting point of another. All in all I was impressed with the development since this is nothing like it was when I was at school.

I asked her what the subject was, what the test was about, and I got the answer: I'm not sure. That sparked my curiosity and I asked her to describe what they'd been doing. To say the least I was pleasantly surprised. She told me that they had to solve a mathematical problem and then describe how they had solved it. They were free to use written language, mathematical language (her words) or images and diagrams to describe the process. I had a big smile on face the rest of the drive home and we talked more about it. She had mixed written language and math and imagery and I said -That's great. find it easier to understand how someone else has thought if I get different types of information about it. We talked about the use of imagery and how the combination of different ways of communication can make it easier to understand another person.

I was impressed that this had been implemented in the tests and exams and it raised my hopes for the future. I do believe that all is not as bad as I had feared in the school system in Sweden today. We are moving forward and I hope that most, if not all, teachers use this approach in the class room. Letting the kids think for themselves and use different means of communication to explain what they've learned.

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.

EuroSTAR 2010 - a great experience

I attended my first EuroSTAR conference this week and it was very inspirational and a great learning experience. I was reminded of a lot of stuff I had more or less forgotten and I picked up many new ideas that I will try out. Amongst the many talks and workshops there are a few that sticks out. Michael Bolton on Test Framing was very good. I picked up some very useful stuff attending that. Lynn McKee on inspiring passion in your team was excellent. She made a lot of good points and I will remember them and use them. There were some very good keynotes and Rob Sabourin, Anthony Marcano, Dino Petti, Bob Galen were all really good. They all put ideas into my head and I came back with some new ideas to write about. There were others that were inspiring as well. Henrik Andersson och Fredrik Rydberg made great presentations that gave me some new ideas to test. Ajay Balamurugadas was amazing when he presented Weekend Testers.

Perhaps the best thing was the Test Lab. A good place to do the fun stuff, test, and a great place to learn, listen, discuss with some very good testers. I came back from the conference with some good ideas for new posts on the blog and I will start writing this weekend. I might as well walk the walk and do my best to keep my own passion going and write while I still remember why I made those notes and thought of those topics.

Hanging out with some great people was inspiring and a lot of fun! Testing is fun and testers are fun! At least the good ones :)

Bug magnet?

Do you ever feel like a bug magnet? Well I do, occasionally. I experienced a bug, well it there were several wrongs involved, last Friday in Gothenburg. Here's the story.

I was in Gothenburg to see ZZ Top with my brother and we as we walked from out hotel to the venue I stopped by an ATM to get some cash to spend at the show. The ATM was located outside a bank, Nordea to be exact, and the ATM was a really old one. It has a small black and white screen and I know this model has been in use in Sweden since the 80's. Now I do guess the software has been upgraded several times since, but that is pure assumption on my part. Anyway, I inserted my VISA card, entered my PIN, as instructed. I then got to choose if I wanted a receipt printed or not, I chose not to. Then I entered 600, that's what I wanted to withdraw. Now is when the funny stuff happened. I get a printed receipt withe the text "Your bank does not allow the withdrawal", the standard message when you haven't enough money on your account. Then I get a message on the screen saying "Take your money". OK? What did just happen here? The machine prints, when I said I didn't want it to do that and it told me I couldn't withdraw that amount. Then it still gives me the cash! Just another Friday night for the tester. I'll send a link to this post to the bank and see if they react. I'll post the reaction if I get one.

I guess most people wouldn't think more of it when they get there cash but the tester in me noted the strange behavior and hopefully I'll make use of it when testing in the future. I did check my bank account when I got home and the withdrawal was logged as it should and there was more funds in the account, which I expected.

Documenting the easy way

I recently read Michael Bolton's blog post on Test ideas for documentation and was inspired. I thought about the points he made and the questions he asked and figured I could use them in my own way in a project I'm currently involved in. I had this in mind when I read a blog post by Pradeep Soundararajan on his experiences from a recent project. That blog post is a great example of good story telling that really points out some important observations and conclusions we could all learn from.

The thing that caught my attention and instantly gave me an idea was the use of video test cases. It's a brilliant idea in all its simplicity. It's fast to do and easy to understand. Having just read Michael Bolton's text on documentation I immediately thought of using video for documentation. Not for documentation of test sessions but for the systems documentation that we are required to supply to our customer according to their holy process. The customer is an organization that relies on process and documentation and very little on people. It's the kind of place where some people still believe that a good process can be implemented that will solve all the problems caused be human error. They like best practices and that kind of stuff. You have probably seen this yourselves more than once.

Being in this environment it gave me great pleasure to introduce the idea of more video as part of systems documentation and of course as part of systems test documentation. I was ready to argue my case but I obviously managed to present the idea well enough right of the bat because the idea was embraced fully right away. I was a bit disappointed that there were no arguments since I always enjoy the argumentation part. More than once have I seen new ideas, and better ideas come to life as the result of good arguing by intelligent people.

The way I will use video is by making fairly short videos, screen capture, for each of the various application in the system and then simply naming them in a way that relates them to the relevant design specification document. By storing these together, and supplying a very brief document describing the naming convention and the relationships between the specifications and the videos. I will be able to produce this documentation at the same time that I am testing the system and virtually to two tasks simultaneously. There will be some work left to finish the job but the amount of time this will take is very small. I will use video capture to assist myself while testing as well as I use my notebook and OneNote to keep track of my testing sessions. I feel very good about the setup and feel very good about not having to write long, useless descriptions that are totally pointless and basically just a copy of the design specifications and that will never be read by anyone!

Many thanks to Michael Bolton and to Pradeep Soundararajan for providing the inspiration to think more about the subject and for the inspiration.