if you use conditional build tags, wouldn't hurt to add a few spot checks to make sure that the build expression is actually excluding
what you want it to.
this is a good topic - looking forward to hearing all input, as it's about time I insisted on our Help being treated with the
same process and consideration as the application.
Good point - I'm only using CBTs to exclude topics from output, so my testing is pretty easy. But for folks using CBTs to exclude text or do coditional text for different outputs, things could get messy.
I suppose one could incorporate the Build Tags report into the test plan.
Any concerns about print issues? Search/glossary/index issues?
I don't have any print worries as I work for a web service company. Others might, and would need to have sections in their test plan for each type of SSL output.
Search and Index testing I'm working on, though I'm only spot checking of course. I've not yet implemented a Glossary as I haven't decided whether to use RH's built-in glossary functionality or simply create one topic with alphabetical links as described in other posts on this forum. Probably next version.
Things I routinely include in my testing, for web based help.
- Browser compaibitlity - IE ,6,7,8, Firefox, Chrome, Safari, Opera? This browser testing includes all of the following:
- For Safari, of course you should test on a Mac, in additiona I also test Firefox on the Mac, and now Chrome also.
- TOC Sync if using merged projects.
- Image sizing and viewability. Does the user need to scroll across to view an entire image.
- TOC horizontal scrolling, pet hate for me, so the TOC has a custom width to ensure the widest possible expansion is within the TOC pane.
- Viewing at various resolutions, our web app is designed with a minimum resolution catered for, so the help is tested against that - this will include scrolling, image width etc etc.
- Quick test of various topics that contains snippets to ensure they are correctly used and formatted.