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.

In the trenches and slowly moving ahead

I heard a rumour while I was attending Öredev in Malmö in november about a teamleader at my company. It was an inspirational rumour. The main thing was that he wanted to scipt more testing of the product he is working with!
Is this inspirational, you may ask, and I have to say YES. It should be inspirational to anyone who believes in the possibillities of an exploratory testing approach. There's a good debate in the making when someone wants to go in that direction.

We planned a meeting to talk about the impressions from the conference with a focus on testing. I went into the meeting with a guerilla attitude but no such tactics were needed. It was a good meeting. We quickly discovered that the they do exploratory testing, but in a very freestyling way and only rarely. The test lead on that team does it when completely new services and new major features are getting ready for testing and have reached a level where it can be done.

I should tell you that the product we're dealing with here does not come equipped with a UI. That part is provided to our customers by other companies. This makes testing a bit more challenging, and interesting. All ideas about testing under these circumstances are welcome. I want to learn more and I try to listen and learn from all sorts of sources.

Anyway, we didn't really arrive at any decisions about ET but we decided to keep talking about integrating it in the processes. The development team is working hard on implementing development processes that are intended to help raise the quality of their output and instead of trying to change to much at the same time testing, and test approaches, where put on hold. Have you seen this before? It's not all that bad, there is alot of positive vibes and an open mindedness for change that will lead to improvement in the delivery and development so I have hope for the future. I just got to remind them that there are ways to get better at testing to!