Manbearcat
Legend
I disagree. A playtest campaign works just fine as long ad the DM and players are flexible.
At some point, however, the philosophy of "rulings not rules" has diminishing returns...specifically in a playtest that presupposes that you are going to attempt to play an RPG adventure. Obviously we're not at the point of; "You open the box, inside is a piece of paper that says 'roleplay'." However, we are somewhere between there and having tactical combat depth and extra-combat resolution systems (we have one for combat, of course, but not for the exploration and social pillars - which I thought this edition was working steadfastly to prove that it is just as consequential as combat) that move the fiction forward without DM force/fudge/railroad or DM + player co-opting emergent play (by way of mechanical resolution) through mutual, implicit, speakeasy agreement. We have PC build rules, a kinda-sorta task resolution, some flavor over crunch magic items, and some vanilla monsters that are below the power curve. You can playtest an adventure with this but it really says more about a group's/DM's ability to "fill in the holes" than it does about the ruleset itself. This may be the point, perhaps. I don't know.
I think there are a lot of people that want more "rules not rulings". They'd rather focus their creative agenda and their mental energy/focus on the fiction-creation side (that emerges from the PC/mechanics interface used to resolve conflicts/challenges) rather than the ad-hoc mechanical resolution side or the "filling in the holes" (refereeing a nebulous, open-ended yet inconsistent framework) that the designers either willfully or unknowingly left out.
In its current iteration it strikes me as a much better route to just create characters and run episodic, closed scenes whereby you challenge the PCs with various conflicts that they must resolve (by way of the resolution mechanics available) and see how the tangible metrics (PC vs PC performance vs monster performance) and how the intangibles (mechanic resolution tools) perform in each of the challenges and then provide concrete feedback on that. A playtest iteration (as any engineering project) is meant to be poked/prodded and the moving parts inherent to the product tested "as-is" lest you risk testing (and subsequently providing feedback on) something outside of the scope of the current playtest iteration. Inserting "extra-product" components and seeing how they synergize or how they perturb the system that is being tested is counter-productive (under normal engineering standards) to measuring the output of the project's current iteration. This is, of course, premised upon that standard of testing/QC and product development being compartmentalized and thus product development iterates and testing/QC tests and quality controls creating a feedback loop (which would seem to be the case...I know I didn't get my "product development" wages or badge for these last few months).