I recently passed the ISTQB Certified Tester Foundation Level (CTFL) exam and earned my ASTQB certification. I took the exam on November 14th and scored 87.5% (needed 65% to pass). It took about a week of studying, and overall, I had fun with it.
I just received a congratulatory letter from Margaret Murry, Certification Director at ASTQB, so it’s official enough now to make a blog post about it. Shoutout to my employer, Aspida, for paying for the exam.
What I Learned
The ISTQB Foundation Level covers the fundamentals of software testing, including:
- Testing principles and processes: The seven testing principles, test levels, test types, and maintenance testing
- Testing throughout the SDLC: How testing fits into different development models
- Static testing: Reviews, walkthroughs, and some static analysis strategies
- Test management: Test planning, estimation, monitoring, and defect management
The certification provides a solid vocabulary and framework for discussing testing concepts. It’s helpful to have a common language when talking about testing with other professionals, especially across different organizations.
The Good: Vocabulary and Fundamentals
ISTQB does a good job establishing baseline knowledge. The certification covers important concepts like:
- Equivalence partitioning and boundary value analysis
- Statement, decision, and path coverage
- Risk-based testing approaches
- Defect lifecycle management
Having this shared vocabulary makes it easier to communicate with other testers and stakeholders. When someone mentions “boundary value analysis” or “equivalence partitioning,” everyone certified knows exactly what that means.
The Critical: Rigidity vs. Reality
Here’s where I have issues with ISTQB: the framework is incredibly rigid and prescriptive, which contradicts one of their own fundamental principles.
One of the seven principles of testing is “Testing is context dependent.” Yet throughout the syllabus, ISTQB continuously presents strict rules about roles, responsibilities, and test cycle expectations that completely bypass this.
Most companies don’t have the resources to do testing in the hyper-specialized way ISTQB describes. In the real world:
- QA engineers often wear multiple hats (manual testing, automation, test planning, DevOps)
- Test phases overlap and iterate rather than following strict sequential processes
- Teams adapt their testing approach based on project constraints, not textbook definitions
- The “ideal” test process described in ISTQB is often impractical for smaller teams or fast-moving projects
The certification presents testing as if every organization has dedicated test managers, test analysts, and technical test analysts with clearly separated responsibilities. In reality, many teams have one or two QA engineers handling everything.
Still Worth It
Despite my criticisms, I think ISTQB CTFL is a good starting point for anyone in QA. It provides:
- A structured overview of testing concepts
- Common terminology for the industry
- A baseline understanding of test techniques and processes
- Recognition that’s valued by many employers
Just take the rigid processes with a grain of salt. Use the principles and techniques as tools in your toolbox, not as strict rules to follow.
What’s Next
I’m planning to attempt the ISTQB Advanced Test Automation Engineer (TAE) certification next. I’m curious to see if the advanced level provides more practical, context-aware guidance or if it continues the same prescriptive approach.
The TAE certification focuses on:
- Test automation architecture and design
- Technical test analysis and design
- Test automation deployment and maintenance
- Metrics and reporting for test automation
This aligns more closely with my day-to-day work, so I’m hoping it will be more immediately applicable than the Foundation Level.
Final Thoughts
The ISTQB CTFL certification is a solid foundation, but remember that real-world testing is messy, context-dependent, and requires adapting these principles to your specific situation. Don’t let the rigid framework make you think there’s only one “right” way to test.
Testing is about finding bugs, providing information to stakeholders, and helping deliver quality software. How you get there depends on your context, your team, and your constraints.
Thanks again to Aspida for supporting my professional development and covering the certification cost. If you’re considering the ISTQB CTFL, I’d say go for it, but keep your expectations realistic about how directly it will apply to your daily work.