You heard about him, read about him, read his work… and you think you know what to expect. But nothing really prepares you for it. He’s intimidating and overconfident and at the same time passionate and charming. He’s everything you would like to be one day and he makes you believe you actually have a chance at it. All you have to do is think for yourself and question everything.
James Bach came to Romania for the first time for a Context-Driven School, about exploratory testing and James Bach’s role in defining it, or about how opposed he is to ISTQB and everything related to it. But I am very sure that most (if not all) of the participants that didn’t know these things looked them up afterwards – which is more than we can hope for.
I did know about his work, his beliefs and his methods. Still, the workshop was fascinating. Two days later, I still find myself thinking about it and analyzing everything that I’ve learned.
At the end of the workshop that day, while discussing it with my colleagues, Oana and Alex, I went on and on about how he didn’t have this or that right, or how he contradicted himself on this or that. I argued that while he pointed out that the ISTQB syllabus incorrectly defines exploratory testing as a testing technique, when it is really a testing approach that can be applied to any technique, he himself mistakenly called it a technique later on during the talk. He also presented a “boundary analysis” example which was meant to prove that the ISTQB definition for boundary analysis is incorrect because it says it only involves testing the values around the boundary. In his example, where a program had a 32k bytes boundary value, the program crashed when a value larger than 64k bytes was used – thus proving that it’s not only the values around the boundary that need to be tested, but also any other values that are ‘related” to the boundary in various ways. I was skeptic and argued to my colleagues and even to him, during the workshop, that the 64k bytes value was no longer part of the analysis for the 32k boundary value and that the crash could have been maybe found anyway by stressing the program with any other large(-r than 64k) value.
Later on I realized I would have argued anything. I was just trying to find reasons to prove that he’s not ‘the god’ we all think he is. But this is exactly what he wanted us to do: question him, question everything, think for ourselves. So I did think for myself and realized that his 32k bytes boundary value example was the perfect way to explain how exploratory testing can be successfully applied to any testing technique. It was an approach that he (and everyone else in that room) applied to the boundary analysis technique. I also realized I couldn’t care less about semantics, as long as applying what he taught me helped me find a bug I wouldn’t have found otherwise.
So here I am, two days later, still thinking about it and finding out that my attempts at proving that he was wrong only led me to understand how right he was. I had been brainwashed, by ISTQB and years of working in environments that always told me what the right way was to do things. I need to deprogram myself, and if I might have known this for a long time, somewhere in the back of my mind, I never really thought I could or had to do it. But this is what this workshop taught me, above anything else: if you’re passionate enough, you can do anything. And when you see someone as passionate as James Bach, if you get a chance to hear him talk and think and question, you get all the motivation you need. Trust me.
As a side comment: While we were having lunch that day, James mentioned that he has a script that will alert him every time a new blog post or article related to exploratory testing or any other subject of interest to him is published on the internet. So this is also a test – I’m still trying to prove that sometimes he’s just bragging 😉
–Ru
Great post, I like the writing style.
I think I share your passion for doing things.
Regards from a former Bullguard coder!
James Bach has strong arguments against ISTQB, but in the same time he recommends to indulge our curiosity. It may be possible that the curiosity of some of us to point at some time to ISTQB, due to acquire some knowledge on the Testing Folklore.
With this argument I don’t intend to say ISTQB certificate produces real testers, but as far as I know, few certificates can attest the graduated persons become ‘experts’ after passing the certificate test. For example, the engineering degree doesn’t attest the graduate student is an ‘engineer expert’, as that diploma is just the start to become one.
PS. I don’t have ISTQB, but I have learned a lot from ISTQB books
Welcome to being Bached!
I just have one suggestion to people whose thinking model of contradiction suggests that it is bad – it is not.
Its OK to contradict. For instance, I might have said something when I didn’t have information about a particular thing but then when I learned about it, my idea of it changes, so I may want to correct myself. If I am forced to think that others might think bad of me if I contradict then I would actually be doing more bad to them when I hold back good information.
About ISTQB
ISTQB is built to make money. Hey, its not bad. I don’t mind. I do mind when making money comes at the cost of causing harm to the community.
I haven’t interacted with ISTQB certified testers who got extra passionate about testing after going through it. I live in a land of testers and I hope you may permit me to call India that way. ISTQB is least respected in India by ISTQB certified testers themselves. For some it took half a day of memorizing capability to crack it and for others a maximum of one week.
The syllabus and contents is in such a way that a tester of a stature as James Bach, Michael Bolton or Jerry Weinberg would flunk it. They may score a zero. What does that indicate?