A well-known conformance relation for model-based testing is ioco. A conformance relation expresses when an implementation is correct with respect to a specification. Unlike many other conformance and refinement relations, ioco has different domains for implementations and for specifications. Consequently, ioco is neither reflexive nor transitive, implying that a specification does not implement itself, and that specifications cannot be compared for refinement. In this paper, we investigate how

more »

... we can compensate for the lack of reflexivity and transitivity. We show that (i) given a specification, we can construct in a standard way a canonical conforming implementation that is very 'close' to the specification; and (ii) a refinement preorder on specification models can be defined such that a refined model allows less ioco-conforming implementations. We give declarative and constructive definitions of both, we give examples of unimplementable corner-cases, we investigate decidability, and we do that for ioco as well as for the ioco-variant uioco. The latter turns out to be simpler and on more aspects decidable. Software testing involves checking of desired properties of a software product by systematically executing the software, while stimulating it with inputs, and observing and checking outputs. Model-Based Testing (MBT) is a form of black-box testing where a System Under Test (SUT) is tested for conformance to a model. The model specifies, in a formal way, what the system is allowed to do and what it shall not do. As such, the model is the basis for the algorithmic generation of test cases and for the evaluation of test results. An important prerequisite for MBT is the precise definition of what it means for an SUT to conform to its model. Conformance is expressed using an implementation relation or conformance relation. We thank Frits Vaandrager for his valuable feedback.