
Is ISTQB Worth It? A Hiring Manager's Honest Take
After interviewing and evaluating over a hundred QA engineers, testers, and quality assurance professionals, here's what ISTQB certification actually signals — and what it doesn't.
If you've spent any time in quality assurance or software testing forums or job boards, you've seen this question asked constantly: is ISTQB worth it? It appears from new testers, career changers, and experienced quality assurance engineers alike — and the answers are all over the place. Certification providers say yes. Cynics say it's a waste of money. Neither answer is particularly useful if you're actually trying to decide.
I've been interviewing and evaluating QA engineers, software testers, and quality assurance professionals for a long time — over a hundred candidates across teams in financial services and tech. I've seen what separates candidates who get offers from candidates who don't. ISTQB comes up often enough in that process that I have a clear opinion on it — and it's more nuanced than either camp tends to admit.
What ISTQB Actually Is
ISTQB — the International Software Testing Qualifications Board — offers a tiered certification framework for software testing professionals. The Foundation Level (CTFL) is the entry point and by far the most common. It covers testing fundamentals: the software development lifecycle, testing principles, test design techniques, test management, and testing tools.
Passing the Foundation exam demonstrates that you've studied a standardized body of testing knowledge and can answer questions about it. That's a fair description of what it tests. Whether that maps to what hiring managers are actually evaluating is a different question.
What the ISTQB Cert Signals to a Hiring Manager
At best, seeing ISTQB on a resume tells me a candidate has some baseline familiarity with testing vocabulary and concepts. Terms like equivalence partitioning, boundary value analysis, and test oracles won't be foreign to them. For a candidate who is genuinely new to the field — someone making a career change or just starting out — that shared vocabulary can smooth early onboarding.
That's a real but limited benefit. It tells me you studied. It doesn't tell me you can test software.
In practice, when I probe further in an interview — asking a candidate to walk me through how they'd actually apply a technique they've just cited during a hands-on example — it's not uncommon for that confidence to fall apart. Knowing the name of a technique and being able to apply it under realistic conditions are different skills, and the exam tests the former.
What I'm actually looking for when I review a resume is evidence that the person has done the work — in the real world, with real constraints. ISTQB doesn't and can't provide that evidence, because it's a knowledge exam, not a demonstration of skill.
What I Actually Evaluate When Hiring
The candidates who stand out in my interview process share a few qualities that no certification teaches:
They can talk about real problems they've faced. Not textbook scenarios — actual situations where something was ambiguous, where requirements were incomplete, where they had to make a judgment call. Anyone with genuine experience has these stories. Candidates who only have theoretical knowledge struggle here.
They show ambition beyond the minimum. The best testers I've hired weren't satisfied with executing a test plan they were handed. They were asking what hadn't been thought of yet, proposing improvements, taking on work that wasn't strictly required, but made their job easier long-term. Are they investing in paying down technical testing debt or just making minimum payments? That quality of initiative shows up in interviews and in portfolios — not in certifications.
They demonstrate novel thinking. Give me a candidate who has explored a tool on their own, written about a testing approach they developed, or contributed to a project where testing wasn't the obvious path — and I'm far more interested than I am in a cert that thousands of people pass each year.
They understand what they're testing and why. Smelling out where a bug is or knowing which areas of a system are highest priority and why — is something experienced testers develop over time. It's not something ISTQB teaches meaningfully, and it's something I probe for directly.
Experiential Questions
An interview shouldn't be a pop quiz.
Instead of asking the candidate, "What is black box testing?", I'll ask the candidate to apply black box techniques to find defects in a fake application. Instead of asking if the candidate knows what a page object is, I'd ask them if they've used it before and to provide an example of where it was beneficial versus alternatives. I'll see if the candidate can find problems in a specification and if they understand the hypothetical application. Questions such as these demonstrate experience and ability to think critically beyond just memorizing definitions and pass a certification exam.
The ISTQB Certification Signal Problem
A certification tells an interviewer that you cleared a standardized bar. That's not nothing — but in software testing, the bar ISTQB sets is primarily one of memorization and recall, not applied skill. The questions are answerable by someone who has never run a test in a production environment.
This creates a gap between what the cert signals and what the job requires. I've interviewed candidates with ISTQB who couldn't talk through a realistic testing scenario clearly. I've hired candidates without it who were exceptional testers from their first week. The correlation between holding the cert and being good at the job is weak enough that I don't weight it heavily in either direction. I never bring it up during the interview — it's as irrelevant to me as someone's college GPA from ten years ago.
What I do weigh heavily:
- Curiosity
- Recall ability
- Communication skill
- Excitement about breaking things
- Ambition
- Ability to apply knowledge and select the right tool for the job
The differentiators that get you noticed. A GitHub repository with real test suites, a blog post where you worked through a problem, or a test automation portfolio that shows someone has done this — not just studied it. None of these are required, but when two candidates are close, they're often what tips the decision.
When ISTQB Might Actually Matter
I want to be fair here, because context matters.
For someone completely new to testing, the Foundation Level syllabus is a reasonable structured introduction to the field. If you're self-studying and don't know where to start, it organizes a lot of foundational knowledge in one place. The value there is more about the learning than the credential itself — you can get the same knowledge without sitting the exam.
In certain regulated or government environments, ISTQB carries more weight than it does in product companies or startups. Some contracts and some hiring frameworks in regulated industries treat it as a baseline requirement. If you're targeting those specifically, that context changes the calculation. In my experience in financial services, it was never a stated requirement and rarely came up — but that may not be universal across all regulated sectors.
What to Do Instead of ISTQB
If you're early in your testing career and weighing whether to spend hundreds of dollars and several weeks of study time on ISTQB, here's what I'd suggest instead:
Build something you can show. Set up Playwright against a real application and write a meaningful test suite. Push it to GitHub. That demonstrates more than any cert — but be prepared to talk through it in depth. I ask detailed questions about everything on a resume, and work that wasn't genuinely done by the candidate becomes apparent quickly. The framework matters less than the effort — whether that's Playwright, Selenium, or something else — but if you can find out ahead of time what tooling the company uses, it's worth tailoring your examples. When two strong candidates are otherwise equal, the one who can demonstrate familiarity with our exact stack has the edge.
Practice on real targets. Sites like The Best Websites for Practicing Test Automation list websites and APIs designed specifically for testers to practice against without needing access to a private codebase.
Learn a tool deeply. Whether it's Playwright, Selenium, Postman, JMeter, or something else relevant to the roles you're targeting — hands-on expertise is important. I do ask candidates to demonstrate the ability to use tools listed on their resume during most interviews. That said, I've come across candidates who know a specific tool well but never grounded themselves in testing fundamentals. I need well-rounded candidates. Tools change frequently; core fundamentals are timeless — you just add more as you gain experience. This is actually one area where the ISTQB Foundation can genuinely help, particularly for those who are self-studying early in their career.
Be able to talk about what you've learned. In interviews, I pay close attention to how candidates articulate their experience. Can they walk me through a problem they encountered, how they approached it, and what they took away from it? That kind of reflective thinking signals more than any credential. If you've also written about it — a blog post, a GitHub README, a LinkedIn article — that's a bonus, but the ability to speak to your work clearly and confidently is what matters most.
This also scales with where someone is in their career. When I'm interviewing for an entry-level role, hearing a candidate light up about something they just learned — even if it's basic — scores heavily with me. I'm not expecting someone just starting out to have seen everything. What I am looking for is curiosity and self-awareness, and those qualities come through in how someone talks about what they're learning, not just what they already know.
Contribute where testing is needed. Open source projects often need QA help. Volunteering your skills in a context where the work is visible is a credible signal of both ability and initiative. It's also a free way to gain real project experience, collaborate with engineers and testers outside your immediate circle, and develop a perspective that goes beyond what any single role or company can offer. I take my own advice here — on the open source page of this site you can see some of the packages I've created and maintained and below some examples I've contributed to the NightwatchJS automation framework.

The Bottom Line: Does ISTQB Help You Get the Job?
ISTQB won't hurt you, and in a small number of contexts it may help you clear an initial filter. But it's a weak signal at best in most hiring decisions, and spending significant time and money on it when you could be building demonstrable skills is a tradeoff that rarely pays off.
What moves the needle in my eyes and those of like-minded technical hiring managers is evidence that you've done the work — and that you can think critically about it. Real problems solved, real tools used, real judgment applied. That's what the job requires, and that's what a good hiring process is designed to find.
A certification that proves you studied is not a substitute for a portfolio that proves you can do the job.
Does ISTQB help you get the job? In my opinion, no — but the ISTQB Foundation Level might just provide you the foundation for further learning that will.
So, the next time you see someone asking whether ISTQB is worth it in a forum or job board thread, feel free to point them here — and thanks for reading.