Breaking Things as a Form of Creativity

by Tom Johnson on Jul 1, 2010
categories: creativity • technical-writing

IT Author's latest podcast, Testing testing 123, dives into testing. Rather than just commenting on testing from a technical writer's point of view, Alistair Christie and his co-host Graham Campbell interviewed an actual tester. It's a good interview with lots of informational nuggets. For example, "regression testing" is testing those software features that were tested previously. Every new feature has the potential to affect other features, so even if you've already tested something, you have to test it again.

While listening to the show, I admit I felt a sense of gratitude for not being a tester, because they seem to lead somewhat dull lives. But later in the show, the tester, Richard Paterson, explained that breaking things requires a lot of creativity. It's not just a matter of ensuring things work, but thinking about non-standard ways that customers might use the product to break it.

Testing also invites you to figure out how something works, so it requires a driving curiosity about how all the parts fit together and interact on a deeper level. By the end of the show, I began to see how testing could be an interesting, fulfilling job.

Prescription and Description

Apart from creativity and curiosity, during their discussions about testing, they also noted that testers look at whether the product works according to the design specifications, whereas technical authors look at how the product works as implemented in a development environment. In other words, testers look at the product from a prescriptive point of view. Technical authors usually look at the product from a descriptive point of view.

I find this fascinating and true. In our agile environment, our design specifications are thin and rely more on the interaction designer's prototypes, discussions in meetings, and one-on-one's with the product managers and team leads. Sometimes the implementation changes from the prototypes, so it's hard to refer back to any design specification as a standard. Additionally, the prototypes, once created, are not always updated to reflect the latest changes.

Because we so often work descriptively, we feel that we can't start documenting a product until we have an environment to explore. But recently a friend of mine told me an interesting story. She said she once tried writing documentation based on the specifications rather than the product (which hadn't been coded yet). She poured through the specifications with such thoroughness that her meetings with the product managers and other team leads would drag on for hours, as she clarified the absent detail and other gaps in the specifications. After a while, the product managers recognized her thoroughness and insight and made her a product manager.

So while we often don't write prescriptively, according to design and functionality specifications, there might be advantages in doing so. As a counter to this point, Graham noted that there's a danger in getting involved in the project too early, because as the product changes, the documentation you wrote early on gets outdated. You end up rewriting everything.

Test Cases Versus User Documentation

Another interesting discussion in the podcast included parallels between test cases and user documentation. Presumably, the tester has written test cases that list the steps for all major functionality in the application. User documentation lists the steps for tasks the users want to complete. Can't we borrow or at least drive some of our documentation from test cases?

I think test cases can be helpful, but they can also be harmful. Helpful because they give you a starting point about what to document. Harmful because a tester's perspective is not the same as a user's perspective, and as I mentioned in a preceding post, our documentation should focus on the problems and issues users will have, rather than just describing the basics of an application.

Different Perspectives

Overall, the tester on any project team is a person you need to know well. I find that in my organization, testers know the product inside and out, and they're less busy than project managers in answering questions.

At the same time, while most testers are analytical and sharp-minded, they focus too much on this question: Does the product work as designed? Technical writers, as user experience champions, have another question in mind: Is this design working?