EM-TEC-08 · Subject model · W1
Test, verification and defect
Test specification, run, result, evidence and defect as a nonconformity claim. The remediation work item has an independent lifecycle.
Partially published; research continues
Claude: complete-frozen-study-and-single-audit; Grok: complete-exact-prompt.
Published results
Research note, in Russian: Canonical/runtime promotion remains governed by the package allocation, identity and dependency holds.
Subject boundary and candidate types
- TestSpecification
- TestRun
- TestResult
- Defect
- VerificationEvidence
Deep research questions
- How to separate expected behavior from the test implementation?
- When is a test failure a product defect, and when a test defect?
- How to link a verification to an exact version?
Verifiable invariants
- A run pins the object under test and the environment
- Flaky does not mean passed
- A defect contains the observed and the expected
End-to-end acceptance scenario
One defect with several tests, a flaky run and a re-verification of another version keep separate conclusions.
Negative case
A fixed test automatically closes a production defect.
Approaches to compare
- AISMM/WM-SFT and ArchiMate: product, system and architecture
- CSDM: business application, service and runtime instance
- SPDX/OpenTelemetry/Google SRE: delivery, observation and reliability; choose by boundary
Candidates in the live catalogue
- WM-SFT-015 · Test Case / Test Result · 0.3.0-research.1 · installable
Semantic fit requires boundary research; a published model does not by itself complete this card.
Result requirements
Every card is executed together with the full research contract: definitions, fields and cardinalities, lifecycle, sources, data mastership, rights, the five object facets, at least eight invariants, positive and negative examples, dependencies, migration and applicability limits.