QA in techcomm: creating use cases
A few months ago, I wrote about how you could benefit from having a test bed for your content. I made mention of use cases several times, but what are they, and how can you make them effective?
Author: Jake Campbell
QA in techcomm: you need a test bed
When I first started as a QA tech at a small game company, I was immediately thrown into the QA test bed. It was a place where we could test production-ready content without being interrupted by ongoing development or server restarts. Functionality was well-documented and could be used to test against our users’ bug reports.
The friendly guide to the scope, format, and type attributes in DITA
In testing one day, I was running a set of sample content through the DITA-OT, and much to my consternation, the build was succeeding, but generating no content. The error log helped to ferret out the source of the problem; the preprocessor was attempting to extract a linktext and navtitle from an image file that could not be found.
The image in question was a keyref pulled in from a map referenced in the main map file. Everything validated, previews showed the images resolving correctly, yet the images steadfastly refused to be pulled in during preprocessing—so what was wrong?
The perils of early adoption
It finally happened. A part of your production pipeline has failed too many times, and everyone is in agreement: you need a hero.
DITA 1.3 overview
Robert Anderson, one of the DITA architects, compared the transition from DITA 1.1 to DITA 1.2 to the difference between having a couple of drinks with friends and a huge party. The DITA 1.2 specification introduced broad changes in the form of new base elements, new architectural structures, and new specializations.
DITA 1.3 isn’t the rowdy gathering that DITA 1.2 was—it’s more a group of friends going out to the new pub downtown while being sure to get some designated drivers. This article describes the most important additions to DITA 1.3.
