Re: Format for QAF principles

Good start. I'm working on a draft for TestGL, and am finding that I 
want to say "principle x" implies a, b, c, where a...c might be 
"guidelines" or "checkpoints" or potentially (recursively) 
"sub-principles". For example:


TestGL Principle #1: Users of the test suite must understand what is 
tested, how extensively it's tested, and what is not tested

Rationale: They need to know whether this test suite applies to them, 
the extent to which they can rely on it, where they might need to focus 
additional testing efforts.

This implies:

* The scope and goals of the test suite are documented
* Coverage information is provided (it must be possible to map tests 
back to the spec)
      Assertion lists are a good way to do this


Lynne Rosenthal wrote:

>
> To get us started and to help provide consistency as we write the 
> principles, here is a proposed format that we can follow.  Realize 
> that all the items may not apply or be necessary for each and every 
> principle.   I wasn't able to find Karl's QAF to FAQ to ensure that I 
> captured his ideas - but I think I have.
>
> +++++++++++++++++++++++++++++++++++++
> Storyboard (story, situation)
> Preconditions or assumptions
>
> [PRINCIPLE]
> Descriptions
> Benefit of applying principle
>
> Examples, more examples
> Template and/or tool to implement
> [good practices]
> [constraints  exemptions, caveats]
>
> Assessment: Have I got it right  how do I know
> +++++++++++++++++++++++++++++++++++++++++
>
> At a minimum:  we should always have the Principle, description, 
> examples.
>
> Words to remember:
> Acknowledging that giving advice is easy and implementing it is hard, 
> we need to:
> - try to find the balance between too much documentation, complexity 
> and over-simplification.
> - remember that stating the obvious is not always obvious
>
> --lynne
>

Received on Wednesday, 3 March 2004 04:05:59 UTC