The Swiss Testing Board is the Swiss member board of the ISTQB. It grew out of a working group in the IT section of the SAQ, the Swiss Association for Quality, in the early 2000s. The board accredits training providers, promotes tester certification and, from the very beginning, pushed for learning objectives in the international ISTQB syllabi that can actually be measured, based on Bloom’s taxonomy.
Key Takeaways
- The ISTQB started in the early 2000s as informal conversations between a handful of people, long before it had any formal organizational structure.
- Learning objectives in the Certified Tester Foundation Level syllabus only became measurable and testable through Bloom’s taxonomy and Anderson’s revision of it, and without that rigor there is no reliable certification.
- Testers cannot test software meaningfully if they do not understand what it is used for and how it is built.
- Agile takes a lot of discipline: if you never write down and understand your acceptance criteria, you do not know what you actually have to test.
- Systematic test design based on the classic techniques is still indispensable, because purely intuitive testing finds defects but never gives you completeness.
How the Swiss Testing Board Began: A Question after a Talk
The Swiss Testing Board came out of a concrete request, not a strategic master plan. In the early 2000s, Thomas Müller gave a talk at Credit Suisse on use cases in testing. Afterward, Silvio Moser came up to him with a simple question: how could testers be certified?
Thomas had no answer. But he knew someone who might. He had been working for almost ten years with Karol Frühauf in the IT section of the SAQ, and through Frühauf he got in touch with the British ISEB and the American ASQ, both of which were already writing syllabi for testing.
What settled it was a meeting on a rainy winter evening in a restaurant in Zurich’s red light district. Robert Treffny told Thomas about plans to merge the ISEB and ASQ syllabi and found an international organization. Thomas said yes without really knowing what he was signing up for.
Why the Swiss Testing Board Started as a Loose Working Group
At first, the Swiss Testing Board was not an association at all. It was a working group inside the SAQ’s IT section, and that pragmatic arrangement spared the founders from building an organization of their own.
The international umbrella organization, the ISTQB, was founded in Scotland. Thomas could not be there for family reasons; his children were still small. Robert Treffny represented Switzerland instead. Most of the meetings that followed took place in the Rhine region, in Cologne or Düsseldorf, with six or seven people around the table.
At one of these early meetings, someone asked who would coordinate the work on the syllabus. Thomas volunteered, by his own account as a “nobody” in that group, but with the right background. He had worked on learning objectives and had already built courses, among them some with Hans Schäfer under EU funding programs in Germany.
Measurable Learning Objectives and the K-Levels in the ISTQB Syllabus
Thomas’s first contribution to the content was about measurability. The original learning objectives were not testable, and for a tester that was a contradiction in terms.
His argument to the group was simple. If you know how to write testable requirements for software, you can apply the same principle to learning objectives. The method came from Bloom’s taxonomy and Anderson’s revision of it, which Thomas followed. These cognitive levels, the K-levels, became the basis for every learning objective in the Certified Tester scheme: each objective states which level of knowledge an exam can check.
The idea went back further. In the early 1990s, while working at Schweizerische Kreditanstalt, Thomas studied didactics at ETH Zurich. Professor Frey made “How do you measure it?” a central question, and Thomas carried that into the syllabus work.
Convincing the group that objectives had to be measurable was the easy part. Agreeing on the right level of detail in the texts led to fierce arguments. Native speakers such as Dorothy Graham from the UK board and Erik van Veenendaal from the Netherlands were part of the writing. Finland and Sweden brought in people from their universities from day one.
How ISTQB Certification Took Off in Switzerland
Relative to its population, Switzerland was at times among the leading countries for certified testers. Most of the demand came from banking, with Credit Suisse as a co-initiator and Silvio Moser on the board.
Three training providers were accredited first. They had a strong interest of their own, because the courses sold well. Marketing was left to the training providers, not the Swiss Testing Board, and Adrian Zwingli is named as a particularly active driver. A certificate cost around 400 Swiss francs back then, a price the market accepted without complaint.
The 2007 General Assembly in Zurich-Oerlikon gave things a boost. Many countries sent delegates, and India attended for the first time. Switzerland as a venue was an extra draw. Later the momentum faded, as saturation set in along with critical questions about what certification really delivers.
One industry stayed closed to Thomas no matter how hard he tried: pharma, his main field at the time. There, all that counted was whether something met FDA and GxP requirements. Plenty of the content found its way in, but nobody there cared about a testing certificate.
The Pioneers’ Ideas Still Hold
The fundamental test concepts have kept their value, even though the environment has changed a lot. In Thomas’s view, what pioneers such as Glenford Myers and Bill Hetzel wrote down is still relevant to the questions of what to test, how to test it and what to keep in mind.
One concrete example is the combinatorial approach to system integration. At a high level, you check which systems talk to each other, how they do it and which data elements are involved.
Sampling is a topic of its own in pharma. Many people carry the thinking of hardware manufacturing over to software and ask about acceptable deviations as if the product were nails. Thomas answers with one clear sentence.
“Software is not a nail. Sampling logic from manufacturing cannot be applied one-to-one to software.”
(Thomas Müller)
The Biggest Challenge in Software Testing Today Is Speed
The biggest change in software testing is the pace. Testing has to be built into the development cycle from the very start, not bolted on as a later step.
That starts with requirements. Whether you work with acceptance criteria, user requirements or user stories, ask early whether a requirement can be tested at all. The old principle that requirements must be testable still stands.
Test automation raises a question of its own, especially in regulated environments: is what the automated tests report actually qualified and validated? How do you make sure the results are correct?
With artificial intelligence and machine learning, the ground shifts again. A purely deterministic approach no longer works here, and different test criteria apply than for conventional software.
You Can’t Test What You Don’t Understand
Thomas’s most important advice to testers: understand what is in front of you, what it is used for and how it is built. If you do not know that, you cannot test software or an embedded system properly.
He illustrates this with an example from shipbuilding. A company was asked to test the software for the propulsion engines of container ships, machines the size of a kitchen, in ships costing around 150 million. The biggest hurdle was simply understanding what it was all about. Only with that understanding could they test and simulate, especially since such an engine has to be adapted to new environmental regulations over 20 years.
Testers working at the low level also need technical skills: sound processes, building deployment models, working with tools such as GitLab. They should know their way around neighboring IT disciplines, too.
This is where experienced testers have the edge. They already know a lot from experience, and a look at the real product is often an eye-opener, for developers and testers alike.
Systematic Testing Beats Gut Feeling
Modeling is underused in testing, even though it is highly valuable. If you cannot model, you test by feel or by whatever comes to mind.
“Feelings do matter, I have nothing against them. But systematic work is something else entirely.”
(Thomas Müller)
Intuitive testing can certainly produce good tests, and sometimes it turns up something valuable. But a piece is missing when nobody approaches a requirement systematically. The basic techniques for that were defined by Myers and other early figures in the field.
Agile does not let anyone off the hook either. Agile does not mean “just go for it”; it takes a lot of discipline. If you have written down and understood your acceptance criteria, you also know what you have to check. Early, early, early is how Thomas sums up the principle.
