Hi Adam. >Well, depends on your definition of "quality assurance."
Not really from an engendering point view (there is a lot of literature out there about this subject). I've contact with people who's fundamental purpose to exist in a company was to enforce quality (QA Departments). Their main job was to assure that people and systems were behaving as required. And if there were deviations from what expected and required then a controlled change process would start and so on. The point is: What needs to be assured varies from system to system, and company to company. How it is assured also varies from context to context. Now QA is and always will be assuring that a system (artificial, organic or a combination of both) behaves how it is required. For instance, if requirements state that published articles should have no grammatical or syntactical errors then one needs to assure that it does not happen. If requirements state that only glossy apples can be exposed to the public, then you need to assure that no apples outside requirements are exposed to the public. This is not to say that in order to assure quality you don't need to establish procedures. >In our case, part of that is assurance that all documents have certain >metadata attached to them - so we've built a workflow that won't let a user >transition a document from state A to state B if some of that meta >information is missing. Good, that was the way that your company found to enforce requirements. Note that your company required that certain metadata within documents was mandatory so you enforced that using a workflow within your CMS. Others may find other solutions but I agree with you one should be able to establish this simple rules when defining a workflow in a CMS. The workflow that I'm building not only you can specify those kinds of rules (mandatory meta-data fields) but also one can specify what fields will be able to be seen or/and edited in each step according to each user role of the workflow. That is to enforce rules such as "User's should only see and edit what they need to see or edit". This is not to say that QA is not an evolving activity. The pivotal point of QA development and evolution are "feedbacks" and change procedures. One example was given by Michael Kimslal in a related thread still rolling. Best regards, Nuno Lopes Independent Consultant -- http://cms-list.org/ trim your replies for good karma.
