Following up on the last post on starting with a blank sheet of paper, Rick Grey pointed out that when he first starts writing up his notes, he prefers to work in a plain text editor - not a word processor. He does this so his focus remains on content, not on formatting. If he doesn't have tables, bullets, and headings available to him then he can't spend hours trying to format them to get them just right.

This tip was part of a brainstorm developed at the September 2011 Indianapolis Workshop on Software Testing on the topic of "Documenting for Testing." The attendees of that workshop (and participants in the brainstorm) included: Charlie Audritsh, Scott Barber, Rick Grey, Michael Kelly, Natalie Mego, Charles Penn, Margie Weaver, and Tina Zaza.

When I sit down to write a formal test document, I start with a blank sheet of paper. I do not start with a template.

I do that for a couple of reasons. First, I find that when I use a template I spend more time focusing on filling in the various sections than I do really thinking about the problem I'm trying to solve. The template distracts me from focusing on the problem in a deep and meaningful way. Second, I find that templates can anchor my thinking into specific solutions. When I'm actively thinking about what I want to do with my testing, I want every option on the table. I don't want a document to "guide" my thinking by limiting my options to the sections it contains.

Later, after I've done all the heavy lifting, I'll go back and format my document into the company template for that document. That allows me to add/remove sections as needed. The template does serve as a useful tool at that point. It serves as a quick check-sum to let me know if I've missed any critical piece of the equation or if I haven't thought something out enough.

This tip was part of a brainstorm developed at the September 2011 Indianapolis Workshop on Software Testing on the topic of "Documenting for Testing." The attendees of that workshop (and participants in the brainstorm) included: Charlie Audritsh, Scott Barber, Rick Grey, Michael Kelly, Natalie Mego, Charles Penn, Margie Weaver, and Tina Zaza.

When we submit defects, we often include a core set of data that's included on every ticket. For most organizations, this will include the submitter, the environment where the issues was discovered, the steps to reproduce, and often some sort of attachment showing or demonstrating the issue. In many cases, this core information can be captured and filled out automatically. Some defect tracking tools provide features that provide this functionality, but even if they don't a lot of times you can write a really simple script to populate a lot of this information for you. At a minimum, if your team has an expectation for some of these aspects to be filled out for all tickets, consider making those fields required to help ensure that each one is at least touched/reviewed before the tester clicks submit.

This tip was part of a brainstorm developed at the September 2011 Indianapolis Workshop on Software Testing on the topic of "Documenting for Testing." The attendees of that workshop (and participants in the brainstorm) included: Charlie Audritsh, Scott Barber, Rick Grey, Michael Kelly, Natalie Mego, Charles Penn, Margie Weaver, and Tina Zaza.

This is a test. Think of it as an test of WordPress analytics. No really, you're participating in it right now. I'm curious who's reading this thing we call QuickTestingTips. Here's your mission - should you choose to accept it...

There are two steps:

1. Right NOW: leave a comment on this post. Be sure to include a link to your web page, blog, or twitter feed - your choice. Something that lets the world know who you are. Say anything, just don't say you don't like the site. That's not cool. We're fragile.


2. Tomorrow: Come back and see who posted. Check out who they are. Follow them on twitter or RSS their blog. Connect to someone new - who you've never seen or heard before.

I'll likely turn off comments after the first day. (Otherwise it's not a very effective measurement is it?)

Update: I didn't turn off comments. I figured it would be better to let the links continue. Please post!

When you work with someone for a long period of time, you start to develop a shorthand for communication. Similarly, many of us have found that we leverage a lot of the same heuristics and mnemonics for communicating how we're thinking about the problem and where we're at with our work. This can become incredibly powerful as a means of saving time during documentation and verbal communication.

If your team regularly uses mnemonics like FIBLOTS, MCOASTER, SFDPOTS, HICCUPPS or SLIME then you can in many situations save yourself some verbiage and just reference those mnemonics or heuristics. If you find you don't have one for a process or technique you often practice - then CREATE ONE! And share it. For some idea of the mnemonics out there, check out this list curated by Lynn McKee.

(How can you not freaking love a mnemonic called SLIME?)

This tip was part of a brainstorm developed at the September 2011 Indianapolis Workshop on Software Testing on the topic of "Documenting for Testing." The attendees of that workshop (and participants in the brainstorm) included: Charlie Audritsh, Scott Barber, Rick Grey, Michael Kelly, Natalie Mego, Charles Penn, Margie Weaver, and Tina Zaza.