Repository navigation
ISTQB Compliance Review
Issue: #1054 Type: investigation (documentation + backlog triage — no application code changes) Date: 2026-09-09 Status: VERIFIED-FIXED
This review maps the ISTQB (International Software Testing Qualifications Board)
fundamental testing process and supporting concepts against the features actually
implemented in this TestLink 2.0.1 modernization. Every "Full"/"Partial" claim is
grounded in a real repository artifact (API area, docs/ page, modernized screen)
so a developer can open the cited source to confirm.
ISTQB Foundation Level describes a fundamental test process with the phases: test planning & control → test analysis & design → test implementation & execution → evaluating exit criteria & reporting → test closure activities. Around it sit supporting concepts: test strategy, test levels, test types, risk-based testing, static testing (reviews), traceability, and metrics/reporting.
TestLink 1.9.20 (and this modernization of it) was architected primarily as a test-case execution + reporting tool. The review below shows which ISTQB concepts are fully, partially, or not at all represented in the product's data model and screens.
Legend: Full = first-class, dedicated feature · Partial = possible but without a dedicated ISTQB-first model · Missing = no representation.
| # | ISTQB concept | Current TestLink support | Coverage | Evidence (repo) | Notes |
|---|---|---|---|---|---|
| 1 | Test strategy | No explicit strategy model (no global vs per-level strategy doc/object in schema, no strategy field) | Missing | scan of lib/ + api/ found no strategy entity |
Can be approximated by free-text docs/custom fields only |
| 2 | Test planning | Test Plan object with scope, status, active/archive, milestones, assigned builds/platforms | Partial |
api/plans/, docs/Test-Plan-Management.md, WIKI-TEST-PLAN-MILESTONES.md, api/milestones/
|
Plan scheduling/timeline, owner, resources and effort estimation absent |
| 3 | Test analysis | Requirement specs (ReqSpec + Requirement with versions) and review of requirement coverage | Partial |
api/requirements/, api/reqspec/, api/reqcompare/, docs/Requirement-Editor-Modernized.md, WIKI-REQUIREMENT-SPEC-MANAGEMENT.md
|
No dedicated "test conditions" artifact separate from test cases |
| 4 | Test design | Test Case editor: steps, preconditions, expected results, importance/urgency (priority), keywords, custom fields | Partial |
api/testcasesedit/, api/testcases/, docs/Test-Case-Editor-Modernized.md, docs/Test-Case-Bulk-Operation-Modernized.md
|
No support for equivalence partitioning/BVA modelling tooling; TC is the unit |
| 5 | Test implementation | Assign TC to plan, execution assignment to testers, builds, platforms, priorities | Full |
api/tcassign2tplan/, api/execassignment/, api/builds/, api/platforms/, docs/Test-Case-Assign-to-Test-Plan-Modernized.md
|
Strong, first-class implementation flow |
| 6 | Test execution | Execute test case, record result per step, execution type, notes, attachments, execution history, set batch results | Full |
api/execute/, api/executionedit/, api/execsetresults/, api/executeexport/, docs/Assign-Test-Case-Execution-Modernized.md
|
Core strength of the product |
| 7 | Test evaluation / reporting | Results by status/tester/suite/issue, TC-flat, absolute-latest, metrics dashboard, test-result matrix, baselines, charts | Full |
api/results/, api/metrics/, api/reports/, docs/Results-By-Status-Modernized.md, docs/Reports-Test-Result-Matrix.md, docs/General-Test-Plan-Metrics.md, docs/Execution-Timeline-Statistics-Modernized.md
|
Rich reporting/reporting BFF. Exit-criteria evaluation (pass% thresholds) is Manual, not enforced |
| 8 | Test closure | No dedicated closure workflow: no lessons-learned, retrospective, closure report or closure checklist | Missing | grep of lib/+api/ for `lesson |
closure |
| 9 | Test levels (component/integration/system/acceptance) | No level taxonomy field on plan/TC; only a top-level suite hierarchy | Missing | no test.level/testtype field in schema |
Could be simulated with suite naming/CF |
| 10 | Test types (functional / non-functional: performance, security, usability…) | No structured type taxonomy; keyword tagging is the only free-form proxy | Partial |
api/keywords/, docs/WIKI-KEYWORDS-ASSIGN.md, docs/WIKI-KEYWORDS-SI-TAGS.md
|
Keywords allow classification but not an enforced ISTQB type model |
| 11 | Risk-based testing | Priority computed from importance × urgency (lib/functions/testcase.class.php:4688,6826), filters per plan |
Partial |
lib/functions/testcase.class.php priority calc; plan-level priority filters |
No likelihood/impact (product-risk) model, no risk-priority chart, no risk-based selection automation |
| 12 | Static testing (reviews) | No review workflow for Test Cases, Requirements or Specs (no reviewer/review-status entity, no review checklist) | Missing | scan of lib/+api/ found no review/reviewer entity |
Should be a backlog task
|
| 13 | Traceability | Requirement ↔ Test Case coverage (covered/uncovered), requirement version compare, TC ↔ issue-tracker linkage, keyword tagging | Full |
api/reqcompare/, docs/Requirements-Coverage-Modernized.md, docs/Requirement-Management-Systems-Modernized.md, lib/requirements/reqView.php, lib/results/uncoveredTestCases.php
|
Req↔TC traceability is a real strength; traceability to quality objectives/risks is the missing axis |
| 14 | Metrics & reporting | Metrics dashboard, per-status/per-tester/per-suite/per-build, never-run, without-tester, TCs-created-per-user, timeline statistics, baselines | Full |
api/metrics/, docs/Test-Cases-Never-Run.md, docs/Test-Cases-Without-Tester.md, docs/Baselines-L1-L2.md
|
Strong; lacks pre-defined ISTQB-style exit-criteria dashboards and defect-density vs risk |
| 15 | Defect management | Issue tracker integration (Jira/Bugzilla/Redmine/GitHub…) and "results by issues" report | Full |
api/trackers/, api/codetracker/, docs/Feature-433-Native-GitHub-Code-Tracker.md, docs/Results-By-Issues-Modernized.md
|
External BTS linkage covers defect tracking |
| Coverage | Count | Concepts |
|---|---|---|
| Full | 6 | Test implementation, execution, evaluation/reporting, traceability (req↔TC), metrics, defect mgmt |
| Partial | 4 | Test planning, analysis, design, risk-based (priority proxy), test types (keywords) |
| Missing | 5 | Test strategy, closure, test levels, static testing/review, quality-objective traceability |
| Priority | ISTQB concept | Gap | Suggested backlog item |
|---|---|---|---|
| High | Test closure | No lessons-learned / closure / retrospective workflow |
task: Closure report + lessons-learned module |
| High | Risk-based testing | No structured risk model (likelihood/impact/product-risk) |
task: Risk-based testing model + risk-coverage view |
| High | Traceability to quality objectives/risks | Req↔TC exists; objective/risk traceability doesn't |
task: Quality-objective & risk traceability matrix |
| Medium | Static testing / reviews | No review workflow for test cases/requirements/specs |
task: Peer-review workflow for test cases & requirements |
| Medium | Test strategy | No strategy artifact |
task: Test strategy document object linked to plans |
| Medium | Test levels & types | No level/type taxonomy |
task: Enforced test-level & test-type classification |
| Low | Exit-criteria enforcement | Pass% thresholds not enforced in evaluation |
task: Configurable exit-criteria thresholds on test plans |
| Low | Test planning depth | No timeline/resource/effort estimation on plans |
task: Plan scheduling + effort estimation |
The gaps above are filed as separate, self-contained task-labeled GitHub issues
so the CI factory (implement-task-*) can pick them up independently. Each
references this review (Refs #1054):
| Issue | Gap addressed |
|---|---|
| #1277 | Risk-based testing model (likelihood/impact + risk-coverage view) |
| #1278 | Test closure module (lessons-learned + closure report) |
| #1279 | Test review / static-testing workflow for test cases & requirements |
| #1280 | Quality-objective & risk traceability matrix |
The lower-priority gaps (test strategy artifact, test levels/types taxonomy,
exit-criteria thresholds, plan scheduling/estimation) are captured in §3 and may
be filed as further task issues when capacity allows.
To progress TestLink from an execution + reporting tool toward a fuller ISTQB-aligned platform, prioritize in this order:
- Risk-based testing model (highest value for prioritization) — reuses the existing importance×urgency priority hook.
- Traceability to quality objectives & risks — extends the existing strong req↔TC traceability.
- Test closure / lessons-learned — completes the ISTQB lifecycle.
- Static testing / review workflow — supports earlier-SDLC activities.
- Test levels/types taxonomy + test strategy artifact — formalizes planning vocabulary.
- Exit-criteria thresholds — makes evaluation actionable.
Because this issue changes no application code, the "regression" check is that every Full/Partial claim in §2 points to a real repository artifact. Verification was performed by:
- opening the cited
api/<area>/directory for each Full/Partial row; - opening the cited
docs/*.mdpage for each Full/Partial row; - grep-scanning
lib/+api/for the Missing concepts (strategy, level, type, risk, review, closure) and confirming no dedicated entity exists.
No Event Viewer check is applicable (no runtime code executed). No security
vectors introduced.