Posts in Documentation
Understanding project goals - page two
A little over a year ago I met with another tester in town to provide advice on performance testing. I recently found the notes from the meeting in an old notebook. In the five pages of handwritten notes, I documented my understanding of the problem and how I would approach the project. Take these notes for what they are - sketches over the course of an hour or two as I asked questions and clarified the project. However, I thought they would be interesting to share.

The second page was an attempt to understand the goals of the performance testing.

Understanding project goals

They wanted to better understand their calls-per-hour capacity. They were also trying to determine how many licenses they needed of third-party software to support their anticipated load. As I took notes, I jotted down a couple of constraints and some additional details of a couple of key components/transactions.
Discussing a possible project - page one
A little over a year ago I met with another tester in town to provide advice on performance testing. I recently found the notes from the meeting in an old notebook. In the five pages of handwritten notes, I documented my understanding of the problem and how I would approach the project. Take these notes for what they are - sketches over the course of an hour or two as I asked questions and clarified the project. However, I thought they would be interesting to share.

The first page was an interactive attempt to understand the problem.

Project Overview

To protect the company (who might not want to be identified) I won't provide more details than what's in the picture, but what I remember was that it emerged over a series of questions where I asked things like: "And that's connected to?", "And that gets its data from where?", and "That's not on here yet, where does it go?"
Save examples of graphics you like
I’m a regular reader of the Wall Street Journal. While I like WSJ’s front-page news crib sheet and financial news, I’m really into their charts and graphics. I find that I’m constantly cutting out charts that I see and saving them as examples of a creative way to display complicated information. I don't know if I ever really go back and look at them that often, but the act of taking the time to cut something out and paste it into a moleskin helps me remember the graphic in a way I otherwise wouldn't.
Reviewing technical documentation
When testing documentation, in particular instructions or help documentation, try to keep in mind the following:

  • Follow any steps outlined in the document word for word. Do exactly what it tells you to do. It's not enough to just read the document, you need to test the steps.

  • As your reading, note what questions you have. In addition to checking what's in the document, you may want to provide feedback about what might be missing from the document. That's best indicated by what questions you ask yourself as you read.

  • Try approaching the document from different user perspectives. For example, if it's help documentation, does it contain step-by-step instructions and definitions for beginners? Does it contain shortcuts and an index for advanced users? Does it contain the appropriate amount of marketing buzz and product cross references for managers?