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?

When you’re drawing up requirements for a project, a use case generally means the situation in which an element of that project is useful. In QA, though, a use case is an example or procedure to verify a feature.

Just knowing what you need to test isn’t enough, though; having use cases that are too narrow in scope or that are poorly constructed can complicate testing. This can lead to missing issues or inefficiency in testing.

Types of use cases

Not all use cases are created equal. When I put together test materials, I try to include a few different kinds of use cases.

• Simple: A standard implementation of a feature which answers the question “does this work?”
• Complex: An implementation where multiple use cases interact, verifying whether that interaction causes problems. This is useful if you have a platform or environment that requires a flattened document structure, as opposed to a nested document structure like XML.
• Failure: An implementation where the use case is either not allowed, or set up incorrectly. This is useful if you want to test things like error reporting or fallback processing.

Keep them separated

When you set up a use case within your content, whether at the document or block level, try to keep it clearly separated from other use cases. This is important because you can locate and verify your use cases more easily if they’re self-contained.

By keeping them isolated, you can also add or remove your use cases without having to worry about the impact that this will have on the rest of your test bed. There’s nothing more frustrating than removing an obsolete use case only to find that it’s tangled up with other content.

Keep it real

Lorem ipsum text is a useful way to fill large swaths of space to check general formatting. When setting up a specific use case, however, it is often more useful to create content that more closely approximates your actual content.

The most immediate benefit is recognizability. It’s not unusual for the eye to slide across the page when trying to read placeholder text. This will complicate things if you need to focus to check a use case.

Pictured: your validation team trying to check your use cases. Flickr: Kevin Krejci

The other benefit is organization. Seeing nearly-real content when verifying your output lets you know that this section needs more attention than just general formatting. Also consider ease of locating specific cases: you need to check a use case within a large test bed, but if it’s all lorem ipsum, how do you find it?

With use cases that are well-constructed, you’ll find that your test bed can serve as an even better asset than before.