In most cases, the most practical way to demonstrate both that all the features were implemented, and that they are implemented in an interoperable fashion, is to to show that there are test cases that cover most of the features of the specification, and that for each of these test cases, there are at least two implementations that pass it. So, while the Process Document leaves some leeway (which is useful since not all specifcations can make use of a test suite), if a Working Group is developing a technology that can be tested in a sensible fashion, the W3C Director is likely to require a test suite before allowing to move to Proposed Recommendation.

Test planning should start very early; ideally at the same time as you start working on the specification. Defining a testing approach (what kinds of tests to develop and how they should operate) and thinking about testability are helpful even in the early stages of specification development. During the planning phase, identify all the specifications to be tested. This may seem obvious but often specifications refer to or depend on other specifications. It is also important to understand and to limit the scope of what is to be tested; so, focus on what really needs testing and not on related or dependent technologies being utilized indirectly by implementations.