Dear ISTQB. Please update your syllabi. It is 2023 already.

6 min readMay 17, 2023

On May 9, ISTQB announced the release of a new version of the foundation syllabus (v. 4.0). Version 3.0 was released in 2018, so after 5 years, we could expect significant changes. After all, 5 years is actually a whole epoch in IT. Unfortunately, not in ISTQB. Time seems to flow differently there. This new syllabus is a good opportunity to look at how far the ISTQB approach is from the present IT. I would like to focus here not only on this newest CTFL syllabus but on the holistic vision behind all ISTQB syllabi.

The CTFL syllabus approaches agile methodologies reluctantly. It notices them but treats them as something worse, what can be hardly tolerated. It mentions agile in 7 paragraphs of the main contents (not counting Introduction, Bibliography, etc.). We will not learn much about testing in agile from the CTFL syllabus. We are referred to a separate syllabus for these matters. What do we learn from this work? Not much. Unfortunately, the best way to learn testing in Agile is learning separately testing and learning some Agile framework like Scrum or Kanban.

GENERAL AND DEEP PROBLEMS IN THE PHILOSOPHY OF TESTING

The main problem with the ISTQB approach is the vision of QA in SDLC. ISTQB tends to see the tester as a separate role in the process. Scrum and other modern frameworks see the team, and testing is just one of the activities to produce the increment. This is a very important difference.

If there is a role, then there is also some responsibility. ISTQB wants to see testing as the exclusive responsibility of testers. Modern approaches emphasize that quality is the responsibility of the whole team.

If all team members feel responsible for the whole product, then the understanding of the needs of testing is better. People just cooperate on a daily basis. In ISTQB, cooperation is something special that needs to be allowed in syllabi. Let us see, for example, CTAL-TM.

p. 19 “The Test Manager needs to consider requirements during the scoping and estimation of test effort, as well as remaining aware of changes to the requirements and exercising test control actions to adjust to those changes. Technical Test Analysts and Test Analysts should participate in requirements reviews.”

This sentence shows not only that the responsibility for testing is taken from the whole team and concentrated on testers, but also that ISTQB promotes a more granular responsibility split. Cooperation among Test Managers, Test Analysts, and Technical Test Analysts is something so exceptional that it is worth a separate sentence in the syllabus. In Agile, cooperation is as natural as breathing.

To be honest, I am very curious about the percentage of software development teams that have separate roles such as Test Manager, Test Analyst, and Technical Test Analyst (all three). Throughout my career, I have not seen any.

ARCHAISMS REPEATED FROM VERSION TO VERSION

Let us go back to the new CTFL syllabus. We can read the following point among risks of using test automation (precisely the first one):

p. 59 “Unrealistic expectations about the benefits of a tool (including functionality and ease of use).”

How long should we assume that managers in IT do not understand test automation and have unrealistic expectations? Ten more years? Half a century? A century? This point might have been true when test automation started to gain popularity and the experience in this area of most people in the industry was poor or nonexistent. I think that was more than 10 years ago. Nowadays, test automation is rather a well-grounded standard, not an exception. Other points mentioned in the risks also seem to come from the early days of test automation’s popularity.

SIMPLE BUT SIGNIFICANT MISTAKES

In the “Foundation Level Extension Syllabus Agile Tester” (2014, still the newest one), one can read:

p. 13: “In Agile development, user stories are written to capture requirements from the perspectives of developers, testers, and business representatives.”

It wrongly suggests that in Agile development, we have to use user stories. It is simply not true. User stories are a helpful way of describing Product Backlog Items, but they are neither mandatory nor the only type of backlog items. User stories are not mentioned in the Scrum Guide at all. They are fully optional.

p. 12: “The development team reports and updates sprint status on a daily basis at a meeting called the daily scrum.”

It wrongly suggests that the primary goal of the daily scrum is reporting the status. It is not. The primary goal is to plan the next day of work. Communicating what was done is needed to plan what to do next. Reporting is not the goal itself.

p. 13: “Iterations or sprints are optional in Kanban.”

It should be “Iterations are optional in Kanban.” because a sprint is the name of an iteration in Scrum. Iteration is a proper word for every iterative process.

p. 21 “While Scrum, in theory, does not allow changes to the user stories after iteration planning, in practice such changes sometimes occur.”

This is simply not true. Let me quote the Scrum Guide: “During the Sprint […] Scope may be clarified and renegotiated with the Product Owner as more is learned” and “If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.” It is clear enough, I think.

ISTQB VS KANBAN

One of the most visible differences when it comes to Agile can be seen in the case of Kanban. Kanban is an Agile method that focuses on visualizing the workflow, limiting the work in progress, and optimizing the flow of value.

Kanban does not prescribe any roles or ceremonies but relies on self-organizing teams that collaborate and communicate effectively. Whereas the ISTQB syllabus defines roles and responsibilities for testers, test managers, test analysts, test designers, etc., and describes various testing activities and tasks.
Kanban does not use iterations or timeboxes but delivers work items continuously and incrementally, based on customer demand and feedback. Whereas the ISTQB syllabus assumes that testing is done in iterations or sprints and covers various aspects of planning, estimating, monitoring, and reporting testing activities within an Agile project.
Kanban uses a pull system, where work items are pulled from a backlog when there is capacity available and prioritized based on value and risk. Whereas the ISTQB syllabus uses a push system, where work items are pushed from a product backlog to a sprint backlog based on the sprint goal and the product owner’s preferences.

To illustrate how reluctant ISTQB is to Kanban, let me mention that the only reference to Kanban in the CTAL TM syllabus is “Kanban board.” For ISTQB Test Managers, Kanban does not exist.

OTHER PEOPLE CRITICIZING ISTQB

Nine years ago (I repeat, nine years ago), many of the above problems were raised and broadly commented on by some Polish testers on their blog pages. What has happened? Actually, nothing. Nobody has done anything. Neither ISTQB nor the Polish society SJSI has done anything to fix it.

Is my criticism exaggerated? In my opinion, the level of my criticism is rather moderate. If you are interested in the voices of truly upset people, then I would like to share the following perspectives with you.

James Bach is a well-known software testing expert and a critic of ISTQB. He has expressed his views on ISTQB in various blog posts, articles, and interviews.

Pradeep Soundararajan is another software testing expert and a critic of ISTQB. He has criticized ISTQB in his blog posts, articles, and interviews.

You can find more information in the following resources:

WE HAVE TO PLAY THIS GAME

ISTQB has a completely different vision of how QA functions in the SDLC compared to most of the IT industry. While small mistakes can be relatively easy to fix, changing the philosophy or even the focus requires rewriting everything. I have no illusions that I will see it happen.

However, ISTQB is widely recognized in the job market. There is no other organization offering certifications in the testing area with such a strong position. This forces young testers to play this game. I also engage in this game when I share ISTQB exam preparation materials with people. Others in the tester community also do the same. Why? Because for many people, it is the only way to improve their qualifications and start a new job in IT.