Why care? It's not always easy to anticipate Working Group (WG) needs during the rush and pressure of Chartering, or in the busyness of early WG life. But the earlier the WG can accurately identify and commit to its test and other quality related deliverables, the less likely that the WG get big surprises later on, or run into problems that will delay its progress towards Recommendation. (the less likely it is that the WG will get major surprises later on, or run into problems that will delay its progress towards Recommendation.)
Additional reason -- b (B)inding decisions about WG membership (e.g., numbers per company) often are made at Charter time.
What does this mean? In practice, this means attention to a handful of points, which we enumerate as Good Practices.
Good Practice: Decide ASAP -- will the Working Group build test materials or acquire them?
Clearly, it is going to make a big difference in a Working Group's (WG) staffing requirements -- building test materials tends to be labor intensive (extremely so for some types of specifications). Even if the WG imports them, some staff resources will have to be applied (see last module). The particular test-related activities and milestones in the WG's programme of work will in general be completely different for develop (build) versus acquire options.
Good Practice: Think about and enumerate the QA activities & deliverables that might help the Working Group through the Recommendation track. Minimally, commit to assuring the timely existence of test materials.
Different kinds of QA deliverables might include:
Test materials are by far the most common QA deliverable, and likely will be a key to quick and painless passage through Candidate Recommendation (CR).
Good Practice: Synchronize QA deliverables with specification milestones, and for the bigger QA deliverables, define and schedule intermediate milestones if possible.
This advice echoes that in Tips for Getting to Recommendation Faster [REC-TIPS] for example see item #6 in section 2.
Good Practice: Consider whether the Working Group should tie any quality criteria to Rec-track advancement.
For example, finishing test materials deliverables before requesting Candidate Recommendation (CR) is common (important), in order to facilitate CR's Implementation Assessment. (Counter-example: as in the above Story, if the WG is still building them during CR, it is likely to uncover things that will oblige it to cycle in CR.)
This good practice takes the synchronization of the previousone (synchronization of deliverables of the previous Good Practice) a step further -- the specification cannot (may not) advance unless the committed test or other quality criteria are met.
How to Organize a Recommendation Track Transition [TRANSITION] talks some about the role of test suites in advancement decisions.
Good Practice: Put some thought into how to staff the WG's QA plans.
The earlier this is done, the more options will be available. Some options include:
The third option isn't really different from the first. It's just a way of doing it. But notice that it's an option that is only available by looking into these questions at Charter time.
By the way, there has been confusion [TBD: find the chairs archive reference] about "W3C Process only allows each company to have two members on the WG". In fact, that is not from W3C Process. W3C Process gives considerable freedom for this to be tailored to WG needs -- W3C Process says it may be specified in the Charter. So, for example, the WG could decide on these rules: allow two per company in technical discussion, issue resolution, voting, etc; and, allow additional dedicated test suite builders.
By the way, this is another good reason to put some thought into test suite plans and other quality-related deliverables as early as possible.
Tips for Getting to Recommendation Faster [REC-TIPS] (section 3) also talks some about the value of (early) staffing decisions.
Examples:
How can I do it?