This summer I was looking for a job and I, of course, met the ISTQB mnemonic a lot on my interviews. I said I’m not certified, because my former company didn’t offer it and I wouldn’t spend my own money (no one asked me though if I ever did anything else testing related outside of work) on it. Because other testers made me realize that the ISTQB knowledge is not actually being applied to testing and it’s only scary trying to find a job without it as long as you don’t know any better.
But I didn’t have a comeback on two arguments:
– ISTQB knowledge gives the co-workers a common vocabulary.
– test cases makes it easier for new colleagues to know what should be done.
People who are saying these must have never watched themselves carefully. There is no common vocabulary. The illusion might be there. I have worked with the very same people that told me these things and they themselves told the story on how it failed: Once upon a time a testing team which was responsible for a layer of testing (system) had a greatly different and broader understanding of “smoke test” than the someone who wrote down that the integration team can only start the work after the system team finished their smoke test. So this someone went complaining of course, what’s taking so long, then the integration team called a meeting, then…, braaah, kill me now.
With the help of my friend in testing (@zzmolnar) I can tell you now that you should form a local common vocabulary within your company or project, teach your workmates to ask questions and not wait for a world-wide organization to give you that. How many of you only passed the ISTQB exam so that you can just have the certificate? What terms do you remember? What do you mean by them now? Does the term “black-box testing” means the same to you, your lead and someone sitting in Brazil, working with a completely different domain? Meh…
Test cases! Go back and read your own test cases from 6 months before. Seriously, do it. (khm.. are they up-to-date?) I know you said that you wrote them in a manner that “anyone from the street should be able to execute this test by following my steps“. But that just never happens. Even yourself will have difficulties with it. But even more importantly: remember the last time you went to a new place in the city and was led by someone? And what happened to you when you went again and tried to the find the place by yourself? Remember? Most of us gets lost. Mindless execution and repetition does not generate understanding. I’m sure someone famous said this.
I found several testing jobs with 3 years of experience as a tester, with sociology studies, with no ISTQB certification. I’m a freer man than before the summer and it wasn’t always like this:
Read more:
http://www.developsense.com/blog/2011/06/common-languages-aint-so-common/
http://www.satisfice.com/blog/archives/1346
http://zzmolnar.blogspot.hu/ (Hungarian!)
A nice memory of my first contact with ISTQB: https://twitter.com/erikhun/status/641334383073447940/photo/1
promptest 
This is a fascinating topic. I’ve read the Mitchell & Black book (Advanced Software Testing), which is supposed to be a volume in a series designed to prepare you for sitting the ISTQB Advanced Technical certification (I have not taken the test myself).
I found the book on the shelf at Foyles, and decided to give it a try. The book was chock full of some great ideas, clever ways of thinking about testing problems, and useful tips and tricks for testers. It also covers a number of essential code quality concepts (e.g. cyclomatic complexity), and explains why they’re important to understand. Overall, I found the book extremely informative and well researched (although Rex Black’s writing is a bit too academic and dry for my taste).
Still, what I don’t understand, is why this book needs to be part of any kind of “certification” program. I thought the certification fad died off 10 years ago, with the MCSE and the A+. But it seems to be alive and well in testing. Why?
Nobody demands a rubber-stamp certification from programmers, in interviews. Everyone seems to understand that such a “certificate” would be no guarantee at all, of the quality of code they’d get from the programmer. Instead, they put the programmer to work, asking him to demonstrate his skill with coding challenges or trial days.
Why aren’t employers taking the same approach with testers? Put the tester to work on a testing challenge. Give him a trial day. Find out what he’s really capable of. See how he thinks.
It seems profoundly lazy and irresponsible to me, to rely primarily on a cert to judge whether or not you should hire a technician (be it a tester, a network analyst, or a programmer). Most people get this automatically, when I’m talking about technicians other than testers. So, why does this impulse still linger for testers?
LikeLike
Hey, thanks for the book recommendation! I was wondering about fresher ISTQB material. If someone wants to say anything about that, they should be familiar with it.
It can be that testing is not that acknowledged and even test leads don’t observe themselves carefully enough to point out the skills that makes someone a good tester. Setting up a testing problem would require that.
LikeLiked by 1 person