Introducing Mandatory ISTQB Certification for the QA Team
Context
Bykea's QA team had grown from 2 to 8 engineers with very different backgrounds — some from manual testing, some from development, some self-taught. Inconsistency in testing vocabulary, bug reporting quality, and test coverage decisions was creating friction and unpredictability.
Decision
Make ISTQB Foundation Level certification mandatory for all QA engineers, with a structured study program and company-funded exam
Alternatives Considered
Internal training only
- Customizable to Bykea's specific context
- Cheaper
- Faster to implement
- No external standard to benchmark against
- Knowledge quality depends on trainer expertise
- No credential that grows with the engineer's career
Role-specific certifications (Appium, API testing)
- More directly applicable to daily work
- Technical depth
- Misses foundational testing principles
- Different certifications = continued fragmentation
- Tools change; principles don't
ISTQB Foundation Level (universal baseline)
- Globally recognized standard
- Establishes shared vocabulary across the team
- Covers testing principles, not just tools
- Credentializes the team — better career trajectories
- Builds professional identity and pride
- Time investment (study + exam)
- Abstract concepts take time to apply in practice
- One-time certification doesn't guarantee ongoing learning
Reasoning
A team that doesn't share the same mental model of software testing will have inconsistent results no matter how good their tools are. ISTQB provides a proven framework — test levels, test types, defect lifecycle, risk-based testing — that creates a common language. Once the team shared that language, conversations about test strategy got dramatically faster and more substantive.
The Problem Was Language
In a sprint retrospective, one engineer called something a “regression test.” Another called the same thing an “integration test.” A third called it “sanity testing.” They were talking about the same thing — but the disagreement cost 20 minutes of the retro.
This wasn’t a rare event. It was the norm. And inconsistent vocabulary leads to inconsistent coverage.
Why a Standard Certification Over Internal Training
I’ve seen many companies build elaborate internal training programs. They’re usually great at covering “how we do things here” but weak at covering “why we do it this way” — the principles behind the practices.
ISTQB’s Foundation Level is deliberately principle-focused:
- Test levels (unit, integration, system, acceptance)
- Test types (functional, non-functional, structural, regression)
- Defect lifecycle and classification
- Risk-based testing approach
- Test estimation techniques
These are transferable skills that make engineers better regardless of which tools or projects they work on.
Implementation
- Company funds the exam (removes financial barrier, signals organizational investment)
- Bi-weekly study sessions for 6 weeks before each exam cycle
- Study materials provided (official ISTQB syllabus + recommended books)
- Two attempts allowed with company support
- Celebration ritual — passing the exam was recognized publicly in all-hands
Impact
Within 18 months, 100% of the QA team was ISTQB certified. The tangible changes:
- Bug reports improved dramatically — structured severity/priority classification, clear reproduction steps
- Test planning conversations became faster — shared vocabulary eliminated lengthy debates about scope
- Junior engineers gained confidence — the certification gave them a credible framework to push back on “just test it quickly” pressure
- Hiring bar improved — ISTQB certification became a preferred requirement, signaling professionalism to candidates
The Unexpected Benefit
Several QA engineers reported that ISTQB made them more confident in stakeholder conversations. When a PM asked “is it fully tested?” they could articulate what kinds of testing had been done, at what levels, and what risk remained. That professional clarity changed how QA was perceived by the whole product org.