Nearly a million. That is the number of ISTQB exams that have been carried out and has so far led to almost 700,000 certificates.issued. Does the fact that you have obtained a certificate make you a good tester? Not necessarily. And some might even say “definitely not”. But, that’s not what this article is about. All those people who have obtained one or more of those certificates once started with the ISTQB Foundation. In addition, there are also people who have followed training courses based on TMap or courses or workshops based on the ideas of ISTQB and/or TMap. All these trainings, courses and workshops have one thing in common: an important part is about test design techniques. Techniques that were partly already described by the Special Interest Group in Software Testing of the British Computer Society and later found their way into part 4 of IEC2119, the international standard for software testing.
Again, my concern is not whether or not it is important to record something like this in a standard. What matters is that from the moment software quality was thought about, there was also thought about how to design tests in such a way that they actually test something of that quality. And that importance has always been recognised, because it’s not for nothing that techniques have always been added. Whereas the test design techniques were first and foremost based on the structure of the software, these were later supplemented with techniques that look at the specifications and use. So there is a whole range of design techniques. Often categorized as structure-based, specification-based and experience-based. In addition, there are techniques that are not so easy to put in one of those boxes.
So you would think that these techniques are, as it were, in the DNA of every tester, because since the beginning of our field, nothing has been more important than the development of these techniques. And as I said, every education in that field pays ample attention to those techniques. However, where you would expect every tester to have these techniques at the top of his or her toolbox, I often find the opposite. They are in the bottom compartment, that compartment for which you first have to push the other compartments aside to access them. And then there are all kinds of things on top. If we open that toolbox at all, it’s often not to get a test design technique out of it. We take a Python script or a piece of free software to automatically perform a test. We would like to see the limit value analysis at the top of our toolbox, but otherwise we feel shy about the test design techniques and prefer to leave them unused at the bottom of the toolbox.
This shyness is general and does not only apply to those who have just completed a training course and obtained a certificate, but still need to gain the necessary experience. In the 2019 update of ISTQB Certified Tester Advanced Level – Test Analyst a number of test design techniques have been omitted that were still included in the 2012 version. This is based on feedback from the stakeholder review, the people who hopefully have a warm heart for the test design techniques. Techniques they were shy about, but why actually? Because they are difficult to apply or because they were difficult to explain? As a trainer of the advanced levels of ISTQB I often notice this shyness with the test design techniques among the students. An important part of it has already passed by at the Foundation, but people have difficulty reproducing it. In the end, the most important reason is that people simply don’t use them. When you don’t train, you never become a top athlete. It’s the same with the test design techniques. Of course, if you don’t use them, it never becomes a matter of course. And then it becomes embarrassing.
So we’d rather just open the lid of our toolbox and grab the tool that’s on top. That test-automation tool that we also used in the previous project. The question then is which tests you perform using that tool. How are they structured? To what extent are they suitable for testing something of the quality aspect? We often hide behind standard terms such as good- and bad-weather scenarios and corner-cases, but we can’t really explain how we determine them. If we had opened our toolbox a bit more often and looked in the lower compartments as well, we would have come across some wonderful techniques to help us do that. Of course, as a tester, you also need to have knowledge of the system and its users, and you determine useful scenarios based on that knowledge. As a tester, you also need to dare and be able to think out-of-the-box, or perhaps out-of-the-technique, and perform unexpected actions, enter special data, etc., but that particularly concerns the piece of experience-based testing. An extremely important aspect of testing, but not the only one.
Especially with automated testing, which often precedes experience-based testing, you want to get going as efficiently and effectively as possible. Efficiency and effectiveness mean that you do the right things, not too much and not too little. Not too superficial and not too deep but fitting the criterion you want to test and the associated risk. Test design techniques are then the right tools to ensure that you derive test cases that are efficient and effective, appropriate to the risk. Once you have mastered these techniques, you can even go a step further and use them to define your requirements. In my presentation at the QA&Test 2020 I will elaborate on this.
But first, let’s start by pulling that toolbox completely open again and see what hidden treasures can still be found in it. Then get to work with it and learn how to actually use the tools. Then it will become easier, more fun and you will get more and more satisfaction from the result.
I would love to hear your experiences when you visit one of my conferences. See you then!
Are you interested in a test job at ALTEN? Please click here.