Return to HomePage

---

Checklist Item Test Cases

Title
* Title is in the form of a check?(fuel full? light on?)

Applies To
* Do you list technology and version? (e.g. ASP.NET 2.0)

What to Check For
* Does this section describe the essence of the checklist item?
* Is it a tight description - no more than 2 or 3 sentences?
* Is it clear to the reader what action they need to take in order to be in compliance?

Why
* Does this section explain the consequences of ignoring the checklist item?


How To Check
* Is this section broken into discrete steps? (ideally numbered 1,2,3)
* Is each step actionable?
* Is all necessary information included to be succesful?(Important information should be inline, not linked to.)


How to Fix
* Is this section broken into discrete steps? (ideally numbered 1,2,3)
* Is each step actionable?
* Is all necessary information included to be succesful? (Important information should be inline, not linked to.)

Problem Example
* Does the example show what the problem looks like in the real world?
* If there are multiple common problem instances are they all described?
* If this is a design checklist item is the example illustrated with images and text?
* If this is an implementation checklist item is the example in code?

Solution Example
* Does the example show the resulting solution if the problem example is fixed?
* If this is a design checklist item is the example illustrated with images and text?
* If this is an implementation checklist item is the example in code?

Additional Resources
* _Are the links from trusted sites? _
* Are the links correct in context of the checklist?
Related Items
* _Are the correct items linked in context of the checklist? _

Additional Tests to Consider When Writing a Checklist Item
* Does the title read like a checklist item (Noun then State). For example "Fuel is full" or "Brakes are off"?
* Does the title use conditions as appropriate (if 'this' then 'that')
* If the item is a MUST, meaning it is prevelant and high impact, is Priority = p1?
* If the item is a SHOULD, meaning it has less impact or is only applicable in narrower circumstances, is Priority = p2?
* If the item is a COULD, meaning it is nice to know about but isn't highly prevelant or impactful, is Priority = p3?
* If this item will have cascading impact on application design, is Type = Design?
* If this item should be followed just before deployment, is concerned with configuration details or runtime behavior, is Type = Deployment?
* If this item is still in progress or not fully reviewed, is Status = Beta?

---

Return to HomePage