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.

When I started working at Scriptorium, one of my first tasks was to develop a content test bed to run alongside our PDF transform to help improve it. For example, one part of our test bed is a massive thread pitch table. It will readily flow across multiple pages, includes both vertical and horizontal straddles, and has varying column widths. If we run into a problem with large tables, I can run that content through, confident that I’ll be able to reproduce the issue and deal with it accordingly.

Making a test bed

A test bed is a useful tool when managing your content. In the context of content strategy, a test bed is a set of topics that represents a broad section of your content. However, a test bed is more than just a sample of your production-ready content; to be truly useful, a test bed should be:

• Modular: You should be able to add and remove chunks of content from your test set. This allows you to quickly set up use cases to verify your output. You also need to be able to quickly trim the size of your test bed to cut down on processing time for tests, unless that test involves a large document.
• Well-maintained: As your content grows and changes, so too should your test bed. Otherwise, you run the risk of missing critical errors that can creep in when you do your testing.
• Representative: You should have examples of all major requirements for a particular publication. If you have a table that needs to be formatted in a specific way depending on its context, make sure that you have that example in your test bed. Also keep in mind errors that turned up in the past, so you can keep an eye out for bugs that might creep back into your workflow.
• Content-neutral: Make the actual content of your test bed generic. While it can be useful to have your actual content in your test bed, it can also make it problematic if you need to hand that test bed off to an outside entity, like a friendly consulting group. If you need to have “real” content in your test bed, make sure that it’s already publicly available or otherwise non-sensitive.

Using a test bed

Once you have a solid test bed in place, it can provide benefits both internally and externally. Internally, if you’re using a platform to generate output, you can run your test bed through it to verify any changes made to that platform. Conversely, if you implement a major change to the format of your content, you can use your test bed to more accurately scope the impact of that change. You can also use it as an example to familiarize new authors with your content. Externally, you have content that you can hand off quickly, without spending time compiling a set of appropriate documents that represent your project needs.

With a bit of maintenance as your documentation needs change, your test bed can become a versatile and powerful tool when both developing and maintaining your content.