In QDL, the test plan is the documentation. So to test the app, you go through the Help posts, and try to do whatever it says you're supposed to be able to do. Any discrepancies between the documentation and the actual behavior of the app constitute bugs that should be entered.

• intended workflow doesn't actually work
• features in the docs that aren't in the app
• features in the app that aren't in the docs
• usage threw an error

If the bug pertains to a specific statement in the docs, and if you have rights to annotate the docs, you can just select the offending text, and add a sub-post. This will automatically quote the selected text in the sub-post, and create bi-directional links between it and the source post. It should automatically use the Bugs & Wishes prototype, but if it doesn't, this should be selected, so that if all else fails, we can find all of these annotations with a prototype report. Describe the nature of the bug & submit it. Then the sub-post so created can be cut-n-pasted to the folder.

 

If you run into a bug not really knowing which Help post pertains to that functionality, or if it is functionality that isn't specific to any one feature, you can enter a generic bug report. Later, if the appropriate docs are located, they can be linked to that report.

 

If you have editor rights to the Help posts, when you're done thoroughly testing the functionality described in one of them, edit the post, and without making any changes, just save it. This will update the modification date of the post, thereby marking it as having been touched. The significance is that we have a report that shows all of the Help posts, sorted by modified date (ascending). So it will show at the top the docs that haven't been tested in the longest period of time, which are probably the features that need to be tested next.

 

Once a bug report has been created, by whatever means, the report can be scheduled.