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.

Some people struggle with saying no. It happens for a lot of reasons:

• we want to please others


• we really do want to do what we're committing to


• we are afraid to say no


• etc...

Here are some tips for saying no that I've found helpful:

• Force prioritization: "If I do that, something else needs to fall off my plate. What would you like that to be?"


• Remind them about long term effects: "If we write this code without writing our tests according to our methodology, in six months you'll regret it when we need to refactor this section of the code."


• Clarify that you're being asked to do something you can't: "You recognize that you're asking me to make a commitment that I can't really make, correct?"

However, no matter how you sugar coat it nothing beats a plain-spoken "No, I can't or I won't do that."

Practice it. No is more difficult than yes. Especially if you're saying it to yourself. Trust me when people would rather hear "no" upfront then have you say yes and then they don't get what they wanted.

Here's how I can tell I need help:

• I'm working at 1:00 AM and it's not because it's required (like some performance testing) or because I really like doing it (too much cool software and not enough daylight time).


• People are talking about something that needs to be tested and I can't follow the conversation (due to a lack of domain knowledge or technical knowledge).


• I'm missing deadlines (for the project I'm struggling with or for other projects because I can't get away from the project I'm struggling with).


• I'm not happy with the quality of my work.

If one or two of those happen for a short period of time, I probably need help. If all of them are happening (like they are right now), I know I need help.

When you need help, ask for it. That's easy to say, but hard for a lot of people to do. I know it's hard for me. I also know it's hard for many people who've worked for me. For me, it's an ego thing. But sometimes I need to recognize that I'm not helping anyone (most of all myself) by trying to hide the fact that I need help. Often, help is there - ready and waiting to be had.

If you're overwhelmed, ask for help. You might be surprised where it comes from.

A lot of testers know that if you want to be able to test well, you have to ask lots of questions and not just to one or two developers, but to a whole range of people who have some vested interest in the product your testing.  We ask questions to understand the context. We ask questions to understand the application we are testing.

I wonder though, am I the only tester out there who is not  that great at listening to the answer?

I ask the question, I hear the answer, what the Project Manager, or Marketing Director says, but that's different to listening.

Listening means, "I hear what you say, and I will take that into account"

As a tester with a bit of experience, I have to confess I sometimes think I know best. I go into "Yeah sure, that's what you think you want, but here is what you really need" mode and forget to listen to other people.

It takes respect and humility to listen properly to other people. Its something I want to improve on. I know it will make me a better tester in the end.

So, next time you have that conversation with your colleagues or potential clients. Do yourself a favor and really listen to what they have to say. You might even learn something.

Merry Christmas