Decoding ISTQB CTFL v4.0 Personal Insights – Part III: Why Understanding the Mindset Behind It Matters

Navigating the #ISTQB CTFL v4 (2023) is a valuable exercise. Not only does it help us understand the mindset of those who designed it, providing answers to the "whys," but it also eases our study efforts, especially for first-time exam takers.

The previous #ISTQBFoundation v3 was straightforward. #WhiteBox testing techniques were reserved for the Advanced Level Technical Test Analyst certification #ISTQB-CTAL-TTA. Yes, I hold that certification, so for me the content isn't new but for newcomers to the profession, this isn't quite true.

But why this knowledge move with more detail from Advanced Level TTA to the ISTQB Foundation Level v4?

In my view, as I discussed in my previous article (see link), there's a clear intention to align the tester’s role more closely with #SoftwareEngineering. Testers need to understand more about Test Automation and how those tools are connected to tools ( #Jenkins or #GitHubActions or ...) that support #DevOps workflow.

So, this syllabus reflects a forward-thinking approach to future work methodologies, even if it's not yet mainstream (as I said in the previous article). DevOps entails testing at all levels, including the lowest levels. Therefore, testers must become more technical and less focused on business know-how, even they continue bridging the two extremes of software development.

This reminds me of a trend popularized by #Microsoft about 10 to 20 years ago: when they hiring professionals as #SDETs – Software Development Engineers in Test, essentially tester-developers, which is now foundational in all automated testing teams.

Is knowledge of white-box techniques useful day-to-day?

This is a more complex question. In my experience, the software development processes of large multinational companies leave little room for this level of testing. Agile methodologies, with their emphasis on continuous delivery, offer limited time for testers to analyze source code and create tests that ensure full code coverage.

But it's not just about time constraints. There’s a significant technical challenge. Today, a business process might start with code written in #Python, connect to another part in #ABAP (SAP), and end in a microservice coded in #Golang. How do we achieve white-box test coverage for an end-to-end business flow? It’s an incredibly difficult task or even impossible. We can only perform white-box testing module by module, validating Python code, then Golang code, and so forth.

Even this kind of challenge I believe white-box techniques are useful in closed product development (typically COTS - Commercial-off-the-shelf), like MS Word or a specific game.

So how does it impact the ISTQB exam?

Regarding the techniques included in the Foundation Level, they are relatively simple to understand. However, it’s more challenging for testers with no programming experience to pass the ISTQB exam, even though the objectives are mostly K2 – Understand, rather than K3 – Apply.

In conclusion, understanding the rationale behind the CTFL v4 is crucial. It not only helps us grasp the why behind the changes but also prepares us better for the evolving landscape of software testing, where testing wisdom is becoming to keep updated.

1st article - Decoding ISTQB CTFL v4.0 – Part I - Test Levels Debate

2nd article - Decoding ISTQB CTFL v4.0 – Part II - Software Methodologies Debate

#Testing #Tester #QA #TestingEngineer #QualityAssurance #SoftwareTesting #QAManager #SWTesting #TestingCommunity #GalpQA #ISTQB #ISTQBFoundation #BlackBoxTesting #WhiteBoxTesting #SLDC #SoftwareDevelopment