⚙ prototype · architecture confirmed · adapters implemented · 2026-04-26
What is MI-M-T?
MI-M-T (Methodology for Integrated Manual Testing) is a structured approach to software quality evidence management. It addresses a gap that exists in most development workflows: manual test execution produces results that disappear into notes or spreadsheets, never accumulating into an auditable body of evidence linked to the defects they verify.
MI-M-T introduces a test object model — three YAML artefacts that together form a traceable evidence chain:
bugs.yaml— structured defect registry with severity × priority classification, reproduction steps, root cause, fix reference, and lifecycle statustestcases.yaml— test case definitions linked to bugs, with explicit expected/actual steps and preconditionstestruns/— timestamped execution records, one file per run, capturing actual results, environment context, and pass/fail verdicts
The result is a complete traceability chain: bug → test case → test run → evidence. Every defect has a test case. Every test run produces a dated, reviewable record. Nothing is implicit.
Why MI-M-T alongside JIRA?
MI-M-T is designed to coexist with — not replace — JIRA, Atlassian tools, and Postman. JIRA handles issue tracking and project structure well. What JIRA does not enforce is the structured test object model: explicit expected/actual fields per step, component-scoped evidence, and reproducible testrun reports that export as living documentation.
The value proposition is bidirectional sync at low cost. MI-M-T owns test design and execution evidence. JIRA owns metadata — status, assignee, fix version, labels. A single CLI call keeps both in sync:
mi-m-t sync --bidirectional --source jira --dry-runThis means no duplication penalty. Work in MI-M-T; JIRA stays current automatically.
Architecture
The 4-step evidence chain
| Step | Artefact | Authority | External sync |
|---|---|---|---|
| 1. Report | bugs.yaml |
MI-M-T (steps, evidence) | JIRA (status, assignee) |
| 2. Design | testcases.yaml |
MI-M-T (steps, expected) | Zephyr Scale (read-only copy) |
| 3. Execute | testruns/*.yaml |
MI-M-T (actual, verdict) | Newman → testrun converter |
| 4. Report | MkDocs export | MI-M-T (living docs) | JIRA attachment / Confluence |
Integration interfaces
MI-M-T communicates with the external test ecosystem through two typed adapter interfaces:
| Interface | Direction | Protocol | Auth |
|---|---|---|---|
| D03 — JIRA | Bidirectional | JIRA Cloud REST API v3 + Zephyr Scale v2 | Basic (dev) / OAuth 2.0 3LO (prod) |
| D04 — Postman | Import + execution capture | Postman API v10 + Newman CLI | Postman API key |
Both interfaces are implemented as Python adapters extending BaseIntegrationAdapter — an abstract base class that enforces a uniform contract for importing test targets, pushing results, and fetching attachments. The adapter layer isolates MI-M-T’s core schema from external API changes.
Demo Case: 3-fold-path
MI-M-T’s current dataset is the 3-fold-path project — three interconnected WordPress sites (zemla.org, mim2000.cz, bodyterapie.com) developed in parallel under a shared theme library. Real bugs, real test cases, real evidence — not synthetic examples.
| Metric | Value (as of 2026-04-26) |
|---|---|
| Total bugs registered | 22 across 3 sites + cross-site |
| Open / reported | 12 |
| Closed / fixed / verified | 10 (including 4-version podcast player hotfix chain) |
| Test cases | 15 — 100% bug coverage |
| Languages covered | CS · EN · DE · IT · JA (5 locales) |
| Severity breakdown | A-blocker: 7 · B-major: 12 · C-minor: 3 |
| Components covered | podcast · podcast/player · blog · content · cross-site |
Severity × Priority triage matrix (current state)
| Priority A immediate |
Priority B next session |
Priority C backlog |
|
|---|---|---|---|
| Severity A blocker |
0 | 3 open | 2 open |
| Severity B major |
0 | 4 open | 3 open |
| Severity C minor |
— | 0 | 0 |
No priority-A blockers remain open — the podcast player hotfix chain (BUG-018 through BUG-021) closed the last severity A/priority A cluster in v1.7.4.
Tooling
# Triage — list open bugs by severity × priority
python3 evidence/tools/triage.py --site zemla --status open --matrix
# Filter by component
python3 evidence/tools/triage.py --component podcast/player
# Generate MkDocs evidence report
python3 evidence/tools/evidence-report.py --format mkdocs --output docs/evidence/
# JIRA sync (bidirectional)
mi-m-t sync --bidirectional --source jira --dry-run
# Postman collection import
mi-m-t import --source postman --collection-id {uid} --dry-run
# Newman execution → testrun YAML
mi-m-t run --postman --collection TC-001 --environment prod \
--output evidence/testruns/Implementation Status
| Component | Status | Notes |
|---|---|---|
| bugs.yaml schema + seed data | ✓ done | 22 bugs, 22/22 integrity pass |
| testcases.yaml seed data | ✓ done | 15 test cases, 100% bug coverage |
| triage.py CLI | ✓ done | Filter/sort/matrix view (MI-M-T-P04) |
| evidence-report.py | ✓ done | MkDocs markdown export (MI-M-T-P05) |
| BaseIntegrationAdapter (D02) | ✓ done | ABC + ImportedTestTarget dataclass |
| JiraAdapter (D03) | ✓ done | 23 assertions — 43/43 smoke PASS |
| PostmanAdapter (D04) | ✓ done | 20 assertions — 43/43 smoke PASS |
| C4 architecture diagrams | ✓ done | System context + container (draw.io + puml) |
| First manual testrun (P06) | ⧖ pending | mim2000 CEO blog all locales — ThinkPad |
| JIRA webhook integration | ○ planned R3 | Real-time delta sync on issue change |
| Newman execution bridge | ○ planned R3 | Auto testrun capture from Newman output |
MI-M-T v0.1.0 prototype · ← Projects · Last updated: 2026-04-26