Facing the behemoth: ISTQB Advanced

Standard

Last week I started the course for the ISTQB Advanced Test Analyst certification. I had been planning to do this course for some two years. The price is steep, some 2,500 euros and it is a time-consuming business. I know some of you reading this must think I lost control of my senses, taking an ISTQB course instead of Black Box Software Testing course, the Bug Advocacy course or Rapid Software Testing. It suffices to say that it was a somewhat rational decision.

I intended to do live blogging from the course but did not pursue that option. But I do wish to spend some posts on the subject.

My first impression is that ISTQB is a behemoth. I do not say this because I am unable to oversee the material. I am very well capable of that. Still, if you look at the mountain (card house, for the critics among you!) of constructs and definitions the course seems to stagger under its own weight. For example, the famous glossary alone has some forty pages of definitions. And that’s just words about words. The two binders holding the printed slides of the course are massive, of the aforementioned biblical proportions.

It is words about words. ISTQB is a framework for defining testing. It is construct placed upon construct. It is a sum of abstractions that seems to live in a world entirely of its own. It hardly ever touches the human world we live in. It is not easy at all to get to know ISTQB because the only frame of reference for ISTQB is ISTQB itself. Like mathematics it is an artificial universe in which constructs interact. Not easy at all to learn.

Unfortunately the day before I started the course I opened a book by Alistair Cockburn entitled Agile Software Development. Cockburn is all about human side of creating software and his theory for building and sharing knowledge. This book, in some way, surprised me too. Considering the book is about agile software development, I expected a tale about processes (Scrum and iterative things in all kinds of forms, unit tests, customer involvement, burn down charts and other hollowed out concepts). But Cockburn, in his introductory pages, refuses to notice even that such concepts exists. Which is a very, very refreshing take on software development. And perhaps it is also the only viable take on software development.

But now, back to the glittering wonders of the processes of software testing. I left the first day of the ISTQB course with one prevailing feeling. ISTQB is a set of constructs that excludes other ways of looking at testing. If I compare it to my History of Software Testing (which is also a huge amount of constructs), my history is not a system. For me it is a path of discovery; use whatever you like, leave out whatever you like.  The ISTQB framework is a system, it is a limited, restrictive set of constructs, it is a framework inside which the software tester thinks. It reduces options, it takes away the possibilities of looking at testing in any other way. The course forces upon the tester the only one way of looking at software testing.