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
, 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 😉